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
// open the file and read the metadata
err = iProcessor.open_file(pathname);
if(err != 0)
// 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)
// process the image
err = iProcessor.dcraw_process();
if(err != 0)
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.
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 ;)
Seems it's supported since last release, I could not try since I work in linux heheh
RawDigger 1.4.2 (2020-09-24)
Canon EOS R5, R6
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
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), it is 1 for lossless compression (supported) and 0 for unsupported lossy.
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.
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.
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.
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:
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.