2
\$\begingroup\$

I have a Sony body with a 24MP APS-C CMOS sensor. It will store images in the following resolutions:

  1. 6000x4000 (24MP)
  2. 4240x2832 (12MP)
  3. 3008x2000 (6MP)

When comparing the 24MP and 6MP cases, it's easy to see that the camera could effectively sample from four physical pixels to produce each stored pixel. Based on this fact alone, I would expect SNR to be twice as high. Or, putting it another way, I could double ISO when recording 6MP and expect the same noise I see at 24MP, all else equal. Is my theory accurate so far?

Now, in practice do cameras that downsample achieve that full theoretical improvement in noise?

There are so many physical and logical layers between the point at which the image impinges the sensor and where it is finally written to a digital image stream I am left wondering if perhaps the camera can do even better when downsampling?

(Conversely, if on-camera downsampling is known to be suboptimal, one would prefer to "pay" to record at maximum resolution and downsample in post-processing, where the full Sqrt[N] improvement in SNR can be achieved.)

\$\endgroup\$
2

1 Answer 1

1
\$\begingroup\$

It's always possible that a poorly written post-processing application could do noise reduction and downsampling, as well as other raw conversion processes, at lower quality than the in-camera routine. But the well written post-processing applications (which would include all of the popular ones and a lot of the less popular ones) can do it much better than the in-camera routines that are limited by speed and power concerns as well as a one-size-fits-all approach to each image converted in-camera.

Every picture your camera takes starts out as a 6000x4000 pixel raw data file. To produce the JPEGs in 24MP, 12, MP, or 6MP resolution the camera processes that raw data into a JPEG image file.

You can do the same thing at least as well and usually much better developing that raw data and applying noise reduction after the fact on a computer. The reasons should be fairly obvious:

  • Cameras are optimized (or at least take a balanced approach) to conserve battery power. Computers are optimized for processing power. The in-camera processor is designed for efficiency and the processing algorithms are written for efficiency in terms of power consumption. Processing on the computer isn't normally as concerned with conserving power - the raw conversion application on the computer is usually more optimized for maximum processing power because it has a power supply much greater than the battery in most cameras.
  • Cameras are designed for speed. The shorter a processing routine is the faster it can be executed. This allows the camera to process each image more quickly and move on to the next image. Shorter in-camera processing times allow higher frame rates until the point is reached where the internal buffer is filled (when the camera to card write speed becomes the bottleneck). There are a few computer photo processing applications that are optimized for speed at the expense of quality but most allow the user to set quality as a priority if the application isn't written that way to start with.
  • Noise reduction is fairly processor intensive. Sometimes it can require more processing power than the demosaicing of the same file. See the first two points above.
  • Noise reduction is also more flexible with most post processing applications than it is with most in-camera controls. Rather than selecting Off-Low-Medium-High in camera and letting the camera actually set the values for luminance and chrominance noise based strictly on a preset value for a particular ISO, in post processing you can control luminance and chrominance noise reduction independently and on a custom basis for each frame based on the actual content. You can also selectively apply different NR levels to different areas of the same photo using a brush tool if your application has that feature.
  • Cameras process the raw data into a jpeg image. If jpeg is the file output selected the camera will only save the information in the jpeg to the memory card. The rest of the data in the raw file is discarded and not saved. So you're stuck with a single interpretation of the raw data. If you don't like that result you can't go back to the raw data and do it again with different settings. If given a raw file, computers retain all of the raw data even though they only display a portion of it in more or less jpeg form on the monitor. When changes to settings are made the application can draw upon all of the data in the raw file to reconvert that data into another more or less jpeg type form to display on the screen. Those changes are non-destructive to the original raw data. The only thing that has changed is how that raw data is interpreted to produce an image. If the user doesn't like that interpretation they can change the settings and let the application reinterpret the original raw data again. And again. And again. And again...
  • There are many other considerations when processing the raw data regarding image quality besides noise reduction. For in-camera processing, please see the first and second points above. On the computer each step can take as long as the user desires and be done one at a time to optimize each step in the process to the preference of the photographer/editor. Cameras tend to use a one size fits all approach to processing the raw data into a jpeg image.
  • All approaches to downsampling are not equal. A brute 4 pixel square into one pixel in a 4:1 reduction as described in the question does not produce as smooth an image as a method that uses info from surrounding pixels, in much the same way that demosaicing does to produce color values, to interpolate the pixel values of the resulting reduction. Of course such an approach is also more complex and requires more processing power.
\$\endgroup\$
5
  • \$\begingroup\$ I don't know enough to even ask, other than to point to this answer to the comment-linked question which suggests, "the sensor may do a hardware-level pixel binning, which decreases read noise when shooting at a lower resolution." My question was essentially along those lines: I.e., Can some level of hardware do something better than can be done with the raw data? Are useful data discarded before raw storage? \$\endgroup\$
    – feetwet
    Commented Jan 8, 2017 at 17:50
  • \$\begingroup\$ "Can some level of hardware do something better than can be done with the raw data?" The in-camera processing is doing what it does with the raw data - the exact same raw data that would be stored on the memory card (assuming it is uncompressed as it is in most cameras). Anything done to the sensor output before it is digitized is done to both the raw data used in-camera and the raw data used later in post-processing because it is the same data. The "... level of hardware (that can) do something better..." is likely the hardware in your computer, not the hardware in the camera. \$\endgroup\$
    – Michael C
    Commented Jan 8, 2017 at 18:39
  • \$\begingroup\$ The answer you link above says exactly the same thing my answer says: If you use the raw data for both the computer can give you a better conversion. That answer only suggest in-camera may be better if the external conversion is done to a camera produced jpeg rather than from the raw data. \$\endgroup\$
    – Michael C
    Commented Jan 8, 2017 at 18:49
  • \$\begingroup\$ Actually, uncompressed above should say losslessly compressed. \$\endgroup\$
    – Michael C
    Commented Jan 8, 2017 at 18:50
  • \$\begingroup\$ Right. And to clarify my comment: by hardware I meant something on the optical or sensor layer, not a post-sensor calculation engine. E.g., there are cameras that do things like shifting optical filters or sensors to oversample in ways that are not put on the raw data stream. So another way of looking at my question is, "Can conventional CMOS image sensor stacks exploit data or physics for downsampling that are unavailable in the raw sensor data files?" \$\endgroup\$
    – feetwet
    Commented Jan 8, 2017 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.