Thanks for the answer, is there any api to get a sub-sampled version of the image data buffer because I guess it should be enough to calculate an histogram.
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.
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.
Hi Alex,
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 "josephlintw@icloud.com", thx.
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.
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.
OK.
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:
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
tiff_ifd[ifd].dng_levels.default_crop
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).
4th:
DefaultCrop tags may be rational, so getint() is not useful here, getreal(type) is suggested.
Bad cam_mul values issue finally fixed in 0.19-stable branch (preparing 0.19-beta2): https://github.com/LibRaw/LibRaw/commit/d4420a4dac0d1f232629f7f163fb59d7...
Finally: it is fixed in LibRaw 0.19 (now in beta): COLOR() will check xtrans mask for xtrans files.
raw data are stored into imgdata.rawdata.raw_image[] array, available for both read and write.
This 'API' allows easy sampling with any stride, if you need sampled data.
Thanks for the answer, is there any api to get a sub-sampled version of the image data buffer because I guess it should be enough to calculate an histogram.
Histogram is built during postprocessing stage if auto-exposure is used.
Raw data are accessible after LibRaw::unpack() call, so histogram calculation is trivial single loop over all pixels.
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?
You can contact us via info@libraw.org, or via this site Feedback form (https://www.libraw.org/contact )
Hi Alex,
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 "josephlintw@icloud.com", thx.
That worked like a charm! : )
Thank you.
make -f Makefile.dist should do the trick
(or longer way:
autoreconf --install
./configure
make
but you need to have autotools installed for autoreconf)
Hello there,
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,
Marco
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
Our (LibRaw) team do that.
Hi There,
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
Thanks a lot. Fixed.
Here the logs of the errors I have (with no changes in the code):
http://free-astro.org/download/errors
I'm not sure that all MinGW versions supports std::filebuf->open(wchar_t*);
You may try to enable this in your LibRaw copy
OK.
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__ */
Cheers,
Cyril
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
tiff_ifd[ifd].dng_levels.default_crop
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).
4th:
DefaultCrop tags may be rational, so getint() is not useful here, getreal(type) is suggested.
Pages