0.18 will receive only security fixes, no new cameras, sorry.
LibRaw is surely compatible with gcc 4+, clang 3+ (may be 2+ too), Visual Studio 2010+ (not sure about 2008). Most of these tools are available for free (including Visual Studio community edition), so I advise you to switch to current public snapshot (from github), it is stable enough for production use (and we use it for RawDigger and FastRawViewer).
Thanks for your reply and for taking time to find a solution so quickly.
I have not yet tried to build libRaw from sources, this is not easy for me because I have to use an old version of Visual Studio (2005) for my application. Do you plan to release a 0.18.x version including this fix or will it be in 0.19 ?
Thanks for yout fast reply. I am going to send you one samle file right now.
I just want to correct something that I said in my first post. Suspecting an authorization problem, I changed the location of the input file : now, I get an error code -2 (Unsupported file format or not RAW file) when using open_file.
Oh, so this won't work for a photo of the sea and sky, or a forest canopy with little sky, etc.
I will take a look at that code after I finish some other things, thanks!
This code cycle through image[] 8x8 blocks, skip blocks with data near sensor saturation and calculates pixel sum/count for other (non-saturated) blocks to get mean per-channel values.
This code assumes entire image is (average) gray. If not, auto-WB will not work well.[/geshifilter-c]
Sorry, I meant if there was a way to get the auto WB. I know I can get the "as shot" WB.
Right now, I do things like this:
Init, open, unpack, raw2image, black subtraction, apply WB, debayer, sRGB, gamma curve then I do things like contrast and saturation.
Is there a function I can call after black subtraction to make LibRaw return an auto calculated WB, preferably accessible from C, without doing further data 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? :)
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.
LibRaw 0.18 will receive security fixes only. Use public development snapshot, it is stable enough to use in production
Ok, I will give it a try. Thanks a lot for your great work.
0.18 will receive only security fixes, no new cameras, sorry.
LibRaw is surely compatible with gcc 4+, clang 3+ (may be 2+ too), Visual Studio 2010+ (not sure about 2008). Most of these tools are available for free (including Visual Studio community edition), so I advise you to switch to current public snapshot (from github), it is stable enough for production use (and we use it for RawDigger and FastRawViewer).
Thanks for your reply and for taking time to find a solution so quickly.
I have not yet tried to build libRaw from sources, this is not easy for me because I have to use an old version of Visual Studio (2005) for my application. Do you plan to release a 0.18.x version including this fix or will it be in 0.19 ?
Thanks.
Eric
Thank you for sample.
This is due to additional raw metadata integrity check added somewhere before 0.18 version.
It is already fixed in development snapshot, please apply this patch to 0.18: https://github.com/LibRaw/LibRaw/commit/ade8d9a0be16079b177bdb5ec33dd880...
Thanks for yout fast reply. I am going to send you one samle file right now.
I just want to correct something that I said in my first post. Suspecting an authorization problem, I changed the location of the input file : now, I get an error code -2 (Unsupported file format or not RAW file) when using open_file.
You may upload sample to some file sharing service (Dropbox, Google drive, WeTransfer/free version, etc) and send link to info@libraw.org
Please do not use 'share for' Google/Dropbox service, because it requires account linked to specific email, just 'share for anyone who knows the URL'
Could you please provide sample file that do not open?
Do not use mingw, according to quick googling you need to add ws2_32 library to link options to get htons and other these functions for mingw: http://mingw.5.n7.nabble.com/Link-error-undefined-reference-to-htonl-4-w...
Well, if the "as shot" multipliers worked, I wouldn't have asked about the auto WB thing :)
Yes, auto balance does not work well for colored shots. Use as-shot (camera wb) instead.
Oh, so this won't work for a photo of the sea and sky, or a forest canopy with little sky, etc.
I will take a look at that code after I finish some other things, thanks!
sorry for geshifilter-c in previous message, sometimes code formatter on our site works strange :)
this is just [ c ]
There is no exposed function.
You may steal code from internal\dcraw_common.cpp:scale_colors() function;
Starting with
if (use_auto_wb || (use_camera_wb && cam_mul[0] == -1)) {And up to final calculation of pre_mul:
This code cycle through image[] 8x8 blocks, skip blocks with data near sensor saturation and calculates pixel sum/count for other (non-saturated) blocks to get mean per-channel values. This code assumes entire image is (average) gray. If not, auto-WB will not work well.[/geshifilter-c]
Sorry, I meant if there was a way to get the auto WB. I know I can get the "as shot" WB.
Right now, I do things like this:
Init, open, unpack, raw2image, black subtraction, apply WB, debayer, sRGB, gamma curve then I do things like contrast and saturation.
Is there a function I can call after black subtraction to make LibRaw return an auto calculated WB, preferably accessible from C, without doing further data processing?
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.
Pages