RawSpeed team is focused mostly on code rewrite and cleanup and on correct handling of corner cases (e.g. fuzzer testing, etc). This is very important work, but in reality users of RAW processing software usually feeds it by files created by cameras, but not random crap generated by fuzzer.
On the other side, the real issue with real files created by real camera is not fixed for 10 months: https://github.com/darktable-org/rawspeed/issues/100 (is this library really *maintained* ?)
So, I'm somewhat skeptical about current RawSpeed state. It has very strong features (e.g. LJPEG decoder is really ~30% faster on Canon 5Ds files, this is vital for apps build for speed /like our FastRawViewer/), but focusing on 'pure software development process' (code cleanup, modern C++ rewrite, fuzzer testing) instead of handling real issues is, at least, questionable from my point of view.
Most likely, we'll support 'RawSpeed devel' (do not know exact version is it v3 or v4 now) in LibRaw after 0.19 release (so, this year).
Very probable, that support will use some 'whitelisting', so only known/tested camera files to be passed to RawSpeed decoder (and, sure, this list will be empty by default).
P.S. RawSpeed has imported our (LibRaw) compressed fuji decoder and provided feedback was very useful, we fixed two (or so) corner cases based on it.
RawSpeed is maintained here now: https://github.com/darktable-org/rawspeed There have been new versions and changes to the code. Is this something LibRaw supports currently? If not, does it make sense to add support?
Yes, camera profiles are already camera-RGB-to-sRGB, so matrix mentioned does not matter in color space conversion. It is used only in output profile calculations (this profile is embedded into TIFF files recorded by dcraw_ppm_tiff_writer())
To match camera JPEG colors you need to use same (in-camera) color profile and tonal (contrast) curve.
No. Only full-size and half-size (for bayer). Or cropped.
Does dcraw_emu have any option to resize the output other than -h, with the caveats as you described?
Nice to know you and glad to know you had a team to handle the growing up of Libraw. I have some questions about Libraw team's operation and further update plan. If you don't mind, can you share your E-mail for having more detail discussion? Or you can contact me through "email@example.com", thx.
That worked like a charm! : )
make -f Makefile.dist should do the trick
(or longer way:
but you need to have autotools installed for autoreconf)
I would like to experiment with the latest 0.19 versions of LibRaw. I already use the latest precompiled 0.18 version but I need the Fuji-X compressed RAW's support.
Could someone of the LibRAW team tell me how to compile the snapshot on my macOS High Sierra?
I have XCode installed, but the source code doesn't even have the configure.sh script.
Thanks in advance,
The -h option is only suitable for bayer-patter files.
If the file is not bayer-mosaiced, or demosaiced by some intermediate software (linear DNG), -h is omitted
I'm a new member and just joined this group today. I follow up the Libraw a while ago and noticed it's based on the "DCRaw" to extend the capability. I have a question and expect someone can answer to me. As I know, DCRaw didn't have an update over two years. But I can see some new Camera Model which not be supported by DCRaw but is available in Libraw 0.19 snapshot version. Can someone tell me who creates those cameras support?
Also, who is the supervisor of this place? If anyone can share more info, it will be great.
Both UFRaw and RawTherapee does not use LibRaw, but use own patched dcraw code
Here the logs of the errors I have (with no changes in the code):
I'm not sure that all MinGW versions supports std::filebuf->open(wchar_t*);
You may try to enable this in your LibRaw copy
In fact with MySys2 it is mingw and there is no _MSC_VER macro definition neither ...
So it definitely can't work.
Is there any reasons why MINGW is not wanted for the windows version of the function ?
For example with libtif I've faced to the same issue but the windows function is ok with mingw:
extern TIFF* TIFFOpen(const char*, const char*);
# ifdef __WIN32__
extern TIFF* TIFFOpenW(const wchar_t*, const char*);
# endif /* __WIN32__ */
Sorry, have not used Mysys2, so not know what preprocessor variables are defined
Thank you for your patch, but...
1st: to get TIFF/EXIF fields (for your own use) you do not need to patch parse_tiff_ifd/parse_exif code. Just install callbacks.exif_cb and you'll get all tag data into your code.
2nd: Current LibRaw/Github master branch (public snapshot) already parse DNG DefaultCrop tags into
If you need to apply this crop, add LIBRAW_PROCESSING_USE_DNG_DEFAULT_CROP bit to imgdata.params.raw_processing_options
And, yes, this is noted in aug-2017 snapshot announce: support for DefaultCrop Origin/Size tags (add LIBRAW_PROCESSING_USE_DNG_DEFAULT_CROP to raw_processing_options to enable)
3rd: DNG is more complex, than 'simple parse tag from some nested IFD'. Same tags (DefaultCrop* for example) may be specified separately for each IFD (and/or for IFD0). If some DNG file contains several different-resolution renderings (e.g. full data + fast load data), these tags should be applied in accurate way (see identify() function code for that).
DefaultCrop tags may be rational, so getint() is not useful here, getreal(type) is suggested.
cameraCount() return size of supported camera list.
LibRaw does not parse image count from sony metadata 0x9050 tag, so you need
- either create own metadata parser
- or try to use some other parser (Exiv2? not sure)
- or use Exiftool -ImageCount
Thank you for your help.
EOS 77D is supported by github-master version.
thanks a lot! That solved my issue. Found the header files unchanged at the place where they should be and adapted my makefile to use the new ones directly from the source location. Now, linking is no longer the problem, and images will now load.
Unfortunately, EOS 77D doesn't seem to be supported by this version.
Tried to fetch the GitHub repository to get it to run anyway. But there is no branch assigne with version 0.19 as indicated by your latest post about it. Which branch will continue the patch for EOS 77D?
Thank you in advance!