OK, Thanks for the explanation.
If you would write the formula to compute (estimate) the pixel pitch then, would you use raw_width or width ?
raw_width seems to be more the good one but for canon it gives result pretty far from the vendor value:
pitch = 22.3/6288 * 1000 = 3.55 (while it is given to be 3.7)
At the opposite, for the Sony it gives better result.
Single pixel size error in raw_width will result in distorted picture (like synchro loss on old analog TV), so raw_width/raw_height values are indeed right in LibRaw.
Visible (non masked) area is a matter of taste: LibRaw specifies 'as much as possible' (full visible area), while in-camera JPEGs (and, so, vendor advertized image size) may be slightly less than full area.
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.
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).
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.
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.
I don't see any practical sense in getting the exact pixel pitch value. Any approximated value is good enough
OK, Thanks for the explanation.
If you would write the formula to compute (estimate) the pixel pitch then, would you use raw_width or width ?
raw_width seems to be more the good one but for canon it gives result pretty far from the vendor value:
pitch = 22.3/6288 * 1000 = 3.55 (while it is given to be 3.7)
At the opposite, for the Sony it gives better result.
Not that easy :).
Single pixel size error in raw_width will result in distorted picture (like synchro loss on old analog TV), so raw_width/raw_height values are indeed right in LibRaw.
Visible (non masked) area is a matter of taste: LibRaw specifies 'as much as possible' (full visible area), while in-camera JPEGs (and, so, vendor advertized image size) may be slightly less than full area.
I would expect that the Sensor resolution width would match the raw_width, or the width value.
But I may be wrong.
For example
For Canon EOS 200D:
Sensor resolution width = 6026 pixels
Libraw:
width: 6022
raw_width: 6288
For Sony Alpha 7S:
Sensor resolution width = 4278 pixels
Libraw:
width: 4256
raw_width: 4288
What accuracy did you expect?
The resolution value, given in the link I gave you don't match with any field of libraw: width, iwidth nor raw_width.
Where I can find the explanation of the field ? ==1 (Canon APS-C?), == 2 (FF ?)
EDIT: I found it.
enum LibRaw_camera_formats
{
LIBRAW_FORMAT_APSC = 1,
LIBRAW_FORMAT_FF = 2,
LIBRAW_FORMAT_MF = 3,
LIBRAW_FORMAT_APSH = 4,
LIBRAW_FORMAT_1INCH = 5,
LIBRAW_FORMAT_FT = 8
};
Thanks Alex.
I will try this way.
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.
I don't think so, I would like the pixel pitch:
https://www.digicamdb.com/specs/canon_eos-200d/
imgdata.sizes.raw_width/raw_height are not enough?
Thanks a lot, that was what I was looking for.
Many thanks
imgdata.color.maximum variable holds maximum data range (this value is not black-level-subtracted)
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.
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).
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.
Thank you very much Alex ;-) !
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;
}
}
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
Ah thank you Alex, it was a bit confusing, but I guess this is due to my own assumptions ;-) ...
Kind regards,
Mabula
Yes, libraw imgdata.sizes.flip and tiff:Orientation tag are different.
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.
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.
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.
Thank you for your feedback and attention to details. Case closed.
Pages