1) This is 'linear DNG' (demosaiced) with 12 bit data
| | 3) BitsPerSample = 12 12 12
So, expected 'real max' value is 4095. In reality it is 4136, that's why LibRaw's decoder warns about data corruption (data value is outside manifested limit)
2) unprocessed_raw sample supports only bayer (not demosaiced) files right now, so you may need to write some code
After LibRaw::open_file() and LibRaw::unpack(), the (unprocessed) data is accessble via
-imgdata.rawdata.color3_image as an array of 3-component pixels
or
- imgdata.rawdata.color4_image as an array of 4-component pixels (for 3-color DNG, 4th component will be always zero)
Only one pointer is not NULL, check before use.
Historically, Adobe DNG SDK fills colr3_image array, but libraw internal decoder(s) use color4_array
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.
1) This is 'linear DNG' (demosaiced) with 12 bit data
| | 3) BitsPerSample = 12 12 12
So, expected 'real max' value is 4095. In reality it is 4136, that's why LibRaw's decoder warns about data corruption (data value is outside manifested limit)
2) unprocessed_raw sample supports only bayer (not demosaiced) files right now, so you may need to write some code
After LibRaw::open_file() and LibRaw::unpack(), the (unprocessed) data is accessble via
-imgdata.rawdata.color3_image as an array of 3-component pixels
or
- imgdata.rawdata.color4_image as an array of 4-component pixels (for 3-color DNG, 4th component will be always zero)
Only one pointer is not NULL, check before use.
Historically, Adobe DNG SDK fills colr3_image array, but libraw internal decoder(s) use color4_array
Alternatively, one may use camera preset from imgdata.color.WB_Coeffs/WBCT_Coeffs if present for specific camera(raw file)
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?
Pages