Shifting from 808 symbian to lumia 1020

[tgr42]

I didn't confirm any of your statements. If Nokia wanted to, they could've easily made the 808 save multiple sized versions of the same photo regardless of whether the resize was implemented in hardware or software. And if you have visual proof that the 808 really uses a resampling algorithm with higher quality than the 1020 and standard resize algorithms implemented in PC-based software, let's see the images.

 

[JustToClarify]

they couldn't unless 808 had two parallel sensors there is a 3rd party app for 808 that does save both 38&5 pics and results vary greatly in comparison with stock oversampling... also there is a significant difference between 808 full res and 8/5/2 pictures, not the case with 1020 though

tried to find it now, it seems they have removed 808 test from dpreview...shame

 

[Tech friend]

These two articles might be of interest:

• AaWP: All About 'Oversampling', the Lumia 1020 compared to the original Nokia 808
• AaWP: Want absolute purity? Think about NOT reframing that Lumia 1020 photo!

They don't look exactly into the matter discussed here in the very latest posts, but touch it partly.

Considering what this thread in general is about they are worth reading always.

 

[Tech friend]

tried to find it now, it seems they have removed 808 test from dpreview...shame

Due to a lack of time I wasn't able to follow your discussion with tgr42 in detail, but are you perhaps looking for this article?

 

[tgr42]

they couldn't unless 808 had two parallel sensors there is a 3rd party app for 808 that does save both 38&5 pics and results vary greatly in comparison with stock oversampling... also there is a significant difference between 808 full res and 8/5/2 pictures, not the case with 1020 though

tried to find it now, it seems they have removed 808 test from dpreview...shame

Why would they need two parallel sensors? You can already set the 808 to save an image at 38, 8, 5, or 3MP. Why would it require additional hardware to just save the image at one size, then save it at the next size? Sure it would take additional time, but so what? You don't think the 1020 isn't just doing this sequentially behind the scenes, do you?

When it comes to the difference between full-res and resized images, people seem to want to assume that Nokia's "proprietary algorithm" or using the raw sensor data instead of reconstructed RGB as the source for the resize automatically yields higher quality results than resizing the full-res reconstructed RGB data with a standard resize algorithm. These were some good articles that Tech friend has linked here. But unfortunately they don't contain a single test of taking the full-res image from the 808 and then resizing it down with a standard resize algorithm to see how that result compares with the same size 808-resized version. Without doing such a test, it's impossible to prove an advantage in the 808's resize algorithm when all of the other characteristics of the 808 are being mixed into the results as well.

If I had an 808 myself I would just do this test, the same way I did for the 1020 in my last post with the attached images. It would take less than half an hour. But alas, I only have a 1020.

I do think it's kind of amusing how some 808 and 1020 fans feel the need for there to be some greater advantage than just pure high resolution. Do you not realize the advantages of high resolution? Resizing an image down with a competent (but not otherwise special) resize algorithm corrects a great number of problems and will ultimately yield the pixel-perfection that we love to see in images once the image has been resized down far enough. Even Juha presents it this way in his whitepaper about the 808. It's all about the resolution. Nokia has distinguished themselves from the megapixel race of the past in two ways: 1) by offering high resolution in a compact physical space as an alternative to optical zoom, and 2) by being more direct with consumers about the advantages of high resolution, building some convenience around it by integrating it into the phone and the picture-taking experience. Of course everyone was already capable of doing these operations on the PC since the beginning of time: resize and crop. They're two of the simplest tools in the image processing arsenal, but they're also extremely powerful and should not be underestimated.

 

[JustToClarify]

Why would they need two parallel sensors? You can already set the 808 to save an image at 38, 8, 5, or 3MP. Why would it require additional hardware to just save the image at one size, then save it at the next size? Sure it would take additional time, but so what? You don't think the 1020 isn't just doing this sequentially behind the scenes, do you?

you can't bin bixels and use full resolution at the same time, in 808 case it's not (only) additional time, it's additional picture as well (different from the first one) since you can't physically use the sensor twice in the same moment, it would work in case you use tripod (or have a very steady hand) and the scene is static, in all other situations you would get two different pics

1020 takes full res picture and then uses the resize procedure to get 5 MP file, so it's essentially the same picture only with different resolution

When it comes to the difference between full-res and resized images, people seem to want to assume that Nokia's "proprietary algorithm" or using the raw sensor data instead of reconstructed RGB as the source for the resize automatically yields higher quality results than resizing the full-res reconstructed RGB data with a standard resize algorithm. These were some good articles that Tech friend has linked here. But unfortunately they don't contain a single test of taking the full-res image from the 808 and then resizing it down with a standard resize algorithm to see how that result compares with the same size 808-resized version. Without doing such a test, it's impossible to prove an advantage in the 808's resize algorithm when all of the other characteristics of the 808 are being mixed into the results as well.

