DNG format is TIFF format + some additional tags.
So your options are:
- Adobe DNG SDK
- libtiff (you'll need to add tags using libtiff calls)
- plain write w/o addional libraries.
In this specific case LibRaw/dcraw_emu works better (more correctly) than dcraw.
This is especially true for DNG files with multiple sub-images and different color data (e.g. DNG w/ fast-load JPEG data): LibRaw/dcraw will select correct matrix, while dcraw will always use the last one.
dcraw parses DNG tags one-by-one, in order (in file being processed), both ColorMatrix1 and ColorMatrix2 tags are parsed into same (cmatrix) structure. So, latest one wins.
LibRaw w/ default settings (without LIBRAW_PROCESSING_DONT_CHECK_DNG_ILLUMINANT flag) analyzes CalibrationIlluminant1/2 tags too and selects color matrix which is closer to D65/daylight.
Usually (e.g. files created by Adobe DNG SDK) the last matrix is the one that corresponds to daylight (resulting in same dcraw/dcraw_emu results), but not in this specific file (CameraMatrix1 => D65, CameraMatrix2 => Ill.A).
So, LibRaw is right in this specific case, while dcraw is not.
(dcraw is *much* worse if DNG file contains multiple sub-images w/ different color data).
Thank you Alex,
but is the coordinate with or without the border?
If it's with border, is the border always the same size left/right and top/bottom. So the "real" picture is always centred?
And where is the viewport? Is it at top/left or bottom/left or even somewhere else?
Thanks once again!
I do not think that fallback to older model is safe. Newer camera may have different sensor, or different CFA filters, or different calibration, or different raw adjustments in firmware. You could not know it without new raws analysis.
Finally: old DNG SDK 1.4 (dated May 2012) is *not* compatible with LibRaw. Internals of dng_info are very different in May 2012 and June 2015 versions, the older one does not have fChainedSubIFD array.
Implementing support for older version is just a big time waste: it will require lot of testing (already done for modern DNG SDK version) and no benefits.
So, you'll need to go second route (via patched modern DNG SDK 1.4), the DNG SDK provided w/ GPR SDK will not fit.
Hello Alex,
Thanks a lot for your job about LibRaw and FastRawViewer !
To solve my problem of using libraw librairy in Windows8.2 / Qt / C++ / MingW64, and according to your answer ( if i understand well )
i just done this :
> mingw32-make - f Makefile.mingw
This create the librairy : libraw.a with my mingw compiler 64 bits
libraw.a is 1183 ko in /lib folder.
In my minimal project !
i declare the librairy, and the Include/header and try to use it : As above in my first message
LibRaw *processor = new LibRaw ;
processor->open_file("C:/Test.cr2") ;
When i compile i still have errors like ; undefined reference to symbols...
I don't understand what is wrong with the linking.
1) GPR SDK includes Adobe DNG SDK v1.4 dated May 2012 (according to $datetime in comments).
In this version, dng_info's fIFD and fChainedIFD are AutoPtr arrays of fixed size.
2) In Adobe DNG SDK v1.4 dated June 2015, same fields are std::vector
This is very minor change, it should be easy to adopt, but I do not see any way to distinguish two SDKs at compile time.
It could be selectable by user w/ additional #define (like USE_OUTDATED_DNG_SDK :)
We'll try to solve this problem in beta update (need some time to set-up testbed with outdated DNG SDK included w/ GPR).
Current LibRaw (w/ ability to extract any DNG subframe via shot_select option) relies on DNG SDK 1.4 internals, it is not compatible w/ DNG SDK included into GPR SDK.
Looks like we need to update README.GoPro by removing this option:
I. GPR SDK comes with (patched) Adobe DNG SDK source. You may use this DNG SDK instead of
Adobe's one, or use standard Adobe's distribution.
Yes but... if I just use raw_image I only get a 2D array back.
If I need colour channels I need to manually demosaic?
You do not need postprocessing step(s) if you want to analyze unaltered raw data
Some examples of `light` DNG creation tools:
http://a1ex.magiclantern.fm/bleeding-edge/pgm2dng.c (needs a few more files from CHDK)
https://github.com/fastvideo/pgm2dng
LibRaw only reads files, not writes.
DNG format is TIFF format + some additional tags.
So your options are:
- Adobe DNG SDK
- libtiff (you'll need to add tags using libtiff calls)
- plain write w/o addional libraries.
Thanks a lot Alex !
It work well now !
Lucien
You need this only for Microsoft or Intel compilers. For others LIBRAW_WIN32_DLLDEFS is not defined automatically.
For the static library, you must define LIBRAW_NODLL when compiling programs that link to it.
In this specific case LibRaw/dcraw_emu works better (more correctly) than dcraw.
This is especially true for DNG files with multiple sub-images and different color data (e.g. DNG w/ fast-load JPEG data): LibRaw/dcraw will select correct matrix, while dcraw will always use the last one.
Thanks for your reply!
Yes, I've done a side-by-side debug run of dcraw and LibRaw example, and I've found the divergence point.
Can dcraw_emu be used as a replacement of dcraw, or it is just an example program that is not intended for everyday use?
dcraw parses DNG tags one-by-one, in order (in file being processed), both ColorMatrix1 and ColorMatrix2 tags are parsed into same (cmatrix) structure. So, latest one wins.
LibRaw w/ default settings (without LIBRAW_PROCESSING_DONT_CHECK_DNG_ILLUMINANT flag) analyzes CalibrationIlluminant1/2 tags too and selects color matrix which is closer to D65/daylight.
Usually (e.g. files created by Adobe DNG SDK) the last matrix is the one that corresponds to daylight (resulting in same dcraw/dcraw_emu results), but not in this specific file (CameraMatrix1 => D65, CameraMatrix2 => Ill.A).
So, LibRaw is right in this specific case, while dcraw is not.
(dcraw is *much* worse if DNG file contains multiple sub-images w/ different color data).
Thanks for the quick reply!
imgdata.image is already cropped to visible area.
Thank you Alex,
but is the coordinate with or without the border?
If it's with border, is the border always the same size left/right and top/bottom. So the "real" picture is always centred?
And where is the viewport? Is it at top/left or bottom/left or even somewhere else?
Thanks once again!
coordinate is (y * width) + x (unless you use half_size option).
Values in imgdata.image array are 16 bit/linear space, IrfanView values are, most likely, 8bit/gamma corrected.
I do not think that fallback to older model is safe. Newer camera may have different sensor, or different CFA filters, or different calibration, or different raw adjustments in firmware. You could not know it without new raws analysis.
Alex,
I have removed any .dll or . a librairy before compiling.
Just i use libraw.a as soon as created
( I am probably a dummy with librairies )
In my project just i have this :
INCLUDEPATH += C:\LibRaw-0.19.5\libraw
LIBS += -LC:\LibRaw-0.19.5\lib -llibraw.a
and :
#include
I have still the trouble with static library. but '.exe' files in /bin work well !.
Lucien
Finally: old DNG SDK 1.4 (dated May 2012) is *not* compatible with LibRaw. Internals of dng_info are very different in May 2012 and June 2015 versions, the older one does not have fChainedSubIFD array.
Implementing support for older version is just a big time waste: it will require lot of testing (already done for modern DNG SDK version) and no benefits.
So, you'll need to go second route (via patched modern DNG SDK 1.4), the DNG SDK provided w/ GPR SDK will not fit.
Readmes are updated to reflect this.
make sure you're linking with (newly created) libraw.a, not (older) libraw.dll
Hello Alex,
Thanks a lot for your job about LibRaw and FastRawViewer !
To solve my problem of using libraw librairy in Windows8.2 / Qt / C++ / MingW64, and according to your answer ( if i understand well )
i just done this :
> mingw32-make - f Makefile.mingw
This create the librairy : libraw.a with my mingw compiler 64 bits
libraw.a is 1183 ko in /lib folder.
In my minimal project !
i declare the librairy, and the Include/header and try to use it : As above in my first message
LibRaw *processor = new LibRaw ;
processor->open_file("C:/Test.cr2") ;
When i compile i still have errors like ; undefined reference to symbols...
I don't understand what is wrong with the linking.
Thanks Alex,
Lucien
Btw, mingw-w64 binaries for libraw are already available through msys2 and easily installable with pacman: https://packages.msys2.org/base/mingw-w64-libraw
Followup:
1) GPR SDK includes Adobe DNG SDK v1.4 dated May 2012 (according to $datetime in comments).
In this version, dng_info's fIFD and fChainedIFD are AutoPtr arrays of fixed size.
2) In Adobe DNG SDK v1.4 dated June 2015, same fields are std::vector
This is very minor change, it should be easy to adopt, but I do not see any way to distinguish two SDKs at compile time.
It could be selectable by user w/ additional #define (like USE_OUTDATED_DNG_SDK :)
We'll try to solve this problem in beta update (need some time to set-up testbed with outdated DNG SDK included w/ GPR).
Right now we've updated DNG/GPR readme files only: https://github.com/LibRaw/LibRaw/commit/d86f980a5c7d30e7d553156861a108e1...
LibRaw dll coming with binary distributions is built using MS Visual Studio.
It is very likely that C++ name mangling (AND C++ library too!) is not compatible with gcc/MinGW.
You need to rebuild LibRaw using your compiler (Makefile.mingw should help)
Thank you for the feedback.
Current LibRaw (w/ ability to extract any DNG subframe via shot_select option) relies on DNG SDK 1.4 internals, it is not compatible w/ DNG SDK included into GPR SDK.
Looks like we need to update README.GoPro by removing this option:
I. GPR SDK comes with (patched) Adobe DNG SDK source. You may use this DNG SDK instead of
Adobe's one, or use standard Adobe's distribution.
We do not use mkdist/configure internally, but cloned (not commited) Makefile.devel
mem_image_sample problem fixed in this patch: https://github.com/LibRaw/LibRaw/commit/253f7ac76d03163497019302e3d1f967...
Pages