Canon 40D users: what does sRAW consist of?

[Guillermo Luijk]

Is sRAW a RAW interpolation? signal decimation? I have seen some 100% crops of sRAW images vs corresponding RAW and they seem to be a bit more sharp.

I didn't have access to the RAW files however. Does anyone know what technical process is behind sRAW?

Regards

[Jonathan Wienke]

Does anyone know what technical process is behind sRAW?

Basically it is some kind of in-camera conversion from 4 mono-color pixels (G-R-G-B) to a single linear RGB pixel.

[Guillermo Luijk]

Basically it is some kind of in-camera conversion from 4 mono-color pixels (G-R-G- to a single linear RGB pixel.

I was thinking of something like that, but then the result needs some special (and simpler) demosaicing strategy, doesn't it? because the Bayer estructure is not preserved. Or it is?

[John Sheehy]

I was thinking of something like that, but then the result needs some special (and simpler) demosaicing strategy, doesn't it? because the Bayer estructure is not preserved. Or it is?
[a href=\"index.php?act=findpost&pid=177838\"][{POST_SNAPBACK}][/a]

IIRC, it is the original data resampled and redistributed in such a way that the resulting sRAW, with 1/4 the pixels of the RAW, have 1/2 as many samples as the original RAW, but with two of them in each pixel such that there are two types of pixels, green+red and green+blue, 30 bits each (I don't recall if it is 15+15 or not), in a checkerboard pattern.

So, yes, they still need a form of demosaicing for the red and blue channels.

This is according to our own Panopeeper, under another name in another forum.

[Panopeeper]

SRaw is a demosaiced form. It does not need any more demosaicing, but the color needs to be white balanced and transformed from twe camera's color space in whatever.

The data is stored as a three component JPEG image; two components are subsampled. This means, that there is a green components for each pixel, but there is only one red and one blue component for each pair of pixels (in a row).

As every pixel pair represents eight raw pixels (numerically only), i.e. two red, two blue and four green pixels, every color component value in the sRaw fprmat represents two source raw pixels. The values are kept in 15-bit form; I *guess* that the purpose of this form is to store a precise average of the incorporated pixel values (the added precision covers the extra bit resulting from dividing the sum by two).

In other words the sRaw format contains *close to half* of the original values. I have not done anything with it yet, but I do expect a better quality than downresing in PP could deliver.

[bernie west]

What bugs me about this is how hard it is to find this information out (I'm guessing Pano worked it out himself, not from Canon?).  Why can't Canon provide a definitive technical description of what is actually going on in things like ISO, HTP, and now sRAW?  There I was for a while shooting away at intermediate isos, thinking they were implemented on the analogue data off the sensor, and later find out that they are just a post-processing fudge.  Surely professionals and advanced enthusiast can handle knowing what is going on in their cameras, and be given the chance to capture the best signal from a scene.  End of rant...

[Panopeeper]

Why can't Canon provide a definitive technical description of what is actually going on in things like ISO, HTP, and now sRAW?

It is not only Canon; others are even worse (this is not in defence of Canon). Nikon and Sony even cryptographically encode some information in the raw file. They regularly violate the protocols of the data formats.

They maintain the myth, that their own raw processor should be enough for everyone, there is no need for them to supply any information to other raw processor developers. Some of them offer developer kits, but those restrict the way to process the data.

On the other hand, one has to realize, that there are not enough people interested on such technical details. See on this forum as well: pixel peepers are outcast, like those, who want to take a closer look instead of shooting the cat to show, how good the camera is.

I hope the time will come soon, when someone will force one of the big manufacturers to publish their interfaces - like Miscrosoft is forced in the EU (got fined again). This should be a breeze for layers, for the camera manufacturers do not have the slightest basis to keep that secret, or even to cryptographically encode them.

[Guillermo Luijk]

I do expect a better quality than downresing in PP could deliver.

Since the sRAW data can be obtained from the complete RAW data, does your last statement mean that a downsizing algorithm can be implemented using this kind of strategies improving the quality of result over a regular demosaicing + regular resizing down?

On one side I consider this theoretically logic since we don't perform so many Bayer interpolations that in the end are to be averaged.

But on the other side I cannot forget the own sRAW's definition means losing information.

Bayer interpolation + resizing down to the final size (i.e. losing information)

          vs

sRAW creation (i.e. losing information) + resizing down to the final size (i.e. losing information again)

If I got it we are facing a two step resizing algorithm vs a one step resizing, both of different nature. I hope you do your tests soon.

Regards.

[John Sheehy]

SRaw is a demosaiced form.

But it is remosaiced again, and must be demosaiced again:

but there is only one red and one blue component for each pair of pixels (in a row).

[a href=\"index.php?act=findpost&pid=177877\"][{POST_SNAPBACK}][/a]

[Panopeeper]

Since the sRAW data can be obtained from the complete RAW data, does your last statement mean that a downsizing algorithm can be implemented using this kind of strategies improving the quality of result over a regular demosaicing + regular resizing down?

I don't have any raw processor, which would downsize this way. Rawnalyze (not a raw processor!) is doing something close to this: when you view in color image mode with reduced size, the four pixels of each CFA block are regarded as one pixel with three color components (the greens are averaged). However, that is not a demosaicing.

Anyway, this process imitates a perfect Foevon sensor, with large sensels.

But on the other side I cannot forget the own sRAW's definition means losing information

This is a loss only in relation to the full size image.

But it is remosaiced again, and must be demosaiced again

A further demosaicing can not take place at this stage any more; the original relative physical locations of the pixels does not apply any more.

Simply, the one red value appies to two pixels; the same goes for the blue value. This is a normal procedure, part of the JPEG compression too, for example in PS up to quality 7 or 8.

[teddillard]

somebody's saying on another forum that sRAW files take longer to download than even the bigger RAW files (5DMII), which makes no sense to me...  he saw it posted somewhere but can't remember where.  I've talked to a few of our techs, nobody has any idea what could cause that, based on a file structure.  

any idea what that is about?

[Panopeeper]

somebody's saying on another forum that sRAW files take longer to download than even the bigger RAW files (5DMII), which makes no sense to me...  he saw it posted somewhere but can't remember where.

any idea what that is about?

Intuitively I would say it is nonsense, but I will ask somebody who may know somebody who may have read a post somewhere from whomever relating to some issue regarding digital photography.

[BJL]

Here is a wild speculation as to how this could be happening.
Start with the standard Bayer CFA data on a pair of rows:
GRGRGRGR...
BGBGBGBG...
Average the two greens in each 2x2 block, so the above 16 pixels give four "big G" values, which I describe as
|GG|GG|GG|GG|...
|GG|GG|GG|GG|...
Average each side-by-side R values, giving big R values offset a bit to the right, which I indicate as
 |RR|RR|RR|...
 |RR|RR|RR|...
same for blue, but the B pairs used are from locations offset a bit to the left:
|BB|BB|BB|...
|BB|BB|BB|...
Pair the big B's with the "odd numbered" big G's, and the big R's with the "even numbered" big G's:
|GG|GG|GG|GG|...
|BB|RR|BB|RR|...
Output for the above 16 origial samples four pixels that are alternately G and B only, G and R only.

Which RAW processors handle sRAW? Only Canon's own?

[teddillard]

Intuitively I would say it is nonsense, but I will ask somebody who may know somebody who may have read a post somewhere from whomever relating to some issue regarding digital photography.

thanks!  everybody I've talked to has the same response...  pretty much nonsense.

[Panopeeper]

Here is a wild speculation as to how this could be happening.

A closer look at the sRaw file helps in the speculation (I have not looked at the larger version, sRaw2).

The original arrangement is

Grb,Brb,Grb,Brg
Rrb,Grb,Rgb,Grb

After demosaicing:

G11,B11,G12,B12
R21,G21,R22,G22

The sRaw file contains tricolor pixels with the red and blue subsampled; I *guess* this is it:

((R21+R22)/2, (G11+G21)/2, (B11+B12)/2)    ((R21+R22)/2, (G12+G22)/2, (B11+B12)/2)

Note, that (R21+R22)/2 and (B11+B12)/2 are not stored twice (this is the subsampling).

[BJL]

The sRaw file contains tricolor pixels with the red and blue subsampled; I *guess* this is it:

((R21+R22)/2, (G11+G21)/2, (B11+B12)/2)    ((R21+R22)/2, (G12+G22)/2, (B11+B12)/2)

Note, that (R21+R22)/2 and (B11+B12)/2 are not stored twice (this is the subsampling).

Thanks; that is a more careful statement of roughly what I was thinking of, except for the extra detail of "all three colors in each pixel, but not really, due to sub-sampling". Can you explain what that involves? I can maybe see it being done with JPEG, by eliminating all horizontal spatial frequencies about half the maximum from the R and B data. Or some equivalent trick of storing FFT conversions of the data.

[Panopeeper]

Thanks; that is a more careful statement of roughly what I was thinking of, except for the extra detail of "all three colors in each pixel, but not really, due to sub-sampling". Can you explain what that involves?

It is something like JPEG (the data is stored in three-component JPEG format, losslessly compressed). Most JPEG images are in the form of a tighter specification, namely JFIF, which requires that the luminance and colorance are separated; the three channels will be Y, Cb and Cr, instead of R, G and B. The separation allows for different encoding of the components; usually the luminance is kept completely, and 1/4, 1/2 or even 3/4 of the color info will be discarded. It is up to the encoder program how this reduction occurs, for example by averaging the available components and storing the average.

As the sRaw compression is lossless, this is not a consideration, but space saving must occur, otherwise the main point is lost. The saving is on the red and blue values: they are shared between two adjacent pixels.  Four color values are stored for every two pixels, this doubles the color info per pixel compared to the original raw, but the number of pixels is halved. The result is an sRaw file half of the size of a full raw.

The JPEG metadata indicates, that the data precision is 15bits per component; perhaps there is no halving of the values as I speculated above. This would allow for some more accuracy.