well first of all it's not technically a resize, since 808 internally bins pixels to form 5 MP of a big size pixels, it doesn't take full 38 MP photo and it never exists in 808 RAM thus it can't be saved

I do think it's kind of amusing how some 808 and 1020 fans feel the need for there to be some greater advantage than just pure high resolution. Do you not realize the advantages of high resolution? Resizing an image down with a competent (but not otherwise special) resize algorithm corrects a great number of problems and will ultimately yield the pixel-perfection that we love to see in images once the image has been resized down far enough. Even Juha presents it this way in his whitepaper about the 808. It's all about the resolution. Nokia has distinguished themselves from the megapixel race of the past in two ways: 1) by offering high resolution in a compact physical space as an alternative to optical zoom, and 2) by being more direct with consumers about the advantages of high resolution, building some convenience around it by integrating it into the phone and the picture-taking experience. Of course everyone was already capable of doing these operations on the PC since the beginning of time: resize and crop. They're two of the simplest tools in the image processing arsenal, but they're also extremely powerful and should not be underestimated.

sure resolution is very important but it's not everything, you have 8 MP cameras that are junk and some that are professional(although old models they are still very good), for example 808 takes much better 2 MP pictures than HTC One which has 4 MP

808&1020 also differ greatly, 808 has hardware DSP, bigger FSI sensor and better optics while 1020 has OIS and sharper BSI sensor

 

[tgr42]

you can't bin bixels and use full resolution at the same time, in 808 case it's not (only) additional time, it's additional picture as well (different from the first one) since you can't physically use the sensor twice in the same moment, it would work in case you use tripod (or have a very steady hand) and the scene is static, in all other situations you would get two different pics

1020 takes full res picture and then uses the resize procedure to get 5 MP file, so it's essentially the same picture only with different resolution

well first of all it's not technically a resize, since 808 internally bins pixels to form 5 MP of a big size pixels, it doesn't take full 38 MP photo and it never exists in 808 RAM thus it can't be saved

Why would you need to "physically use the sensor twice in the same moment" to create multiple output files at different sizes? You just need to capture the data from the sensor once, then do the multiple resizes from that same original data. Yes, they could've designed it in such a way that all of the RGB reconstruction (demosaic etc), resampling, and JPEG encoding happens in real-time taking its input from the sensor in the short window of time while the shutter is open, with only one of several resampling sizes available during the pipeline. One can easily imagine a simpler and more flexible design that stores the raw sensor data in a memory buffer and then does whatever it wants with it after that.

sure resolution is very important but it's not everything, you have 8 MP cameras that are junk and some that are professional(although old models they are still very good), for example 808 takes much better 2 MP pictures than HTC One which has 4 MP

808&1020 also differ greatly, 808 has hardware DSP, bigger FSI sensor and better optics while 1020 has OIS and sharper BSI sensor

Of course there's much more to a camera than resolution, I totally agree. I intended my comments to be limited to the context of resolution and resampling. The 808 and 1020 share the same major distinguishing advantage: high resolution. This is what sets them apart from the competition. Good execution on a number of fronts helps too. But the resampling is nothing special, on both the 808 and 1020, whether it's done in hardware or software. I don't believe it gives you any substantial advantage over resizing the full-res image yourself in a decent paint program. Actually it seems worse, since Nokia doesn't (currently) give you any control over the process - most importantly the level of sharpening.

 

[JustToClarify]

Why would you need to "physically use the sensor twice in the same moment" to create multiple output files at different sizes? You just need to capture the data from the sensor once, then do the multiple resizes from that same original data. Yes, they could've designed it in such a way that all of the RGB reconstruction (demosaic etc), resampling, and JPEG encoding happens in real-time taking its input from the sensor in the short window of time while the shutter is open, with only one of several resampling sizes available during the pipeline. One can easily imagine a simpler and more flexible design that stores the raw sensor data in a memory buffer and then does whatever it wants with it after that.

the problem is that DSP bins pixels on-the-fly, so there is no information in memory about all 38 million of pixels... 808 receives only 5 MP (or whatever resolution you have chosen) from DSP

nice article if you have the time to read it

http://www.imageval.com/public/Papers/20091118 PixelBinningSPIE.pdf

 

[vlad0]

the problem is that DSP bins pixels on-the-fly, so there is no information in memory about all 38 million of pixels... 808 receives only 5 MP (or whatever resolution you have chosen) from DSP

nice article if you have the time to read it

http://www.imageval.com/public/Papers/20091118%20PixelBinningSPIE.pdf

