You can install your own EXIF-callback and get all EXIF/TIFF tags into your app.
This callback is called:
- EXIF: tag parameter is EXIF tag ID
- Kodak Metadata: tag | 0x20000
- Panasonic metadata: tag | 0x30000
- Tiff/DNG IFDs: tag | ((ifd + 1) << 20)
(tag upper bits are for LibRaw 0.19, in 0.18 ifd# was not passed)
This callback is not called on makernotes value parsing, but will receive complete makernotes record as tag# 0x927c
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:
You can install your own EXIF-callback and get all EXIF/TIFF tags into your app.
This callback is called:
- EXIF: tag parameter is EXIF tag ID
- Kodak Metadata: tag | 0x20000
- Panasonic metadata: tag | 0x30000
- Tiff/DNG IFDs: tag | ((ifd + 1) << 20)
(tag upper bits are for LibRaw 0.19, in 0.18 ifd# was not passed)
This callback is not called on makernotes value parsing, but will receive complete makernotes record as tag# 0x927c
i'd like to see that article too!
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
Pages