Doug Kerr
Well-known member
When the new Canon "sRaw" image format emerged (on the EOS 1D Mark III), I paid little attention. I did note that there seemed to be some initial lack of clarity as to just exactly what this creature was. That uncertainty has been very durable.
Just today, I was reminded of the matter by an inquiry posted on the Pro Photo Home forum. I thought it was about time to figure out "what is really going on here".
You can follow the action over there by starting here:
http://www.prophotohome.com/forum/c...x-sensors/89799-what-sraw-camera-process.html
A couple of the wizards on the forum pointed me to a couple of "articles" on the matter, and I was off and running.
I'm a long way from figuring out the whole thing, but certain things seem likely so. Here's what I today believe is the story.
**********
• The sRaw format occupies an interesting middle ground between the familiar set of raw data and a "developed" image. It is "slightly-cooked" data - essentially demosaiced and that's all
• In the "basic" version, the image represented in sRaw form has exactly the pixel dimensions of one of the small options the camera offers for its JPEG output (in the EOS 40D, equivalent to the ""small" JPEG output).
• For each pixel position (at this resolution), there are an R, G, and B value, in linear, 14-bit form, which can be thought of as demosaiced and "downsampled" raw data (and with the two "G" channels consolidated; since the data has already been demosaiced, there is no value nor meaning to two G values per pixel).
• These are then transformed to a YCbCr form, with the Cb and Cr components at half the resolution of the "sRaw fat pixels" (just as is done, in our regular JPEG file, with the gamma-precompensated RGB values of the pixels of the developed image). Just as in the JPEG case, this recognizes the lower resolution of the human eye to changes in chromaticity compared to luminance. In effect, the raw data has been compromised in this regard.
• The resulting suite of data comprises four 14-bit numbers for each two "sRaw pixels" (2 Y values, 1 Cb value, and 1 Cr value).
• This is then compressed with a "reversible" JPEG compression algorithm ("lossless" is the unfortunate common description).
Now, with such an sRaw file in hand, we can decode the compression (since the compression is reversible, we get the original data back precisely) and, by interpolating the Cb and Cr values (since there is only one of each for every two sRaw pixels), get a complete YCbCr representation for each sRaw pixel.
From that, we can unambiguously reconstruct the (linear) R, G, and B "raw" values for each sRaw pixel.
We now work this just as we would work "regular" raw data - except that we do not need to demosaic it, since we already have an explicit set of R, G, and B for each sRaw pixel. We can manage it for "exposure compensation", apply a color-correction vector for white balance purposes, and apply sharpening.
**********
If the sRaw image has half the resolution (half the pixel dimensions) of the "native" resolution of the camera, then the amount of data to be compressed is exactly half the amount of data for the regular raw file (of the 14-bit flavor).
**********
What is the object of this, anyway? Canon, in the white paper for the EOS 1D Mark III, where this format first appeared, points out that the sRaw file (of the single type then available) has about half the size of a conventional raw file, and supports an image of half the pixel dimensions (1/4 the number of pixels).
They continue that such an image may be very important for some work (wedding photography is, inexplicably, mentioned), and it is advantageous to have the flexibility in processing offered by the raw approach with a smaller file than if the regular raw output were used.
Later (even in the white paper for the EOS 40D), they gave up trying to explain its advantage. And wedding photographers were not further mentioned.
**********
That's how it looks here. Others may know things that show this outlook to be a complete misconception.
Just today, I was reminded of the matter by an inquiry posted on the Pro Photo Home forum. I thought it was about time to figure out "what is really going on here".
You can follow the action over there by starting here:
http://www.prophotohome.com/forum/c...x-sensors/89799-what-sraw-camera-process.html
A couple of the wizards on the forum pointed me to a couple of "articles" on the matter, and I was off and running.
I'm a long way from figuring out the whole thing, but certain things seem likely so. Here's what I today believe is the story.
**********
• The sRaw format occupies an interesting middle ground between the familiar set of raw data and a "developed" image. It is "slightly-cooked" data - essentially demosaiced and that's all
• In the "basic" version, the image represented in sRaw form has exactly the pixel dimensions of one of the small options the camera offers for its JPEG output (in the EOS 40D, equivalent to the ""small" JPEG output).
• For each pixel position (at this resolution), there are an R, G, and B value, in linear, 14-bit form, which can be thought of as demosaiced and "downsampled" raw data (and with the two "G" channels consolidated; since the data has already been demosaiced, there is no value nor meaning to two G values per pixel).
• These are then transformed to a YCbCr form, with the Cb and Cr components at half the resolution of the "sRaw fat pixels" (just as is done, in our regular JPEG file, with the gamma-precompensated RGB values of the pixels of the developed image). Just as in the JPEG case, this recognizes the lower resolution of the human eye to changes in chromaticity compared to luminance. In effect, the raw data has been compromised in this regard.
• The resulting suite of data comprises four 14-bit numbers for each two "sRaw pixels" (2 Y values, 1 Cb value, and 1 Cr value).
• This is then compressed with a "reversible" JPEG compression algorithm ("lossless" is the unfortunate common description).
Now, with such an sRaw file in hand, we can decode the compression (since the compression is reversible, we get the original data back precisely) and, by interpolating the Cb and Cr values (since there is only one of each for every two sRaw pixels), get a complete YCbCr representation for each sRaw pixel.
From that, we can unambiguously reconstruct the (linear) R, G, and B "raw" values for each sRaw pixel.
We now work this just as we would work "regular" raw data - except that we do not need to demosaic it, since we already have an explicit set of R, G, and B for each sRaw pixel. We can manage it for "exposure compensation", apply a color-correction vector for white balance purposes, and apply sharpening.
**********
If the sRaw image has half the resolution (half the pixel dimensions) of the "native" resolution of the camera, then the amount of data to be compressed is exactly half the amount of data for the regular raw file (of the 14-bit flavor).
**********
What is the object of this, anyway? Canon, in the white paper for the EOS 1D Mark III, where this format first appeared, points out that the sRaw file (of the single type then available) has about half the size of a conventional raw file, and supports an image of half the pixel dimensions (1/4 the number of pixels).
They continue that such an image may be very important for some work (wedding photography is, inexplicably, mentioned), and it is advantageous to have the flexibility in processing offered by the raw approach with a smaller file than if the regular raw output were used.
Later (even in the white paper for the EOS 40D), they gave up trying to explain its advantage. And wedding photographers were not further mentioned.
**********
That's how it looks here. Others may know things that show this outlook to be a complete misconception.