Hello,
I'm experimenting with DNG images loading. I'm using LibRaw and I'm trying to achieve the same result as with dcraw processing, but I can't. White balance is different (see. image in the attachement).
dcraw command I'm using (it's dcraw 9.26 built from the source code):
dcraw -h sunset.dng
dcraw_emu command (it's LibRaw 0.20 built from the sources):
dcraw_emu -h -c 0 sunset.dng
Source image: sunset.dng
dcraw result: sunset_dcraw.ppm
dcraw_emu result: sunset_emu.ppm
Could it be that LibRaw and dcraw uses different default white balance settings? For example, different illuminants?
| Attachment | Size |
|---|---|
 Comparison of the processing results | 227.78 KB |
dcraw parses DNG tags one-by
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).
-- Alex Tutubalin @LibRaw LLC
Thanks for your reply!
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?
In this specific case LibRaw
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.
-- Alex Tutubalin @LibRaw LLC