params.use_camera_wb will force to use As-shot balance
params.use_auto_wb will switch to auto-balance
params.user_mul[4] allows to use user-specified WB
Any idea how RawTherapee gets it right?
Is there a way to force LibRaw to manually calculate the WB and put it in cam_mul or something like that? Or is it too orthogonal to it's purpose? :)
From _01.DNG sample, using raw-identify -v:
Makernotes 'As shot' WB multipliers: 2.031746 1.000000 1.729730 0.000000
and
Derived D65 multipliers: 6.630021 0.866640 0.901968
This file is shot under daylight, so D65 mutipliers looks incorrect: too weak for blue and too strong for red.
D65 (daylight) multipliers are calculated from DNG ColorMatrix* tag(s). So, embedded profile for this file looks incorrect.
Use as-shot, or auto WB for this camera (I do not see any way to do this automatically in LibRaw because pre_mul is within 'more or less correct values' (6.63/0.86 = 7.7 does not 'high enough' to throw it out automatically)
On a side note, there is no such thing as cross-sensitivity because red, green, and blue are what CFA says they are. For a serious work, sRGB is a sub-optimal choice, because a lot of colour clipping happens when converting CFA RGB to sRGB (all the negative values from such a conversion are clipping). For better colour, try computing a colour matrix for your particular camera.
My understanding is that vendors keep those values secret, so probably the best results are form the raw editor from the manufacturer (Canon). I've also noticed that compared to my program (which uses LibRaw) RawTherapee has slightly different colors, but I haven't investigated if it's the WB, the sRGB matrix, or the tone curve.
Once I finish with everything for my program, I might take a look at their source code and see if I can understand it, and see what's different.
Well, it is my understanding that LibRaw can export fully debayered TIFFs, and that there are various debayering algorithms built in (and some that can be added separately).
I am not sure how the internals work, but it would be very useful if either image[] array was fully populated or there was some other array with the proper RGB values.
I tried implementing a few debayering algorithms in my project, but then eventually gave up (I wasn't getting the results I wanted) and just used the quarter of the resolution debayering method, since that should be enough for my project (a program used for making timelapse videos, where any photo 12MP or bigger can yield enough information for a 1920x1080 movie frame).
I am glad it helped :)
While I am at it, to not open a new thread, would it be possible to expose to C the debayering functions? Maybe I missed something, but I don't think they are exported in C.
So far, things are clear. But what's about the sRGB stuff?
I've compared DCRAW (with and without use of rgb_cam matrix filled in by the adobe_coeff()) to FastRawViewer and also to the Canon software and got 4 different results! DCRAW with use of rgb_cam looks worst (warm & greenish look).
Yes, AsShot white balance is broken in DNG tags:
| 25) AsShotNeutral = inf 8.872800664e-007 200 (1000/0 1000/1127039858 1000/5)
LibRaw by default uses daylight WB (calculated from ColorMatrix* DNG tags), so it works ok. If camera WB is specified explicitly (params.use_camera_wb = 1), than image becomes wrong (as expected).
Looks like we need additional check for camera WB range and fallback to Auto if camera wb looks corrupted.
Sure, I will send it. But actually, I know what the problem is, I just remembered. The camera is a Canon SD980 running CHDK, and I helped porting that CHDK version (at the time this camera was using a newer API set, so CHDK didn't work on it, it needed quite a bit of reverse engineering). And the port might have had some stuff missing.
The interesting thing is that all programs I tried worked fine with it, so I guess they had some detection for invalid Wb settings, and calculated their own.
So probably the DNG is not too useful for you, as only my camera is affected by it (all my other RAWs from other CHDK cameras are OK). But if you still want it, I can send it to you.
Use daylight or auto multipliers if camera WB looks wrong (as in this case). As a general rule, red/blue multipliers should be in 0.05..20.0 (or may be less) range after normalization (green one set to 1.0)
BTW, could you please share this DNG (e.g. send link to info@libraw.org if you do not want to share it public) for detailed examination?
I use the cam_mul for WB, and then do the debayering (manually) and after that I do the sRGB stuff.
You also have to do channel clipping before the sRGB conversion (and optionally highlight recovery).
A good place to start IMHO is "Image sensors and signal processingfor digital still cameras", edited by Junichi Nakamura and "Way Beyond Monochrome" by Ralph Lambrecht. One book covers the digital part, the other speaks of photographic process.
To get flatten output you may try samples/unprocessed_raw sample
B-channel pattern you show looks ok (one value in 2x2 square), while R-channel is not. Could you please upload raw somewhere and provide the link for in-depth analysis?
as-shot balance (cam_mul) is avaliable just after LibRaw::open_file()
To calculate auto-wb you may use raw data with black subtracted (Libraw does this at LibRaw::scale_colors() call, before interpolation step)
I meant, if there was a way to only get the WB, without fully process the image (so that I can do my own processing).
params.use_camera_wb will force to use As-shot balance
params.use_auto_wb will switch to auto-balance
params.user_mul[4] allows to use user-specified WB
Any idea how RawTherapee gets it right?
Is there a way to force LibRaw to manually calculate the WB and put it in cam_mul or something like that? Or is it too orthogonal to it's purpose? :)
Also, with as-shot balance sky is 'too cyan' in FastRawViewer, that also points to not-so-correct embedded color profile.
From _01.DNG sample, using raw-identify -v:
Makernotes 'As shot' WB multipliers: 2.031746 1.000000 1.729730 0.000000
and
Derived D65 multipliers: 6.630021 0.866640 0.901968
This file is shot under daylight, so D65 mutipliers looks incorrect: too weak for blue and too strong for red.
D65 (daylight) multipliers are calculated from DNG ColorMatrix* tag(s). So, embedded profile for this file looks incorrect.
Use as-shot, or auto WB for this camera (I do not see any way to do this automatically in LibRaw because pre_mul is within 'more or less correct values' (6.63/0.86 = 7.7 does not 'high enough' to throw it out automatically)
On a side note, there is no such thing as cross-sensitivity because red, green, and blue are what CFA says they are. For a serious work, sRGB is a sub-optimal choice, because a lot of colour clipping happens when converting CFA RGB to sRGB (all the negative values from such a conversion are clipping). For better colour, try computing a colour matrix for your particular camera.
My understanding is that vendors keep those values secret, so probably the best results are form the raw editor from the manufacturer (Canon). I've also noticed that compared to my program (which uses LibRaw) RawTherapee has slightly different colors, but I haven't investigated if it's the WB, the sRGB matrix, or the tone curve.
Once I finish with everything for my program, I might take a look at their source code and see if I can understand it, and see what's different.
That makes sense, thanks for answering :)
LibRaw's goal is to provide access to raw image data either in source form (LibRaw::open_file/unpack) or in processed (LibRaw::dcraw_process())
There is no intention to expose internal sub-functions, this is orthogonal to library purpose.
Well, it is my understanding that LibRaw can export fully debayered TIFFs, and that there are various debayering algorithms built in (and some that can be added separately).
I am not sure how the internals work, but it would be very useful if either image[] array was fully populated or there was some other array with the proper RGB values.
I tried implementing a few debayering algorithms in my project, but then eventually gave up (I wasn't getting the results I wanted) and just used the quarter of the resolution debayering method, since that should be enough for my project (a program used for making timelapse videos, where any photo 12MP or bigger can yield enough information for a 1920x1080 movie frame).
Could not understand what part of debayer code you want to export (to C-API?).
LibRaw's debayer code uses lot of internals (image[] array, CFA pattern, etc) and not intended to be used alone.
I am glad it helped :)
While I am at it, to not open a new thread, would it be possible to expose to C the debayering functions? Maybe I missed something, but I don't think they are exported in C.
So far, things are clear. But what's about the sRGB stuff?
I've compared DCRAW (with and without use of rgb_cam matrix filled in by the adobe_coeff()) to FastRawViewer and also to the Canon software and got 4 different results! DCRAW with use of rgb_cam looks worst (warm & greenish look).
Got it, thanks
Yes, AsShot white balance is broken in DNG tags:
| 25) AsShotNeutral = inf 8.872800664e-007 200 (1000/0 1000/1127039858 1000/5)
LibRaw by default uses daylight WB (calculated from ColorMatrix* DNG tags), so it works ok. If camera WB is specified explicitly (params.use_camera_wb = 1), than image becomes wrong (as expected).
Looks like we need additional check for camera WB range and fallback to Auto if camera wb looks corrupted.
Thank you for the sample.
Ok, I sent it :) I hope you got it, since it's a large-ish file :)
Let me know if you find anything wrong with it :)
Yes, we collect any 'strange' DNG/RAW files to make sure LibRaw works fine even in corner cases :)
Sure, I will send it. But actually, I know what the problem is, I just remembered. The camera is a Canon SD980 running CHDK, and I helped porting that CHDK version (at the time this camera was using a newer API set, so CHDK didn't work on it, it needed quite a bit of reverse engineering). And the port might have had some stuff missing.
The interesting thing is that all programs I tried worked fine with it, so I guess they had some detection for invalid Wb settings, and calculated their own.
So probably the DNG is not too useful for you, as only my camera is affected by it (all my other RAWs from other CHDK cameras are OK). But if you still want it, I can send it to you.
Use daylight or auto multipliers if camera WB looks wrong (as in this case). As a general rule, red/blue multipliers should be in 0.05..20.0 (or may be less) range after normalization (green one set to 1.0)
BTW, could you please share this DNG (e.g. send link to info@libraw.org if you do not want to share it public) for detailed examination?
I use the cam_mul for WB, and then do the debayering (manually) and after that I do the sRGB stuff.
You also have to do channel clipping before the sRGB conversion (and optionally highlight recovery).
Fantastic! Thanks for the recommendations!
A good place to start IMHO is "Image sensors and signal processingfor digital still cameras", edited by Junichi Nakamura and "Way Beyond Monochrome" by Ralph Lambrecht. One book covers the digital part, the other speaks of photographic process.
Got it. Thanks for taking the time to reply.
If you had any book recommendations that help explain how to do this postprocessing, I'd be very interested.
Thanks again, and thanks for making this amazing library available!
FRV does not use LibRaw for raw image postprocessing, only raw decode phase is used (LibRaw::open_file/LibRaw::unpack).
'Variable contrast' curves in FRV are based on real photographic film contrast curves.
To get flatten output you may try samples/unprocessed_raw sample
B-channel pattern you show looks ok (one value in 2x2 square), while R-channel is not. Could you please upload raw somewhere and provide the link for in-depth analysis?
Pages