LibRaw do not care about in-camera crops like 16:9 and always returns full image.
So, if you want to completely repeat Adobe DNG convertor behavior, you need to parse Exif/makernotes metadata (and, possibly, add vendor-specific or camera-specific hints).
AFAIK, Adobe default cropping is because of
- let some space for demosaic (so ignore pixels very close to border)
- let some space for sensor positioning errors (seen in some cameras, within several pixels)
- also, physical masking may produce border effects (like diffraction) close to mask edge.
Thank you, that's very helpful. I'll go with LibRaw's sensor-size and ActiveArea then.
I actually care mostly about the DefaultCrop since that's what the users sees. I guess Adobe reads the final size from the MakerNotes (e.g., Sony has a FullImageSize tag) and then probably centers it in the ActiveArea. Will see if I can extract some of those with libexiv2.
To make it more complicated, there are also ImageWidth/Height Exif tags at least for Canon/Sony, which seem to also include user settings like 16:9 crop. Adobe (in DNG 1.4) interestingly translates that to DefaultUserCrop, which means the DNG includes 4 nested crops (sensor size, active area, default crop, default user crop)...
Unfortunately, there is no any 'system' in LibRaw margin (ActiveArea) size.
- some of values are derived from dcraw without change
- some of values are read from RAW metadata
- some of values are assigned by hand with 'maximum possible area' in mind.
For entire sensor size, Adobe DNG convertor crops sensor data for some cameras for unknown reason. Also, this cropping may change with DNG convertor version change (I've seen this at least on some Fuji cameras).
Sensor size is definitely right in LibRaw. Wrong raw_width will result in completely distorted image, wrong (too small) raw_height will result in buffer overrun.
Yes, LibRaw performs automatic maximum adjustment to prevent 'pink clouds' (and other highlights) problem seen on many cameras where real maximum varies with ISO or other camera settings.
To turn it off, use '-c 0' switch of dcraw_emu (or set imgdata.params.adjust_maximum_thr to 0.0).
raw_color is, indeed, to avoid color matrix multiplication in convert-to-rgb loop.
This flag is set not only in this ifdef, but in some other cases too (NikonScan files, Leaf HDR files)
Apologies I reversed the ifdef in my head, I should have pasted the else branch, it too sets the same variable, which appears to be part of the context of dcraw rather than the LibRaw code which is testing in convert_to_rgb_loop the value in the libraw_internal_data.internal_output_params.raw_color. I had imagined the intent was to avoid the matrix multiply when the matrix is unity.
Re subclassing - fine with me I'm probably going to combine that and some other code into a single pass over the memory as easy wins in performance.
Thanks for your efforts in producing the library much easier to use than the dcraw code direct.
You don't have to port you simple app on windows, it is simple enough and doesn't contain and system dependent part.
You should just download latest libraw binary and compile your app with proper toolchain (mignw or visual studio) and use proper include and library options during compilation (-I"your_libraw_include_path" -L"your_libraw_lib_path" -lraw options for mingw/gcc or "Additional Include directories" "Additional Library directories" and "Additional libraries" for Visual studio project settings)
This code is under #ifndef LIBRAW_LIBRARY_BUILD, so it is not compiled into LibRaw (because LibRaw is compiled with LIBRAW_LIBRARY_BUILD defined).
LibRaw's code snippet is mostly the same, but without document_mode into account. And it is not wrong.
Histogram: LibRaw calls convert_to_rgb_loop() virtual function. If you do not need histogram calculation, you may provide your own convert_to_rgb_loop() in derived class. The histogram is needed for automatic brightness correction (if used).
I am doing a project about raw file processing.I do not know how to use C++ to write source code to modifies some parameters of RAW file . I have thought about the question for days. Can you give me some suggestion about it.
Thank you!
There are two phases on raw processing:
- raw data decoding (decompressing)
- and postprocessing (black subtraction, white balance, demosaic, color conversion)
For Canon files, decoding is relatively slow, thanks for huffman compression used. RawSpeed is faster than LibRaw for these files (but you can use RawSpeed indirectly via LibRaw).
Postprocessing speed varies from method to method. For timelapse (e.g. video output in 1080p?) you don't need full resolution, so 'half' demosaic may be used.
The LibRaw's benchmark is 'samples/postprocessing-benchmark.cpp' which is included in LibRaw since v0.15
That should say I've added a #include < libraw.h > without the spaces but I guess it thought I was trying to add some kind of HTML tag
LibRaw do not care about in-camera crops like 16:9 and always returns full image.
So, if you want to completely repeat Adobe DNG convertor behavior, you need to parse Exif/makernotes metadata (and, possibly, add vendor-specific or camera-specific hints).
AFAIK, Adobe default cropping is because of
- let some space for demosaic (so ignore pixels very close to border)
- let some space for sensor positioning errors (seen in some cameras, within several pixels)
- also, physical masking may produce border effects (like diffraction) close to mask edge.
Thank you, that's very helpful. I'll go with LibRaw's sensor-size and ActiveArea then.
I actually care mostly about the DefaultCrop since that's what the users sees. I guess Adobe reads the final size from the MakerNotes (e.g., Sony has a FullImageSize tag) and then probably centers it in the ActiveArea. Will see if I can extract some of those with libexiv2.
To make it more complicated, there are also ImageWidth/Height Exif tags at least for Canon/Sony, which seem to also include user settings like 16:9 crop. Adobe (in DNG 1.4) interestingly translates that to DefaultUserCrop, which means the DNG includes 4 nested crops (sensor size, active area, default crop, default user crop)...
Unfortunately, there is no any 'system' in LibRaw margin (ActiveArea) size.
- some of values are derived from dcraw without change
- some of values are read from RAW metadata
- some of values are assigned by hand with 'maximum possible area' in mind.
For entire sensor size, Adobe DNG convertor crops sensor data for some cameras for unknown reason. Also, this cropping may change with DNG convertor version change (I've seen this at least on some Fuji cameras).
Sensor size is definitely right in LibRaw. Wrong raw_width will result in completely distorted image, wrong (too small) raw_height will result in buffer overrun.
Solved, now I'm able to get the exact match.
Thank you!
P.S. Please note -h key (half interpolation), because AHD interpolation is slightly different in LibRaw and dcraw.
For binary comparison, you may use -q 1 (VNG interpolation, same in LibRaw and dcraw).
To turn it off, use '-c 0' switch of dcraw_emu (or set imgdata.params.adjust_maximum_thr to 0.0).
Simple test:
raw_color is, indeed, to avoid color matrix multiplication in convert-to-rgb loop.
This flag is set not only in this ifdef, but in some other cases too (NikonScan files, Leaf HDR files)
Apologies I reversed the ifdef in my head, I should have pasted the else branch, it too sets the same variable, which appears to be part of the context of dcraw rather than the LibRaw code which is testing in convert_to_rgb_loop the value in the libraw_internal_data.internal_output_params.raw_color. I had imagined the intent was to avoid the matrix multiply when the matrix is unity.
Re subclassing - fine with me I'm probably going to combine that and some other code into a single pass over the memory as easy wins in performance.
Thanks for your efforts in producing the library much easier to use than the dcraw code direct.
Kevin
You don't have to port you simple app on windows, it is simple enough and doesn't contain and system dependent part.
You should just download latest libraw binary and compile your app with proper toolchain (mignw or visual studio) and use proper include and library options during compilation (
-I"your_libraw_include_path" -L"your_libraw_lib_path" -lrawoptions for mingw/gcc or "Additional Include directories" "Additional Library directories" and "Additional libraries" for Visual studio project settings)This code is under #ifndef LIBRAW_LIBRARY_BUILD, so it is not compiled into LibRaw (because LibRaw is compiled with LIBRAW_LIBRARY_BUILD defined).
LibRaw's code snippet is mostly the same, but without document_mode into account. And it is not wrong.
Histogram: LibRaw calls convert_to_rgb_loop() virtual function. If you do not need histogram calculation, you may provide your own convert_to_rgb_loop() in derived class. The histogram is needed for automatic brightness correction (if used).
LibRaw is definitely not the solution for your problem
I am doing a project about raw file processing.I do not know how to use C++ to write source code to modifies some parameters of RAW file . I have thought about the question for days. Can you give me some suggestion about it.
Thank you!
LibRaw opens files in read-only mode and never modifies file data.
Try to use exiftool (or other tools) to modify image metadata.
use imageProcessor.imgdata.params.no_auto_bright=1 before processing;
http://www.libraw.org/docs/API-datastruct-eng.html#libraw_output_params_t
Most likely you need Visual Studio runtime installed (or just copied into program folder)
Could you please explain your problem in more details?
There is no any runtime check to check demosaic pack compiled in.
Make sure that you compile LibRaw with LIBRAW_DEMOSAIC_PACK_GPL2 and LIBRAW_DEMOSAIC_PACK_GPL3 defines.
There are two phases on raw processing:
- raw data decoding (decompressing)
- and postprocessing (black subtraction, white balance, demosaic, color conversion)
For Canon files, decoding is relatively slow, thanks for huffman compression used. RawSpeed is faster than LibRaw for these files (but you can use RawSpeed indirectly via LibRaw).
Postprocessing speed varies from method to method. For timelapse (e.g. video output in 1080p?) you don't need full resolution, so 'half' demosaic may be used.
The LibRaw's benchmark is 'samples/postprocessing-benchmark.cpp' which is included in LibRaw since v0.15
Any news on this? At least i confirm something's up with tiles, also in CA_correct_RT.cc,
`#define TS 256 // Tile sizez
Worked great alex, you're the man. No problem, you need to make a donation button somewhere, i'd get your some coffee ;).
Actual camera list is returned by LibRaw::cameraList() call (http://www.libraw.org/docs/API-CXX-eng.html#cameraList )
There is no list on site, because the list updates frequently (if you use development branch), also actual list depends on actual version you use.
Nikon D610 is supported in LibRaw 0.16, D750 in 0.17(-Alpha1)
Also, to use LibRaw as library you definitely need to spend 'more than minute'.
Sure, I mean to say -c 0:
-c float-num Set adjust maximum threshold (default 0.75)
Sorry for inconvenience, I need to sleep more :)
Hi Alex, Thanks. But:
Tims-:bin tzaman$ ./dcraw_emu -T -w -W -e 0 /Volumes/TZ_USB3_32G/*.nef
Unknown option "-e".
Tim:bin tzaman$ ./dcraw_emu -T -w -W -e /Volumes/TZ_USB3_32G/*.nef
Unknown option "-e".
edit 1
Although i think you meant to say '-W'. This should turn auto brightening off, but it clearly does not for my images.
edit 2
Did you mean to say '-c 0' ?
Followup: maximum values in two files are differ: 12335 and 14213 in G1 channel. May be hotpixel, may be just signal variation
Pages