Recent comments

Reply to: problem of decoding apple proRAW dng file   8 months 1 week ago

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

Reply to: Force Daylight WB?   8 months 1 week ago

Alternatively, one may use camera preset from imgdata.color.WB_Coeffs/WBCT_Coeffs if present for specific camera(raw file)

Reply to: Force Daylight WB?   8 months 1 week ago

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)

Reply to: Force Daylight WB?   8 months 1 week ago

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.

Reply to: Force Daylight WB?   8 months 1 week ago

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;

Reply to: Force Daylight WB?   8 months 1 week ago

draw_emu w/o switches (-w -a) and/or Libraw API w/o use_camera_wb/use_auto_wb processes images with daylight WB

Reply to: unexpected token `ZLIB,zlib,'   8 months 2 weeks ago

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)?

Reply to: Lens Make   8 months 3 weeks ago

AFAIK, Exiftool has large internal LensID => Lens name databases and uses Makernotes data for lookup.

Reply to: CRAW Canon EOS R5   8 months 4 weeks ago

thanks a lot!! I will be checking it ;)

Reply to: CRAW Canon EOS R5   8 months 4 weeks ago

Next LibRaw public snapshot (or 0.21 release, whatever comes first) will support EOS R5 camera.

Reply to: CRAW Canon EOS R5   9 months 3 hours ago

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 ;)

Reply to: CRAW Canon EOS R5   9 months 3 hours ago

RawDigger works with Wine.

Reply to: CRAW Canon EOS R5   9 months 3 hours ago

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

Reply to: CRAW Canon EOS R5   9 months 3 hours ago

Please check if RawDigger https://www.rawdigger.com/download supports the files. If it doesn't, please e-mail us - info@libraw.org

Reply to: CRAW Canon EOS R5   9 months 4 hours ago

Can I help somehow? providing samples or similar? let me know thanks

Reply to: CRAW Canon EOS R5   9 months 5 hours ago

EOS R5 is not officially supported by LibRaw 0.20, here is supported camera list: https://www.libraw.org/supported-cameras

Reply to: Canon 90D cr3 file command issue   9 months 1 week ago

OK, thank you.

Reply to: Canon 90D cr3 file command issue   9 months 1 week ago

There is no 'Document mode' in dcraw_emu

unprocessed_raw and/or 4channels sample(s) may solve your task.

Reply to: Determining 'Correctness' of white level values   9 months 1 week ago

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)

Reply to: Detect use of lossy compression in RAF   9 months 1 week ago

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.

Reply to: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file   9 months 1 week ago

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

Reply to: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file   9 months 1 week ago

BTW, I strongly suggest to update to 0.20.2. raw-identify in 0.20.0 may display rgb_cam incorrect.

Reply to: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file   9 months 1 week ago

I also think the new version is better.

That is why I do not understand why it was called incorrect.

Reply to: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file   9 months 1 week ago

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

Reply to: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file   9 months 1 week ago

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