So.. correct me if I am wrong here, but what you are saying is that the 808 oversamples "raw" data from the sensor at time of capture, while the 1020 can't do that since it records all the pixels into a jpeg, and then resizes that into a smaller 5Mpix image ?

But if they are using some clever software algorithm to do that on the 1020, wouldn't be possible to get a very similar result ?

 

[vlad0]

the problem is that DSP bins pixels on-the-fly, so there is no information in memory about all 38 million of pixels... 808 receives only 5 MP (or whatever resolution you have chosen) from DSP

nice article if you have the time to read it

http://www.imageval.com/public/Papers/20091118%20PixelBinningSPIE.pdf

So.. correct me if I am wrong here, but what you are saying is that the 808 oversamples "raw" data from the sensor at time of capture, while the 1020 can't do that since it records all the pixels into a jpeg, and then resizes that into a smaller 5Mpix image ?

If that's the case, its probably a hardware limitation.. I am guessing that with Snap 800 it shouldn't be an issue and they will be able to do exactly what they are doing with the 808's DSP.

But if they are using some clever software algorithm to do that on the 1020, wouldn't be possible to get a very similar result ?

 

[tgr42]

the problem is that DSP bins pixels on-the-fly, so there is no information in memory about all 38 million of pixels... 808 receives only 5 MP (or whatever resolution you have chosen) from DSP

nice article if you have the time to read it

http://www.imageval.com/public/Papers/20091118 PixelBinningSPIE.pdf

Thanks for the link. This paper raises many interesting questions. I learned a lot and it turned out to be a good starting point for further investigation.

This has been a difficult subject to discuss because pixel binning, resampling, and resizing are frequently used interchangeably, and in such cases when differentiation is attempted, they tend to still not be very well defined. But this paper clearly describes the two methods under study: pre-ADC binning vs. digital resizing. Going by its definitions, I can imagine how the 808 might use pre-ADC binning to reduce the amount of data coming out of the sensor when doing resampling. This would speed things up and could possibly have a noticeable advantage when it comes to noise reduction in low light environments. It would also imply the limitation you mentioned: the impossibility of saving both full-res and resampled images for a single shot. Note that this is pre-ADC binning, which implies that it's not the DSP doing the binning as you say. Wouldn't the noise reduction advantage of binning be lost if you did it post-ADC?

In any case, the paper raises a critical point:

In conditions when there is no significant ADC rate or channel bandwidth limitation, it is advantageous to read the entire high resolution image. In this case it will be possible to resize the image later to produce an image that is very similar to that obtained by binning. A resized image can be further blurred to match a binned image with respect to vSNR and MTF50. There is an image quality tradeoff between noise and blur, and depending on the application users may prefer one error over another. This question is open to experimental investigation through user-preference studies.

Now, Nokia's proprietary implementation and unique set of conditions may somehow exempt them from this assertion, but there's no evidence to support that. It sounds to me like there's probably no quality reason to use pre-ADC binning... only a performance reason. And with the data rates involved, It seems likely that the 1020 is doing this for video. They probably just managed to avoid it for still images this time around, and that's a good thing. It doesn't seem like it would necessitate any sacrifice in quality compared to what they did with the 808.

Finally, this paper led me to an interesting GSMArena interview with the head of the team that developed the 808. He pretty much comes right out and says there's no advantage to the PureView resampling compared to Photoshop, other than his strange view that being stuck with Nokia's preferred tradeoff between noise and sharpness is somehow an advantage (seems quite the opposite to me):

Nokia 808 PureView in focus: Interview with D. Dinning - GSMArena.com

The interviewer tried to help him out by pointing out that saving only the phone-resampled images saves space on your phone while shooting, but he didn't seem too interested in that.

 

[JustToClarify]

So.. correct me if I am wrong here, but what you are saying is that the 808 oversamples "raw" data from the sensor at time of capture, while the 1020 can't do that since it records all the pixels into a jpeg, and then resizes that into a smaller 5Mpix image ?

If that's the case, its probably a hardware limitation.. I am guessing that with Snap 800 it shouldn't be an issue and they will be able to do exactly what they are doing with the 808's DSP.

But if they are using some clever software algorithm to do that on the 1020, wouldn't be possible to get a very similar result ?

no, dedicated silicon is a dedicated silicon and Snapdragon 800 is no Cray...

Finally, this paper led me to an interesting GSMArena interview with the head of the team that developed the 808. He pretty much comes right out and says there's no advantage to the PureView resampling compared to Photoshop, other than his strange view that being stuck with Nokia's preferred tradeoff between noise and sharpness is somehow an advantage (seems quite the opposite to me):

Nokia 808 PureView in focus: Interview with D. Dinning - GSMArena.com

