Recent comments

Reply to: Force Daylight WB?   11 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?   11 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?   11 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?   11 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,'   11 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   11 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   11 months 3 weeks ago

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

Reply to: CRAW Canon EOS R5   11 months 3 weeks ago

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

Reply to: CRAW Canon EOS R5   11 months 3 weeks 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   11 months 3 weeks ago

RawDigger works with Wine.

Reply to: CRAW Canon EOS R5   11 months 3 weeks 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   11 months 3 weeks 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   11 months 3 weeks ago

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

Reply to: CRAW Canon EOS R5   11 months 3 weeks 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   1 year 1 hour ago

OK, thank you.

Reply to: Canon 90D cr3 file command issue   1 year 6 hours 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   1 year 1 day 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   1 year 4 days 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   1 year 5 days 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   1 year 5 days 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   1 year 5 days 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   1 year 5 days 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   1 year 6 days 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?

Reply to: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file   1 year 6 days ago

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

Reply to: Decompression file size(LabRaw_emu.exe)   1 year 1 week ago

Сould you please reformulate your question?

I cannot understand what exactly confuses you.

Pages