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.
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
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?
Please make sure you use libraw.h (and other include files) for the same version: internal layout changes from version to version, there is no binary (ABI) compatibility between LibRaw 0.17 and (say) LibRaw 0.18 (unless you use C-API only).
If version mismatch is *not* problem cause, I do not have any other ideas.
Just checked: dcraw_emu will run properly. However, linking the native DLL against the static library 'libraw.a' or 'libraw_r.a' will crash with described failure during initializer of LibRaw (processor). The Java application has reasonable memory added (a few GB of heap). With exactly the same linking procedure libraw.a from LibRaw-0.17 works properly. What might go wrong here at build time?
BTW: Will 0.18 provide support for EOS 77D? I guess, no, but not certain.
Just switched back to dcraw. But this solution comes with drawback not being able to access the native camera data like black values, cam_matrix, etc. So, I prefer the use of libraw for raw processing.
Could you give some advice where to look into make files or build configuration what might cause the crash using libraw.a from the new version?
I can provide a Java stack trace, but this is not very informative, as it does not go deep enough into the native C code.
There is a huge difference. The sensel patterns have gaps in them that are interpreted by algorithms to produce the final image, and those demosaic/debayer patterns are subjective and vary from program to program. Some are proprietary and some are not, but those patterns are not part of the RAW data, but when the RAW data is baked into a tiff the results of those patterns is baked into the image thus a PNG will look the same from app to app.
If you want to see this in action install a copy of Rawtherapee, go to it's demosaicing panel and switch between it's various debayer algorithms. It's default is AMaZE, but it also offers AHD, LMMSE, DCB and several others. Each will produce a visually similar image out of the sensel data, but they will also be different at the pixel level because of how each interpolates the RAW data. Likewise some demosaicing/debayering algorithms can't be integrated into all software packages due to conflicts in their licensing. For example AMaZE, while open source, has provisions in it's licence that prevent it from being included with applications that are commercial. Thus if you like the result of AMaZE and want to use it in a given commercial app you must first bake that result at which point the image no longer RAW, but it can be PNG.
Thought it probably could be a mismatch between newer Oracle Java which is 64-bit only. Just downloaded the binary distribution 0.18.6 for macOS which is claimed to contain both 32 and 64 bit versions and shall run with Mac OS 10.11. In fact, I only found a single set of libraries pre-compiled. Are these 64-bit? Nevertheless, I experience the same behavior, the code will crash during creation of LibRaw object, when (static) linking the libs against my own code.
Tried both linking with both static libraries libraw and also libraw_r, which is claimed thread-safe. The JNI bridge starts working and properly calls LibRaw::version() without issues. However, when trying to crate the processor object, it crashes during the initializer.
JNIEXPORT jstring JNICALL Java_net_bwmc_libraw_LibRawImageLoader_getVersion
(JNIEnv *env, jclass clazz, jobject javaImageLoaderRef)
{
const char* cversionString = LibRaw::version(); // No problem to call this.
jstring versionString = env->NewStringUTF(cversionString); // C style string to Java String
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.
Thanks Alex
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.
Hi Alex,
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!
Please make sure you use libraw.h (and other include files) for the same version: internal layout changes from version to version, there is no binary (ABI) compatibility between LibRaw 0.17 and (say) LibRaw 0.18 (unless you use C-API only).
If version mismatch is *not* problem cause, I do not have any other ideas.
Hi Alex,
Thank you for your reply.
Just checked: dcraw_emu will run properly. However, linking the native DLL against the static library 'libraw.a' or 'libraw_r.a' will crash with described failure during initializer of LibRaw (processor). The Java application has reasonable memory added (a few GB of heap). With exactly the same linking procedure libraw.a from LibRaw-0.17 works properly. What might go wrong here at build time?
BTW: Will 0.18 provide support for EOS 77D? I guess, no, but not certain.
Just switched back to dcraw. But this solution comes with drawback not being able to access the native camera data like black values, cam_matrix, etc. So, I prefer the use of libraw for raw processing.
Could you give some advice where to look into make files or build configuration what might cause the crash using libraw.a from the new version?
I can provide a Java stack trace, but this is not very informative, as it does not go deep enough into the native C code.
Best wishes for 2018!
Does provided sample applications (e.g. bin/dcra_emu) works, or crashes too?
There is a huge difference. The sensel patterns have gaps in them that are interpreted by algorithms to produce the final image, and those demosaic/debayer patterns are subjective and vary from program to program. Some are proprietary and some are not, but those patterns are not part of the RAW data, but when the RAW data is baked into a tiff the results of those patterns is baked into the image thus a PNG will look the same from app to app.
If you want to see this in action install a copy of Rawtherapee, go to it's demosaicing panel and switch between it's various debayer algorithms. It's default is AMaZE, but it also offers AHD, LMMSE, DCB and several others. Each will produce a visually similar image out of the sensel data, but they will also be different at the pixel level because of how each interpolates the RAW data. Likewise some demosaicing/debayering algorithms can't be integrated into all software packages due to conflicts in their licensing. For example AMaZE, while open source, has provisions in it's licence that prevent it from being included with applications that are commercial. Thus if you like the result of AMaZE and want to use it in a given commercial app you must first bake that result at which point the image no longer RAW, but it can be PNG.
Thought it probably could be a mismatch between newer Oracle Java which is 64-bit only. Just downloaded the binary distribution 0.18.6 for macOS which is claimed to contain both 32 and 64 bit versions and shall run with Mac OS 10.11. In fact, I only found a single set of libraries pre-compiled. Are these 64-bit? Nevertheless, I experience the same behavior, the code will crash during creation of LibRaw object, when (static) linking the libs against my own code.
Tried both linking with both static libraries libraw and also libraw_r, which is claimed thread-safe. The JNI bridge starts working and properly calls LibRaw::version() without issues. However, when trying to crate the processor object, it crashes during the initializer.
JNIEXPORT jstring JNICALL Java_net_bwmc_libraw_LibRawImageLoader_getVersion
(JNIEnv *env, jclass clazz, jobject javaImageLoaderRef)
{
const char* cversionString = LibRaw::version(); // No problem to call this.
jstring versionString = env->NewStringUTF(cversionString); // C style string to Java String
return versionString;
}
This is vignetting + distorsion.
LibRaw does not have internal lens database, so no way to correct this
here is RAW rendering: https://www.dropbox.com/s/oh4qoxuoiphj87v/Screenshot%202017-12-27%2010.4...
And embedded JPEG: https://www.dropbox.com/s/9zfo4sba6m9bvbf/Screenshot%202017-12-27%2010.4...
You may try to use Lensfun, most of Canon fixed-camera lenses listed as 'supported': http://lensfun.sourceforge.net/lenslist/
My mistake, it isn`t real vignette. It looks like it, but I can find another word to describe it =)
Example:
https://imageshack.com/a/img923/2972/yLlXBx.jpg
LibRaw does not perform automatic vignetting and geometry corrections.
OpenCV: most likely, OpenCV opens embedded jpeg, not raw?
Pages