• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

The canon "sRaw" and "mRaw" output formats

Doug Kerr

Well-known member
Beginning with, I believe, the EOS 40D, Canon began offering in the EOS cameras (and eventually in the more serious PowerShot cameras, such as the G- series) a new optional output format, designated "sRaw" (said to be the "small raw" format). These output files have filetype CR2, just like the raw files.

Today, the EOS cameras offer a second optional format of this genre, designated "mRaw" (the "medium raw" format). During an intermediate era, the formats now designated sRaw and mRaw were designated sRaw2 and sRaw1, respectively. (Go figure!)

These files have smaller sizes that than basic raw file.

So what exactly are these?

Before I try and explain that, I am going to give some pertinent background. But first a teaser: These files do not contain the sensor "raw" data as such, nor can it be reconstructed from the file. They are not in any way "raw" files. But there is a little "rawness" to them.

But now, some background.

The Bayer sensor "color space"

The overall outputs of a Bayer-style CFA sensor are in three groups (four actually), customarily designated R, G, G, and B. Those designations are ill-advised, as they suggest that these outputs correspond to the coordinates R, G, and B of an RGB color space (such as sRGB). They don't, in fact, even correspond to the linear precursors of R, G, and B, which I designate r, g, and b. They are in fact (if we set aside an important wrinkle) the coordinates of a different color space, which I will call (for the moment) the sensor color space. And I designate these outputs e, f, and g to avoid the misconception that they are R, B, and B (or even r, g, and b).

The wrinkle is that the sensor "color space" isn't really a color space at all. because a set of values of e, f, and g do not unambiguously indicate a color. But this is not of importance to what follows, so I will not belabor it here. But I will only refer to the sensor pseudo-color space.

The values d, e, and f are held to a precision of 12 or 14 bits, depending on the camera.

YCC encoding

In a JPEG file, once the image is developed and represented in R,G,B form, it is recoded into what is labeled the sYCC form. YCC is short for YCbCr, and the "s" just means that it is a particular standardized form of that encoding, just as sRGB is a particular standardized form of RGB encoding.

In YCbCr encoding, the coordinate Y is derived from a weighed linear combination of the values of R, G, and B. It is often said to represent the luminance of the color (thus the designation "Y") but it doesn't, To develop the luminance of a color, we must take a weighted linear combination of the linear coordinates, r, g, and b. Y isn't even a nonlinear form of the true luminance. So it is perhaps fairly described as a "pseudo-luminance".

Cb and Cr are determined this way:

Cb = B - Y
Cr = B - R

They together form a "pseudo-chrominance" for the color. (They do not form a true chrominance description because they are reckoned from non-linear color coordinates, R, G, and B, rather than from the linear coordinates, r,,g, and b.)

The values R, G, and B from which this process works have a precision of perhaps 12 bits. The values Y, Cb, and Cr are truncated to a precision of 8 bits.

The JPG output flow

Putting aside some subtleties, the process used by the camera in developing a JPG output is essentially this:

• Note that the raw values from the Bayer array, d, e, and f, are to a precision of 12 or 14 bits.

• The suite of raw data (the outputs, d, e, or f of each sensel in the Bayer CFA) is demosaiced. This is a sophisticated from of interpolation that develops d, e, and f values for all the pixel locations that don't have that particular value from the sensor data. The result is that we now have a d, e, anf f value for each pixel location (with a precision of 12 of 14 bits).

• The suite of pixel def values, one for each pixel, is transformed, by multiplication by a transformation matrix, into a suite of rgb values, one for each pixel.

I said that the def outputs do no consistently represent the color of points in the scene. But a set of rgb values does consistently represent a color. So can this transformation be done in a "foolproof" way? No. We do it in a way that minimizes the discrepancy in the process for typical scenes. This is a complex issue which, however, we need not pursue further here.​

• The rgb values for each pixel are converted into RGB (non-linear) values.

• The RGB values for each pixel are converted to YCbCr values.

• Many of the CbCr value pairs are discarded (the process of "chroma subsampling").

• The remaining data is compressed and organized in the proper format for output.

Now, the sRaw format

There is considerable risk that the following description may not be fully accurate. It is based on the best information I am able to get at this time.

Here is the sequence for the generation of an sRaw file.

• The suite of raw data (the outputs, d, e, or f of each sensel in the Bayer CFA) is demosaiced (just as before). This data can be thought of as in the sensor pseudo-color space.

• The suite of def data is downsampled, resulting in a set of def values for only every fourth pixel location.

• The def data for each such pixel location is recoded into a form conceptually the same as YCbCr. But it does not work from nonlinear RGB coordinates, but rather linear def coordinates. So I will speak of its coordinates as Y, Cf, and Cd. The three coordinates are to a precision of 12 or 14 bits (depending on the precision of the sensor data).

• Many of the CfCd value pairs are discarded (the process of "chroma subsampling").

• The remaining data is compressed (in essentially the same way as for a JPG file) and organized in the proper format for output.

For an mRaw file, the process is similar, bu it seems that the initial "downsizing" is only to 75% of the original pixel dimensions (about 1/2 the original pixel count).

The reconstructed image

For the sRaw format, the reconstructed image will typically be at one-half the pixel dimensions of the camera's largest JPG output.

I have nothing here that will make mRaw or sRaw1 files , so I have no idea what the reconstructed image for such is like.

Conclusion

Woof!

The one sentence description

The sRaw and mRaw formats carry a downsized demosaiced image, in the sensor pseudo-color space, re-encoded in an YCbCr-like form, with "chrominance" subsampling, with the coordinates at the same precision as the original sensor data.

Ancestry

I have seen it said that this format was initially developed by Kodak. Perhaps it was Kodak's way of getting back at the movement that eventually almost killed the company - digital photography.

Nikon

Many Nikon cameras offer what seems to be a similar format, and I have seen it said that its operation is conceptually like the Canon formats.

The value of these creatures

I will leave it to others with a more creative bent to fully explain the value of these creatures. But here is my take:

Because they represent the image in the sensor pseudo-color space, and because the coordinates are of a precision corresponding to the precision of the sensor data, the manipulation of images being extracted from such files benefits to a great extent from the same advantages as when we manipulate an image being extracted from a raw file.

And they are smaller.

Acknowledgement

Many thanks to Dave Coffin, developer of the raw development engine dcraw, for helping me to sort out my incomplete understanding of this mess. And thanks to Dave for making it possible for various raw development software, based upon the dcraw engine, to recover the images from these creatures.

Best regards,

Doug
 
Top