Recent comments

Reply to: Get Pixel dimensions   2 months 1 week ago

Thanks Alex.
I will try this way.

Reply to: Get Pixel dimensions   2 months 1 week ago

For many (but not all) cameras LibRaw parses sensor physical size type (full frame, APS-C) into imgdata.lens.makernotes.CameraFormat

You may use this field and pixel dimensions (raw_width, raw_height) to estimate pixel pitch.

Reply to: Get Pixel dimensions   2 months 1 week ago

I don't think so, I would like the pixel pitch:
https://www.digicamdb.com/specs/canon_eos-200d/

Reply to: Get Pixel dimensions   2 months 1 week ago

imgdata.sizes.raw_width/raw_height are not enough?

Reply to: Is there a way to know it DSLR is 12 or 14bits   2 months 2 weeks ago

Thanks a lot, that was what I was looking for.
Many thanks

Reply to: Is there a way to know it DSLR is 12 or 14bits   2 months 2 weeks ago

imgdata.color.maximum variable holds maximum data range (this value is not black-level-subtracted)

Reply to: Is there a way to know it DSLR is 12 or 14bits   2 months 2 weeks ago

OK, sorry for this dummy question indeed.
So my question is now how libraw know the constant factor to apply to normalize to 16bits ?
Sorry if it is a dummy question again.

Reply to: Is there a way to know it DSLR is 12 or 14bits   2 months 2 weeks ago

Could you please explain 12 vs 14 bit difference for Sony cRAW format:

1) Data stored in 8-bit per pixel overall (16-pixel blocks, 11-bit base value, 7-bit deltas)
2) After decompression: 11 bit non-linear data
3) After linearization curve applied: ??bit data with data range 0...~17000

File format is the same for 12-bit ADC cameras (e.g. A700), real 14-bit ADC (e.g. Sony A7r) and 14-bit ADC in 12-bit mode (A7R in electronic shutter mode).

Reply to: Edit EXIF data using external library   2 months 3 weeks ago
Is this possible with the current code?

I do not know. Please try and let us know

is recommended to use LibRaw::open_buffer() to open file or better to use directly LibRaw::open_datastream()
Both ways should work.

Reply to: LibRaw (dcraw?) orientation tag wrong?   3 months 2 days ago

Thank you very much Alex ;-) !

Reply to: LibRaw (dcraw?) orientation tag wrong?   3 months 2 days ago

And followup:

dcraw_emu/dcraw.c also accepts user_flip in degrees (e.g. 90, 270, or -90), to handle this too, add these lines before snippet in previous message:

if (flip > 89 || flip < -89)
{
flip = (flip + 720) % 360;
switch (flip)
{
case 90: return 6;
case 180: return 3;
case 270: return 8;
default: return 1;
}
}

Reply to: LibRaw (dcraw?) orientation tag wrong?   3 months 2 days ago

Here is small code snippet that may help you in flip->orientation conversion:

int arr[10] = { 1, 1, 2, 4, 3, 5, 8, 6, 7, 1 };
return arr[qBound(0, flip + 1, 9)]; // add 1 and set limit to 9 to handle out of range values

Reply to: LibRaw (dcraw?) orientation tag wrong?   3 months 2 days ago

Ah thank you Alex, it was a bit confusing, but I guess this is due to my own assumptions ;-) ...

Kind regards,
Mabula

Reply to: LibRaw (dcraw?) orientation tag wrong?   3 months 2 days ago

Yes, libraw imgdata.sizes.flip and tiff:Orientation tag are different.

Reply to: CMYK Raw Image Data   3 months 2 weeks ago

OK, opened it in phothoshop.
I do not see 2x2 patterns (typical for bayer CFA). If non-bayer CFA is used, than LibRaw/FRV Custom Camera would not help, it targeted for bayer CFA only.

Reply to: CMYK Raw Image Data   3 months 2 weeks ago

The file sample you provide *mostly* contains 0xFF bytes (not all bytes are 0xff, but ~62% from beginning is).

It is not easy to analyze such samples, do you have another one (with some image with well-known object with known non-neutral colors).

Generally, CustomCamera may work for FRV, but we need known colors to guess CFA.

Reply to: LibRaw 0.19.2-Release   3 months 3 weeks ago

I've now checked also images from the 800D and 77D models:
DNG-Converter converts to 6024x4022, and DCRAW reports 6024x4020.

And I found that with both models the additional top rows of the DNGs are black!
So the correct size seems to be 6024x4020.
Since there is no chance to have a common and correct size, I think it might be the best to not change anything.

Reply to: LibRaw 0.19.2-Release   3 months 3 weeks ago

Thank you for your feedback and attention to details. Case closed.

Reply to: guidance needed to improve image quality   3 months 4 weeks ago

I'm afraid it's more basic than magic.

Reply to: guidance needed to improve image quality   3 months 4 weeks ago

Thanks. That's what I needed to know. I feared there was some magic I was missing.

Reply to: guidance needed to improve image quality   4 months 1 hour ago

Typical today raw converter (e.g. Adobe's and/or in-camera JPEG generator, I'm not familiar with rawtherapee) applies S-shaped curve (with different parameters for different cameras/different ISO setting on same camera/different other setting e.g. DLO on Nikon cameras).
LibRaw/dcraw default rendering does histogram shift to the right only.

Here is your sample with +1 correction with highlights compression: https://www.dropbox.com/s/fsimdf5alou55qy/Screenshot%202019-01-25%2020.2...

Reply to: guidance needed to improve image quality   4 months 2 hours ago

Are you saying that 03.nef is underexposed and the dcraw rendering is normal?
Then the question remains, how did rawtherapee know how to compensate?

Here is a Sony A7 raw, the corresponding 'out of the camera' jpeg, and renderings by dcraw and rawtherapee:
https://kornelix.net/downloads/DSC00574.ARW
https://kornelix.net/downloads/out-of-the-camera.jpg
https://kornelix.net/downloads/dcraw.tif
https://kornelix.net/downloads/rawtherapee.tif

The rawtherapee rendering and the 'out of the camera' jpeg are nearly identical, whereas the dcraw rendering is too dark. Is this normal and expected? (my libraw implementation gives the same result as dcraw).

commands:
dcraw -w -T DSC00574.ARW
rawtherapee-cli -t -b8 -d -c DSC00574.ARW

Source web page for the above raw and jpeg:
https://www.dpreview.com/sample-galleries/6769434587/sony-a7-iii-sample-...

Reply to: guidance needed to improve image quality   4 months 4 hours ago

The second one (_03.nef) is underexposed: https://www.dropbox.com/s/2jmz4niipiv552v/Screenshot%202019-01-25%2017.4...
(gray square on girl's cheek is RawDigger sample, average green/red is ~5EV below saturation point).

After exposure correction the image is more-or-less OK: https://www.dropbox.com/s/g76re8v887rnfen/Screenshot%202019-01-25%2017.4...

Reply to: guidance needed to improve image quality   4 months 4 hours ago

Yes the 1st one is not bad, only a small loss in color.
Please check the 2nd one.

Reply to: guidance needed to improve image quality   4 months 5 hours ago

Checked the 1st one:

dcraw -w -T (and irfanview screenshot of resulting tiff file): https://www.dropbox.com/s/ynkb94latus6n55/Screenshot%202019-01-25%2017.0...

Embedded JPEG viewed via FastRawViewer: https://www.dropbox.com/s/wbc4ifjizd9dzm4/Screenshot%202019-01-25%2017.0...

This is screnshots from screen, so in (my) display colorspace (near-sRGB)

I do not see any big problems here, although LibRaw's color profile may differ from Nikon's one

Pages