Not sure how the compatibility works, but I own a Sony A7 III and a Canon EOS R. If I can scrape any data to help add each of those to the support list, I'd be glad to try.
The only way to get the accurate number for that is to look it up in the sensor data sheet. Raw file may contain virtual pixels, and may not contain all the physical pixels.
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).
Not sure how the compatibility works, but I own a Sony A7 III and a Canon EOS R. If I can scrape any data to help add each of those to the support list, I'd be glad to try.
Mhhh ok.
So I will keep my estimation using sizes.width I guess.
The only way to get the accurate number for that is to look it up in the sensor data sheet. Raw file may contain virtual pixels, and may not contain all the physical pixels.
In astrophotography, Pixel size is a value often needed ;).
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.
Pages