The interviewer tried to help him out by pointing out that saving only the phone-resampled images saves space on your phone while shooting, but he didn't seem too interested in that.

GSMArena: If we only needed a 2MP image, for instance, we would traditionally take a full resolution shot, and then downsample it with Photoshop. Does PureView provide downsampling algorithms superior to those of Photoshop or other image editing software, effectively eliminating this step?

D. Dinning: We haven't really made that comparison. What I can say is, depending on the interpolation and downsampling you use in Photoshop, it may be possible that you'll get similar performance. But you're then handling the JPG file that was saved, so you're probably better off doing it at point of capture. I think you'll find that we probably have a different balance to what you achieve with Photoshop. How we optimize the algorithms is to retain as much of the detail as possible that we think is represented in the object, but also filter as much of the noise as possible. In Photoshop, you typically might get a sharpness that looks higher, but you might get more noise, for example. We struck a slightly different balance when we use our algorithms.

pay attention on words "may" and "similar"

 

[Bahamen]

It's been established that the 5MP image on the 1020 is sampled from the raw image from the sensor at point of capture. It is only at subsequent reframing that samples from the jpeg file. This has been explained by Juha before (through Steve Litchfield or Marc @ Pureviewclub).

 

[tgr42]

pay attention on words "may" and "similar"

Oh please. He was caught in a difficult question and did his best to weasel his way out of it. I do give him credit for attempting to give a "least untruthful" answer, although his remark "we haven't really made that comparison" is pretty shaky. Sure, they haven't made the comparison in their marketing and sales materials, for obvious reasons. You can bet they made the comparison in their research and development efforts. Anyone who implements resampling and cares about quality is going to compare their results with Photoshop.

 

[JustToClarify]

It's been established that the 5MP image on the 1020 is sampled from the raw image from the sensor at point of capture. It is only at subsequent reframing that samples from the jpeg file. This has been explained by Juha before (through Steve Litchfield or Marc @ Pureviewclub).

it raises the question why they didn't leave only 5MP option that would take half a second (or so) instead of having only 38+5 MP option taking 3-4 seconds?!

 

[Bahamen]

it raises the question why they didn't leave only 5MP option that would take half a second (or so) instead of having only 38+5 MP option taking 3-4 seconds?!

The only difference between 38+5 vs 5 is the time required to save the 38MP file. All other processes are still required.

 

[Bahamen]

Oh please. He was caught in a difficult question and did his best to weasel his way out of it. I do give him credit for attempting to give a "least untruthful" answer, although his remark "we haven't really made that comparison" is pretty shaky. Sure, they haven't made the comparison in their marketing and sales materials, for obvious reasons. You can bet they made the comparison in their research and development efforts. Anyone who implements resampling and cares about quality is going to compare their results with Photoshop.

Dude. If they can achieve reasonably good results with the Pureview sampling, that alone is sufficient. And the 808 does get good results. Why the heck did anyone expect them to publish comparisons to Photoshop? Nokia is not in the business of competing with Photoshop, are they?

 

[tgr42]

Dude. If they can achieve reasonably good results with the Pureview sampling, that alone is sufficient. And the 808 does get good results. Why the heck did anyone expect them to publish comparisons to Photoshop? Nokia is not in the business of competing with Photoshop, are they?

I'm only debunking claims that Nokia's downsampling - 808 or 1020, software or hardware - outperforms a standard image resize operation performed on the full-resolution image saved by the phone. That is all.

 

[Bahamen]

I'm only debunking claims that Nokia's downsampling - 808 or 1020, software or hardware - outperforms a standard image resize operation performed on the full-resolution image saved by the phone. That is all.

I think there's more to that. Your interesting choice of words "he was caught" and attempted to "weasel his way out" seems rather deliberate to paint Damian as being dishonest or had something to hide. I invite you to explain how that is the case.

 

[JustToClarify]

The only difference between 38+5 vs 5 is the time required to save the 38MP file. All other processes are still required.

For 1020 it takes time of 3.6 seconds for 5 mpx photos and 4.2 seconds for 38 mpx photos, for 808 it's 0.5 vs 3.5 (or so). I think that's quite telling difference.

Dude. If they can achieve reasonably good results with the Pureview sampling, that alone is sufficient. And the 808 does get good results. Why the heck did anyone expect them to publish comparisons to Photoshop? Nokia is not in the business of competing with Photoshop, are they?

exactly, maybe someone from the team has tried to see the difference but didn't find necessary to inform Damian about that

I'm only debunking claims that Nokia's downsampling - 808 or 1020, software or hardware - outperforms a standard image resize operation performed on the full-resolution image saved by the phone. That is all.

I wouldn't call it outperforming (at least not every time), just being different in a way it's done.