When yo set use_camera_wb, LibRaw uses camera reported WB coefficients.
If not, 'daylight WB' coeffs are calculated from built-in color profile, this coeff may differ.
To avoid (most of) clipping due to auto bright, one may set auto_bright_thr to very low value (e.g. 0.0)
When I set use_camera_wb and use_auto_wb both to zero, I get a yellow cast on the image. When I set use_camera_wb to 1 and take the same photo with camera WB set to daylight it there is no yellow cast. (Camera is Sony A7R4, but I get similar results from Olympus Pen-F). I can email you sample images if you don't believe me.
Is anything else that could affect WB?
Here is the code I am using to read and process the image:
White level (data maximum) is not as easy as it should be.
LibRaw provides (estimated) data maximum in imgdata.color.maximum. This value is
- either hardcoded (this is derived from dcraw.c)
- or last item of linearization curve
- or determined using camera bit count
For many formats/vendors/settings it is correct, for others it is overestimated (for example, Panasonic low ISO w/ full-well limited sensor, also Canon's intermediate ISOs)
Also, there is imgdata.color.linear_max[]. If filled (nonzero) this value(s) represents vendor suggested white point parsed from metadata. This value is usually way too low (there are a lot of pixels above this threshold), but it is (yes) suggested by vendor.
Also, there are vendor-specific values in parsed metadata fields (e.g. canon.NormalWhiteLevel/canon.SpecularWhiteLevel)
If you're ready to subclass LibRaw to own class to access protected fields (libraw_internal_data.unpacker_data) , use this method:
position to libraw_internal_data.unpacker_data.data_offset and read header (16 bytes), data version in 3rd byte of header (header[2]), it is 1 for lossless compression (supported) and 0 for unsupported lossy.
Alex,
Apologies for jumping the gun and reporting the issue in 0.20.0 as a bug. I just saw that my tests had failed and assumed a regression. But I agree that 0.20.0 behaviour is better.
I will upgrade to 0.20.2 for the updated raw-identify behaviour.
Alex,
This file has four distinct sensors. However, when the multiplier for E is marked as 0, this would indicate that the E component is being discarded. Same with the rgb_cam having 0's for the E component.
I noticed that the cam_xyz is the same as the F828 entry in the adobe_coeff table is the same. This indicates there is a change in how the rgb_cam and hence the Daylight multipliers are derived in the code.
That being said, the 0.19.5 version has a very strong yellow cast on the image but the image definitely looks better in 0.20.0. Please find attached screenshots in the same drive location as above. I assume the 0.20.0 is the expected behaviour.
Also, the filter pattern reported appears to be different (REGB vs ERBG) but I guess this is expected because the visible dimensions are different too.
When yo set use_camera_wb, LibRaw uses camera reported WB coefficients.
If not, 'daylight WB' coeffs are calculated from built-in color profile, this coeff may differ.
To avoid (most of) clipping due to auto bright, one may set auto_bright_thr to very low value (e.g. 0.0)
A further note, probably irrelevant -- if I set no_auto_bright to zero, the white balance looks better - but some of the channels are clipped.
When I set use_camera_wb and use_auto_wb both to zero, I get a yellow cast on the image. When I set use_camera_wb to 1 and take the same photo with camera WB set to daylight it there is no yellow cast. (Camera is Sony A7R4, but I get similar results from Olympus Pen-F). I can email you sample images if you don't believe me.
Is anything else that could affect WB?
Here is the code I am using to read and process the image:
// create an image processor
LibRaw iProcessor;
// open the file and read the metadata
err = iProcessor.open_file(pathname);
if(err != 0)
return(TRUE);
// set to 16-bit output
iProcessor.imgdata.params.output_bps = 16;
iProcessor.imgdata.params.no_auto_bright = 1;
iProcessor.imgdata.params.use_camera_wb = 0;
iProcessor.imgdata.params.use_auto_wb = 0;
// metadata is accessible through data fields of the class
nx = iProcessor.imgdata.sizes.width;
ny = iProcessor.imgdata.sizes.height;
// unpack the image
err = iProcessor.unpack();
if(err != 0)
goto error;
// process the image
err = iProcessor.dcraw_process();
if(err != 0)
goto error;
draw_emu w/o switches (-w -a) and/or Libraw API w/o use_camera_wb/use_auto_wb processes images with daylight WB
Line 16405 in ./configure provided with 0.20.2 (downloaded from this site) is empty.
Around this line are libjasper checks.
Also, there are no 'ZLIB,zlib' strings in provided configure script.
Have you re-generated ./configure (using, for example, autoreconf)?
AFAIK, Exiftool has large internal LensID => Lens name databases and uses Makernotes data for lookup.
thanks a lot!! I will be checking it ;)
Next LibRaw public snapshot (or 0.21 release, whatever comes first) will support EOS R5 camera.
ok, but we use libraw in https://bitbucket.org/agriggio/art/wiki/Home that's why I am asking so ART can develop CRAW files ;)
RawDigger works with Wine.
Hello,
Seems it's supported since last release, I could not try since I work in linux heheh
Changelog
RawDigger 1.4.2 (2020-09-24)
Camera support:
Canon EOS R5, R6
Please check if RawDigger https://www.rawdigger.com/download supports the files. If it doesn't, please e-mail us - info@libraw.org
Can I help somehow? providing samples or similar? let me know thanks
EOS R5 is not officially supported by LibRaw 0.20, here is supported camera list: https://www.libraw.org/supported-cameras
OK, thank you.
There is no 'Document mode' in dcraw_emu
unprocessed_raw and/or 4channels sample(s) may solve your task.
White level (data maximum) is not as easy as it should be.
LibRaw provides (estimated) data maximum in imgdata.color.maximum. This value is
- either hardcoded (this is derived from dcraw.c)
- or last item of linearization curve
- or determined using camera bit count
For many formats/vendors/settings it is correct, for others it is overestimated (for example, Panasonic low ISO w/ full-well limited sensor, also Canon's intermediate ISOs)
Also, there is imgdata.color.linear_max[]. If filled (nonzero) this value(s) represents vendor suggested white point parsed from metadata. This value is usually way too low (there are a lot of pixels above this threshold), but it is (yes) suggested by vendor.
Also, there are vendor-specific values in parsed metadata fields (e.g. canon.NormalWhiteLevel/canon.SpecularWhiteLevel)
There is no direct/accurate way in LibRaw 0.20
If you're ready to subclass LibRaw to own class to access protected fields (libraw_internal_data.unpacker_data) , use this method:
position to libraw_internal_data.unpacker_data.data_offset and read header (16 bytes), data version in 3rd byte of header (header[2]), it is 1 for lossless compression (supported) and 0 for unsupported lossy.
Alex,
Apologies for jumping the gun and reporting the issue in 0.20.0 as a bug. I just saw that my tests had failed and assumed a regression. But I agree that 0.20.0 behaviour is better.
I will upgrade to 0.20.2 for the updated raw-identify behaviour.
Regards,
Dinesh
BTW, I strongly suggest to update to 0.20.2. raw-identify in 0.20.0 may display rgb_cam incorrect.
I also think the new version is better.
That is why I do not understand why it was called incorrect.
Alex,
This file has four distinct sensors. However, when the multiplier for E is marked as 0, this would indicate that the E component is being discarded. Same with the rgb_cam having 0's for the E component.
I noticed that the cam_xyz is the same as the F828 entry in the adobe_coeff table is the same. This indicates there is a change in how the rgb_cam and hence the Daylight multipliers are derived in the code.
That being said, the 0.19.5 version has a very strong yellow cast on the image but the image definitely looks better in 0.20.0. Please find attached screenshots in the same drive location as above. I assume the 0.20.0 is the expected behaviour.
Regards,
Dinesh
Your message subject: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file
Could you please clarify why you call 0.20.x data 'incorrect'?
What values do you think are correct and why?
The file can be found below:
https://drive.google.com/drive/folders/1Bm-rfEpa6Ql-CtJFXJehtP51L9sjES9i...
Also, the filter pattern reported appears to be different (REGB vs ERBG) but I guess this is expected because the visible dimensions are different too.
Dinesh
Thanks,
Dinesh
Сould you please reformulate your question?
I cannot understand what exactly confuses you.
Pages