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
I think many manufacturier are doing that but I had only the Fuji X-pro2 to test it:
Thanks to you library and the useful plugin for python I have computed gain of my detector using the photon transfert curve method, very simply.
I found of course that the gain increase with ISO as expected.
But also I checked something, the gain increase when you use a high aperture (in this case this is a 56mm f/1.2) on a lens which can communicate with the body.
Compare with the f/2.8 and above (don't know yet where the transition is) there is a factor 1.4 in the gain.
Measurement here : http://www.sylvainphoto.com/p901179378/ha0037831
This is due to the fact that at high aperture, the 'extra' light rays coming from the outer border of the pupil are hitting the pixel with a bigger angle. Pixel have a lower tolerance in angle, so what the manufacturers does is cheating the gain/ISO relation so the user is happy to see the expected extra stop of light which does not exists.
Well all this to illustrate the tricks of camera makers to be able to sell f/1.2 lenses (well you still get the bokeh) and the use of your library.
0.18 will receive only security fixes, no new cameras, sorry.
LibRaw is surely compatible with gcc 4+, clang 3+ (may be 2+ too), Visual Studio 2010+ (not sure about 2008). Most of these tools are available for free (including Visual Studio community edition), so I advise you to switch to current public snapshot (from github), it is stable enough for production use (and we use it for RawDigger and FastRawViewer).
Thanks for your reply and for taking time to find a solution so quickly.
I have not yet tried to build libRaw from sources, this is not easy for me because I have to use an old version of Visual Studio (2005) for my application. Do you plan to release a 0.18.x version including this fix or will it be in 0.19 ?
Thanks for yout fast reply. I am going to send you one samle file right now.
I just want to correct something that I said in my first post. Suspecting an authorization problem, I changed the location of the input file : now, I get an error code -2 (Unsupported file format or not RAW file) when using open_file.
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?
I think many manufacturier are doing that but I had only the Fuji X-pro2 to test it:
Thanks to you library and the useful plugin for python I have computed gain of my detector using the photon transfert curve method, very simply.
I found of course that the gain increase with ISO as expected.
But also I checked something, the gain increase when you use a high aperture (in this case this is a 56mm f/1.2) on a lens which can communicate with the body.
Compare with the f/2.8 and above (don't know yet where the transition is) there is a factor 1.4 in the gain.
Measurement here : http://www.sylvainphoto.com/p901179378/ha0037831
This is due to the fact that at high aperture, the 'extra' light rays coming from the outer border of the pupil are hitting the pixel with a bigger angle. Pixel have a lower tolerance in angle, so what the manufacturers does is cheating the gain/ISO relation so the user is happy to see the expected extra stop of light which does not exists.
Well all this to illustrate the tricks of camera makers to be able to sell f/1.2 lenses (well you still get the bokeh) and the use of your library.
Thank you for you help.
I finally found that it was a common issue but it seems I was typing bad keywords (or Google had problems with "_imp___"
Cheers
It's ok. I have just tried the patch, no crash happens now.
Thanks !
Here is the patch: https://www.dropbox.com/s/rq6x147fhbpruzr/libraw-tiled-dng-patch.patch?dl=0
(in short: for tiled DNGs last tile/tiles row may be larger than row/col count, so buffer overrun may occur).
OK, got it (reproduced) with MSVC 2010/32 bit.
It's ok with development snapshot, files are handled perfectly.
Thanks again for your help.
Also, no problems with
MSVC 2013/x64, nmake -f Makefile.msvc
dcraw_emu -T yourfile.dng produces TIFF file as expected
Could you please provide more details about the crash? May be binary + .pdb file + crash dump?
Thank you (again) for the file.
I'm unable to reproduce the crash using LibRaw compiled with gcc5/freebsd. Will check more with Windows/Visual studio
OK, thanks for your fast reply. I will try with development snapshot.
Thank you for the files.
There is bug in 0.18 in handling some NRW files.
Development snapshot handles these files OK, use it: https://github.com/LibRaw/LibRaw/
(this snapshot is stable for release use, it tested with our RawDigger/FastRawViewer sw).
LibRaw 0.18 will receive security fixes only. Use public development snapshot, it is stable enough to use in production
Ok, I will give it a try. Thanks a lot for your great work.
0.18 will receive only security fixes, no new cameras, sorry.
LibRaw is surely compatible with gcc 4+, clang 3+ (may be 2+ too), Visual Studio 2010+ (not sure about 2008). Most of these tools are available for free (including Visual Studio community edition), so I advise you to switch to current public snapshot (from github), it is stable enough for production use (and we use it for RawDigger and FastRawViewer).
Thanks for your reply and for taking time to find a solution so quickly.
I have not yet tried to build libRaw from sources, this is not easy for me because I have to use an old version of Visual Studio (2005) for my application. Do you plan to release a 0.18.x version including this fix or will it be in 0.19 ?
Thanks.
Eric
Thank you for sample.
This is due to additional raw metadata integrity check added somewhere before 0.18 version.
It is already fixed in development snapshot, please apply this patch to 0.18: https://github.com/LibRaw/LibRaw/commit/ade8d9a0be16079b177bdb5ec33dd880...
Thanks for yout fast reply. I am going to send you one samle file right now.
I just want to correct something that I said in my first post. Suspecting an authorization problem, I changed the location of the input file : now, I get an error code -2 (Unsupported file format or not RAW file) when using open_file.
Pages