Hello,
I'm using DCRAW to import RAWs into a software for the purpose of astro image processing. Actually I'm going to migrate to LibRaw for this purpose.
A problem I face thereby is related to some optimisations I implemented in the DCRAW processing sequence. These optimisations dramatically speed up the conversion for many of the frequently used formats like CR2 and the special needs of astro image processing.
My typical processing route leaves the DCRAW sequence after executing (*load_raw)() and selectively calls original or modified DCRAW functions depending on the RAW format and user options.
When I was looking into the LibRaw sources and examples I found that there are several differences between the original DCRAW and LibRaw::dcraw_process() which might make it quite laborious to transfer my adaptions from DCRAW to LibRaw. Therefore, as a first step, I plan to not replace DCRAW by LibRaw completely. Instead, I want to use LibRaw until LibRaw::unpack() and thereafter use my code with as few changes as possible.
Do you think this approach îs feasible and reasonable, or are there some pitfalls I overlooked?
Can I reconstruct all the DCRAW data structures from their LibRaw equivalents (without too much effort)? Or is there even some sample code doing that?
Erwin
Although most functions in
Although most functions in LibRaw/internal/dcraw_common.cpp looks like untaltered dcraw.c code, this is not completely true.
Data layout in LibRaw is different and old (dcraw's) variables are #define-d in internal/var_defines.h
You may try this approach:
1) Subclass LibRaw:
2) Implement own dcraw_process() (with different function name) and build it using dcraw/libraw functions (pre_interpolate(), scale_colors(), etc)
-- Alex Tutubalin @LibRaw LLC
Ok, "internal/var_defines.h"
Ok, "internal/var_defines.h" exactly is what I was looking for.
Can I presume that the meaning of the defined variables is unchanged?
Thanks a lot, Erwin
Currently, no plans to change
Currently, no plans to change present data layout.
You can re-use internal/var_defines.h with your code, so it will remain in agreement with new versions even if data fields will change.
-- Alex Tutubalin @LibRaw LLC
I have now ported my code to
I have now ported my code to work with LibRaw and most things worked fine instantly.
Up to now there have been only 2 issues I'd like to report:
1.) I had to
#define _WINSOCK2API_
before
#include "libraw\libraw.h"
in order to prevent winsock.h and winsock2.h being included both. (Looks like winsock.h is included somewhere else in one of my headers, but I couldn't locate where.)
2.) On calling convert_to_rgb() right after scale_colors() and pre_interpolate() an exception was thrown because the histogram buffer was not allocated.
I'm no going to build LibRaw_static.lib (with VS 2017). Thereby, I would like to include RawSpeed, since I often work with Canon CR2 Raws. Is there a recipe how to do this on Windows?
Erwin
2: yes, histogram is
2: yes, histogram is dynamically allocated (in dcraw_process()), to reduce size of LibRaw class sizeof()
RawSpeed:
- use 'master' (very old!) RawSpeed from https://github.com/klauspost/rawspeed/tree/master
(not the current one from darktable, current version does not compile with MSVC)
- Working recipe described in https://github.com/LibRaw/LibRaw/blob/master/README.RawSpeed.txt
-- Alex Tutubalin @LibRaw LLC
Looks like I would need to
Looks like I would need to include RawSpeed as a DLL, right? Has anybody ever tried to replace the DCRaw CR2 decompressor (lossless_jpeg_load_raw(), I guess) by the one from RawSpeed?
Another thing: I noticed that I couldn't readout the Canon sensor temperature (which is important for long exposure dark subtraction) by use of set_exifparser_handler(), because the sensor temp appears in parse_makernote(), where the EXIF callback is not called. For the moment I solved this by inserting this callback in parse_makernote() in dcraw_common. May I suggest to either do so too in future versions, or to readout the sensor temperature to imgdata.makernotes.canon?
Yes, RawSpeed is LGPL2
Yes, RawSpeed is LGPL2 licensed, that means (at least, in common interpretation) that you need it as separate DLL (or LibRaw+RawSpeed as single DLL).
lossless_jpeg_load_raw() in LibRaw/dcraw is completely different from RawSpeeds. It handles all ljpeg formats at once, while RawSpeed has separate code (subclassing/using own common decoder) for different vendors. LibRaw+RawSpeed combo works perfect now (although we've blacklisted some cameras in LibRaw::unpack()), so why do backport?
'RawSpeed2' testing is in progress now (just managed to get it working under Windows), so I expect support in next snapshot/release.
Sensor temp: could you please provide your patch to backport into LibRaw (my E-mail: lexa@lexa.ru)
-- Alex Tutubalin @LibRaw LLC
RawSpeed2 support in next
RawSpeed2 support in next snapshot/release sounds good - I'll wait for it.
Many thanks, Erwin
Camera/sensor temperature
Here is the patch: https://www.dropbox.com/s/6ku6scc9ar33nr0/canon-oly-temperature.patch?dl=0
(against 0.19-20170812 snapshot, https://www.libraw.org/news/libraw-0-19-snapshot-20170812)
This patch supports Canon and Olympus cameras, more is on the way.
Camera/Sensor themperatures are in (added) imgdata.other.*Temperature fields (in Celsius)
These fields are inited to -1000 at open_file() start, so check values against >-1000 (or >= -273 :) before use.
-- Alex Tutubalin @LibRaw LLC
I was absent for some days
I was absent for some days but now I have tested the temperature patch and can report that for my EOS 1100D the result is equal to what I extracted myself from the maker notes.
An additional information I can supply is that at least for the 1100D, but probably also for the other, more recent EOS models, this EXIF temperature is the true sensor temperature. For the 1100D I'm very sure about this and also for the 5D-MkII there is strong indication therefore.
Erwin