Followup: the only format with linearization data applied after unpack() phase (within raw2image or dcraw_process()) is PhaseOne files (both compressed and uncompressed).
The tone curve for DNG files (Linearization Curve in DNG specs terms) is always applied on unpack() phase. There are no 'documented' options to turn this off (because RAW application always want to see linearized data), but you may use this trick:
LibRaw lr;
lr.open_file(filename);
// Replace tone curve read from metadata by linear one:
for(int i=0;i<0x10000;i++)
lr.imgdata.color.curve[i]=i;
// Do the unpack with linear curve:
lr.unpack();
This trick will work with data format with separate curve in metadata (all DNG files; Sony ARW2 format), but will not work with files where curve is calculated on unpack() phase (e.g. Nikon lossy NEF files).
Also please note, that raw2image() will skip 'masked pixels' (pixels outside of ActiveArea in DNG terms). To avoid this you may do the same trick: set imgdata.sizes.width and iwidth to raw_width and zero left_margin (and same with height, iheight and top_margin).
Followup: ABI/API changes will not break existing programs source compatibility. It is usual additional features we need. But you may need to recompile your code to adopt these changes.
We use current development version in our published apps (RawDigger, FastRawViewer).
It is stable in terms of program stability.
It is not stable in ABI/API terms, because internals may change without notifications
produces different results, as does the '-W' option (which is also enabled when using -4 option).
Could it be that there is still some kind of auto scaling enabled within dcraw_emu, because it brightens consequtive images differently some times, while dcraw does not.
According to raw-identify from LibRaw 0.16:
ISO speed: 320
Shutter: 24.7 sec
Aperture: f/6.4
Focal length: 28.0 mm
According to Exiftool 9.61:
== Exif section
F Number : 6.3
ISO : 320
Shutter Speed Value : 24.7
Aperture Value : 6.4
Focal Length : 28.0 mm
== Makernotes sections
Target Aperture : 6.3
Target Exposure Time : 25.4
Base ISO : 308
The values of Aperture: 22 and Focal Length: 24 are from lens limits section:
Max Focal Length : 105 mm
Min Focal Length : 24 mm
Min Aperture : 23 (real, not averaged)
From my point, LibRaw values are nearly correct (there are two Exposure time values, LibRaw shows Exif section, not Makernotes
Update:
document_mode is dropped from simple_dcraw (although help not changed, sorry) due to LibRaw internals change.
To get unprocessed raw data please use these LibRaw samples:
4channels - to get per-channel data in separate files
unprocessed_raw to get unprocessed raw data in 1-color bitmap.
This is already fixed in development branch (available at https://github.com/LibRaw/LibRaw ) in two ways
1) Internal LibRaw color profile is copied to imgdata.color.cam_xyz[] ever for DNG files.
2) For DNG files full DNG color data preserved in imgdata.color.dng_color[2] (if DNG contains two color matrices, then both matrices are preserved)
Thank you so much!
It is now clear for the NEF file. I need however to test if the problem comes from my IIQ picture...
I've check one more time and I still get a maximum value of 11040 for the 16bits data from the PhaseOne IQ180 (even if there's some white zones in the photograph).
Thanks to Alex, I'm now confident with the piece of code used, and I will investigate the problem in the settings of the digital back.
Another question:
is it a normal behavior to have different values for imgdata.color.maximum and max (the latter being computed by looping over the raw pixels)? Here is what I obtain:
max = 11040
iProcessor.imgdata.color.maximum = 64508
I can confirm his finding, it is in RGBA. This does not only impact dcraw_make_mem_image(), but it also breaks dcraw_ppm_tiff_writer! I am working on Linux 13.04 (libraw v 0.15-0Beta4)
I can also confirm this is *NOT* a problem in OSx 10.9 (libraw v 0.16.0).
I can now confirm this is an issue with <0.16 versions. Update to 0.16 and you are okay.
Followup: the only format with linearization data applied after unpack() phase (within raw2image or dcraw_process()) is PhaseOne files (both compressed and uncompressed).
The tone curve for DNG files (Linearization Curve in DNG specs terms) is always applied on unpack() phase. There are no 'documented' options to turn this off (because RAW application always want to see linearized data), but you may use this trick:
This trick will work with data format with separate curve in metadata (all DNG files; Sony ARW2 format), but will not work with files where curve is calculated on unpack() phase (e.g. Nikon lossy NEF files).
Also please note, that raw2image() will skip 'masked pixels' (pixels outside of ActiveArea in DNG terms). To avoid this you may do the same trick: set imgdata.sizes.width and iwidth to raw_width and zero left_margin (and same with height, iheight and top_margin).
Thanks! Sounds great.
Followup: ABI/API changes will not break existing programs source compatibility. It is usual additional features we need. But you may need to recompile your code to adopt these changes.
We use current development version in our published apps (RawDigger, FastRawViewer).
It is stable in terms of program stability.
It is not stable in ABI/API terms, because internals may change without notifications
Do you consider the current rev to be stable?
I do not understand your question.
If dcraw_make_mem_image() fails, it will return NULL.
Also, if you pass NULL to dcraw_clear_mem, it will do nothing.
So, what is the *real* problem?
No exact date for 'release'. You may use development trunk from GitHub: https://github.com/LibRaw/LibRaw
Thank you for the report. Flash data is parsed only for old Canon (CRW) files. To be added to EXIF parser section on the next update.
Thanks for the answer.
I`ve found that RawProcessor.imgdata.color.flash_used is always 0 even on photos when I use flash. Check this file https://dl.dropboxusercontent.com/u/7392238/Raw%20camera%20samples/P7312...
Canon CR2 files are lossless JPEG (Huffman) compressed. If raw data is damaged, you'll unable to correctly decompress data up to nex (L)JPEG sync tag.
I solved the problem
Thanks
Test:
(v. 0.16)
dcraw -4 -T filename.nef
dcraw_emu -4 -T filename.nef
produces different results, as does the '-W' option (which is also enabled when using -4 option).
Could it be that there is still some kind of auto scaling enabled within dcraw_emu, because it brightens consequtive images differently some times, while dcraw does not.
According to raw-identify from LibRaw 0.16:
ISO speed: 320
Shutter: 24.7 sec
Aperture: f/6.4
Focal length: 28.0 mm
According to Exiftool 9.61:
== Exif section
F Number : 6.3
ISO : 320
Shutter Speed Value : 24.7
Aperture Value : 6.4
Focal Length : 28.0 mm
== Makernotes sections
Target Aperture : 6.3
Target Exposure Time : 25.4
Base ISO : 308
The values of Aperture: 22 and Focal Length: 24 are from lens limits section:
Max Focal Length : 105 mm
Min Focal Length : 24 mm
Min Aperture : 23 (real, not averaged)
From my point, LibRaw values are nearly correct (there are two Exposure time values, LibRaw shows Exif section, not Makernotes
Thanks a lot for quick answer.
Update:
document_mode is dropped from simple_dcraw (although help not changed, sorry) due to LibRaw internals change.
To get unprocessed raw data please use these LibRaw samples:
4channels - to get per-channel data in separate files
unprocessed_raw to get unprocessed raw data in 1-color bitmap.
Latest versions of dcraw have changed much in document mode, LibRaw sample may be not up-to-date.
Please specify what kind of output do you want to receive and I'll provide you imgdata.params you need to set to get this mode from LibRaw.
Thanks, didn't know about the GitHub repository.
This is already fixed in development branch (available at https://github.com/LibRaw/LibRaw ) in two ways
1) Internal LibRaw color profile is copied to imgdata.color.cam_xyz[] ever for DNG files.
2) For DNG files full DNG color data preserved in imgdata.color.dng_color[2] (if DNG contains two color matrices, then both matrices are preserved)
For unprocessed (not demosaiced) image you may ignore G2 or average (G+G2)/2.
Processed image is RGB in most cases, just ignore 4th component.
Thank you so much!
It is now clear for the NEF file. I need however to test if the problem comes from my IIQ picture...
I've check one more time and I still get a maximum value of 11040 for the 16bits data from the PhaseOne IQ180 (even if there's some white zones in the photograph).
Thanks to Alex, I'm now confident with the piece of code used, and I will investigate the problem in the settings of the digital back.
Another question:
is it a normal behavior to have different values for imgdata.color.maximum and max (the latter being computed by looping over the raw pixels)? Here is what I obtain:
Thank you again.
D90 is 12-bit camera, so maximum possible value is 4096.
It may be slightly less if 'zero level' (bias) is subtracted by camera.
IQ180 is 16-bit, so maximum value should be 64k (and it is in my tests)
I can confirm his finding, it is in RGBA. This does not only impact dcraw_make_mem_image(), but it also breaks dcraw_ppm_tiff_writer! I am working on Linux 13.04 (libraw v 0.15-0Beta4)
I can also confirm this is *NOT* a problem in OSx 10.9 (libraw v 0.16.0).
I can now confirm this is an issue with <0.16 versions. Update to 0.16 and you are okay.
T
I can confirm this is an issue since it has been posted before: http://www.libraw.org/node/1865
the emulator works fine for me too. But my code is simple and still fails for half size and raw color. Maybe the dcraw make mem image function?
(...)
iProcessor.unpack();
// call for postprocessing utility
iProcessor.dcraw_process();
int check_makemem;
image = iProcessor.dcraw_make_mem_image(&check_makemem);
Mat image_rawRGB(cv::Size(image->width, image->height), rawBitDepthCV, image->data, cv::Mat::AUTO_STEP);
This gives out a mangled image if half size is on and raw colors..
Pages