Feature #8362

50D sRAW1 doesn't work

Added by Anonymous over 9 years ago. Updated over 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
hardware architecture:


When I try to open sRaw1(8Mpix) in Darkroom all I get is black. when zooming in or out it shows some purple ghost image.
normal Raws(15Mpix) work ok.
No OpenCL in use.
no plugins affect the end result. But automatic exposure is calculated and seems reasonable.


#1 Updated by Anonymous over 9 years ago

Sharing some RAWS.. smaller and bigger ... easier to find out the problem.. :)

#2 Updated by Jose Carlos Garcia Sogo over 9 years ago

It seemed to work in 0.7 so it is a matter of making an exception for these files so they're not processed by rawspeed.

#3 Updated by Tobias Ellinghaus over 9 years ago

A short update on this issue. With IMG_Joulu-182141-0014.cr2 rawspeed throws an exception in ColorFilterArray::getDcrawFilter(). Because of this the opening is handed over to libraw which for some reason generates garbage. The interesting thing is, that the image is displayed correctly for half a second and then gets broken. Investigation continues …

#4 Updated by Anonymous over 9 years ago

Whoops.. I renamed the files ;) IMG_Joulu-182141-0014.cr2 is now "50D sSraw.cr2"

Might that short "working" image be jpeg preview that is embedded in raws?

#5 Updated by brteag00 - over 9 years ago

I've been poking at this. Yes, the "working" image is a JPEG embedded preview.

It turns out that Rawspeed will, in fact, open an sRaw. Instead of providing the bayer pattern to be demosaiced, it does some funny interpolation and returns 6 bytes-per-pixel RGB data. (The reason that getDcrawFilter pukes is that, with no bayer pattern, there's no color filter.) I don't know enough about the pixel pipe, but I imagine something similar to dt_iop_clip_and_zoom would be required to read it.

Or someone could just figure out what broke, that the libraw fallback doesn't work any more... I can also provide test files, if needed.

#6 Updated by brteag00 - over 9 years ago

Alright. I've got the first pass at sRaw support. Only works with sRaw2 (x and y subsampling), not sRaw1 (only x subsampling). I don't know why - this might be a rawspeed issue, or I might not be using the rawspeed output correctly. I'll look.

Also, mip generation is still a little wonky. We should probably use the jpeg preview for images that haven't had any processing applied yet. This gives a green cast to thumbnails for images that haven't been processed yet. Also, occasionally they're weird colored bars instead of images.

#7 Updated by brteag00 - over 9 years ago

Canon sRAW support, cut #8272. This patch replaces the previous one. It adds sRAW1 support (y-only subsampling) - the trick is to ignore the rightmost 72 pixels of the interpolated image data that rawspeed provides. It also fixes portrait-oriented images.

Also fixes the mip generation. As far as I can tell, the only remaining bug is that newly imported images' thumbnails have a green cast, because white-balance correction isn't being applied.

Testing is encouraged! Especially with other cameras' sRAWs - mine is a Canon 50D. The rawspeed code seems to indicate that there are some cameras with different sRAW formats - I'd be especially interested in knowing whether the 40D works.

#8 Updated by Anonymous over 9 years ago

I'll get my 40D from service soon, I'll test it too. If no one beats me to it.

#9 Updated by brteag00 - over 9 years ago

A recent commit to git master caused a merge conflict. Here's the revised patch.

#10 Updated by brteag00 - over 9 years ago

Finally got my head wrapped around preview generation. As far as I can tell, this patch solves the remaining issues. Wider testing is requested, especially for sRAWs generated by the Canon 40D.

#11 Updated by brteag00 - over 8 years ago

  • Status changed from New to Fixed

Sorry - fixed in changeset 6b8faab4 over a year ago. Marking closed/fixed.

Also available in: Atom PDF

Go to top