Current public snapshot supports Nikon Z6 and Z7, sorry these cameras was missed from release announce
When the Nikon z6 z7 release the firmware？
Sony A7-3 is supported in current snapshot: https://www.libraw.org/news/libraw-snapshot-201903
EOS-R support is expected in next snapshot/release, whatever comes first.
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.
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 Canon EOS 200D:
Sensor resolution width = 6026 pixels
For Sony Alpha 7S:
Sensor resolution width = 4278 pixels
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.
LIBRAW_FORMAT_APSC = 1,
LIBRAW_FORMAT_FF = 2,
LIBRAW_FORMAT_MF = 3,
LIBRAW_FORMAT_APSH = 4,
LIBRAW_FORMAT_1INCH = 5,
LIBRAW_FORMAT_FT = 8
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:
imgdata.sizes.raw_width/raw_height are not enough?
Thanks a lot, that was what I was looking for.
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 ;-) !
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;
case 90: return 6;
case 180: return 3;
case 270: return 8;
default: return 1;