I appreciate your help in creating a 64 bit version of LibRaw for Windows. I can interface with this library version from a 64 bit Java VM using BridJ, but if I try to call the init() method of LibRaw when compiled as a 64 bit dll it crashes. I get EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x00007ffdd79069ac, pid=6876, tid=6592. Any clue on what I can do?
LibRaw assumes *full* raw file is available. If not, the file may be rejected.
In some cases only some part of file is sufficient for metadata parse, but there is no general rule: it is possible that RAW data is recorded before some other metadata (this is the case for Canon CRW files, for example.
You may implement own I/O layer which will ask downloader to download requested file part(s)
I will take a look at this, but I am probably not going to pick up the next release right away. I got into this because my dcraw "adaptation" wasn't working as well as it should and I thought LibRaw might save me a lot of work. It certainly has, because all in all, dcraw is a monolithic global-variable mess. It might sort of be OK for a stand-alone program, but I am not even sure of that. I do know that it is very difficult for someone to maintain the way it is.
So I have my little graphics interface DLL now working with the updated dcraw code and this brings it into the more "modern era". I have also brought in a faster JPEG decoder and I believe this will benefit the applications that use this DLL greatly. So now I get to spend a bunch of time working on those applications with a lot more confidence in the graphics DLL.
Checked all old kodak files with current (-development) LibRaw branch with both open_file() and open_buffer(). All OK.
development branch to be updated on GitHub in few days
I used vcvars32.bat initially to build the correct libraw.dll but then figured i should use vcvarsall.bat for 64 bit build, though there was no difference. If that's not the correct way, how do you rebuild it with 64bit? Thanks a lot again
Thank you for your response. So when machine module type and target is set to x86, everything works fine. When I convert both to x64 From Release Target in Configuration Manager and Linker -> Advanced -> Target Machine, I get the following output:
1>------ Rebuild All started: Project: LibrawReader, Configuration: Release x64 ------
1> readFile.cpp
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(98): warning C4251: 'LibRaw_file_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(101): warning C4251: 'LibRaw_file_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(200): warning C4251: 'LibRaw_bigfile_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(203): warning C4251: 'LibRaw_bigfile_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl LibRaw::~LibRaw(void)" (__imp_??1LibRaw@@UEAA@XZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl LibRaw::recycle(void)" (__imp_?recycle@LibRaw@@QEAAXXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::raw2image(void)" (__imp_?raw2image@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::unpack(void)" (__imp_?unpack@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z)
1>c:\users\imnet\documents\visual studio 2013\Projects\LibrawReader\x64\Release\LibrawReader.exe : fatal error LNK1120: 6 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
OK, mystery solved. I use current (our development) branch for testing.
This branch to be pushed on GitHub within 2-3 weeks, our repository is here.
Or just add these lines to apply_tiff:
1Mb malloc is not much in today raw processing. 50Mpix Canon RAW, processed in full-res in float (16 bytes per pixel) is slightly less than 1Gb (and my phone have 2GB RAM)
Working on embedded systems and games with as little as 128 BYTES of RAM conditions one in different ways and makes one think a bit before doing some things.
I can see where it would be good to set data_size in apply_tiff, but in the code I downloaded from libraw.org it isn't happening. Seems like the statement
data_size = tiff_ifd[i].bytes
would be a good idea to have there, but in the 0.17 code it is not there.
We'll release massive update to 'master' Github branch in 2-3 weeks. The update will include support for this data format. Follow us on GitHub: https://github.com/LibRaw/LibRaw
I have looked around at dcraw_common.ccp and I find no instance of setting data_size... ever. I looked at the latest dcraw.c source and I see the LibRaw version is doing something interesting in copying the entire JPEG data area and byte-flipping it whereas this is apparently done in the input buffer in dcraw.c. I can certainly understand a need/desire to keep the input buffer as "const", even at the expense of a huge malloc to hold the copy.
But this doesn't explain how data_size (which controls the malloc and byte swapping) gets set in things like RawDigger.
I put in some code to set data size at the beginning of kodak_jpeg_load_raw and it works flawlessly now. This isn't something I am comfortable with. I would very much like to understand how data_size is supposed to be set, given that it is buried in an "internal" struct, I am sure it is not an external parameter. Clearly, data_size is completely new to LibRaw and doesn't appear in the original dcraw.c source. But when I search on data_size in dcraw_common.cpp the only occurrences I find are reading it. Actually, I find no occurrence anywhere in LibRaw where this value is set.
positive exposure shift may be non-linear (highlights compression), while auto-bright is linear.
BTW, LibRaw's dcraw_process() is only 'sample' processing. It is not ideal and not in development. We hope developers will implement own processing on top of LibRaw::open_file/unpack.
But if exp_shift works when auto brightness is enabled, why doesn't it darken the image again when using negativ exposure shift - think of it as means to overwrite the auto brightness functionality - or shift it :-)
I appreciate your help in creating a 64 bit version of LibRaw for Windows. I can interface with this library version from a 64 bit Java VM using BridJ, but if I try to call the init() method of LibRaw when compiled as a 64 bit dll it crashes. I get EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x00007ffdd79069ac, pid=6876, tid=6592. Any clue on what I can do?
LibRaw assumes *full* raw file is available. If not, the file may be rejected.
In some cases only some part of file is sufficient for metadata parse, but there is no general rule: it is possible that RAW data is recorded before some other metadata (this is the case for Canon CRW files, for example.
You may implement own I/O layer which will ask downloader to download requested file part(s)
I will take a look at this, but I am probably not going to pick up the next release right away. I got into this because my dcraw "adaptation" wasn't working as well as it should and I thought LibRaw might save me a lot of work. It certainly has, because all in all, dcraw is a monolithic global-variable mess. It might sort of be OK for a stand-alone program, but I am not even sure of that. I do know that it is very difficult for someone to maintain the way it is.
So I have my little graphics interface DLL now working with the updated dcraw code and this brings it into the more "modern era". I have also brought in a faster JPEG decoder and I believe this will benefit the applications that use this DLL greatly. So now I get to spend a bunch of time working on those applications with a lot more confidence in the graphics DLL.
Checked all old kodak files with current (-development) LibRaw branch with both open_file() and open_buffer(). All OK.
development branch to be updated on GitHub in few days
Thank you Alex. It Worked. I am very very grateful. All the best.
And vcvarsall without x64 will create x86 environment, just first lines from this .bat:
vcvars32 surely will set x32 environment.
To rebuild 64-bit libraw.dll I succesfully use this:
I used vcvars32.bat initially to build the correct libraw.dll but then figured i should use vcvarsall.bat for 64 bit build, though there was no difference. If that's not the correct way, how do you rebuild it with 64bit? Thanks a lot again
unresolved symbols mean you cannot link with correct .dll (or lib).
Are you sure you've rebuilt libraw.dll with 64 bit?
Thank you for your response. So when machine module type and target is set to x86, everything works fine. When I convert both to x64 From Release Target in Configuration Manager and Linker -> Advanced -> Target Machine, I get the following output:
1>------ Rebuild All started: Project: LibrawReader, Configuration: Release x64 ------
1> readFile.cpp
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(98): warning C4251: 'LibRaw_file_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(101): warning C4251: 'LibRaw_file_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(200): warning C4251: 'LibRaw_bigfile_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(203): warning C4251: 'LibRaw_bigfile_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl LibRaw::~LibRaw(void)" (__imp_??1LibRaw@@UEAA@XZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl LibRaw::recycle(void)" (__imp_?recycle@LibRaw@@QEAAXXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::raw2image(void)" (__imp_?raw2image@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::unpack(void)" (__imp_?unpack@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z)
1>c:\users\imnet\documents\visual studio 2013\Projects\LibrawReader\x64\Release\LibrawReader.exe : fatal error LNK1120: 6 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
What do you think is the problem?
OK, mystery solved. I use current (our development) branch for testing.
This branch to be pushed on GitHub within 2-3 weeks, our repository is here.
Or just add these lines to apply_tiff:
data_offset = tiff_ifd[i].offset; +#ifdef LIBRAW_LIBRARY_BUILD + data_size = tiff_ifd[i].bytes; +#endif tiff_flip = tiff_ifd[i].t_flip;1Mb malloc is not much in today raw processing. 50Mpix Canon RAW, processed in full-res in float (16 bytes per pixel) is slightly less than 1Gb (and my phone have 2GB RAM)
These days, a malloc under 1MB isn't huge at all.
Working on embedded systems and games with as little as 128 BYTES of RAM conditions one in different ways and makes one think a bit before doing some things.
I can see where it would be good to set data_size in apply_tiff, but in the code I downloaded from libraw.org it isn't happening. Seems like the statement
would be a good idea to have there, but in the 0.17 code it is not there.
data_size is set within apply_tiff() code.
malloc is not 'huge': Kodak JPEG-codec cameras are DC50 (0.5Mpix) and DC120 (1Mpix). Real data size is less than 1Mb.
We'll release massive update to 'master' Github branch in 2-3 weeks. The update will include support for this data format. Follow us on GitHub: https://github.com/LibRaw/LibRaw
LibRaw 0.17 will *not* be updated.
I have looked around at dcraw_common.ccp and I find no instance of setting data_size... ever. I looked at the latest dcraw.c source and I see the LibRaw version is doing something interesting in copying the entire JPEG data area and byte-flipping it whereas this is apparently done in the input buffer in dcraw.c. I can certainly understand a need/desire to keep the input buffer as "const", even at the expense of a huge malloc to hold the copy.
But this doesn't explain how data_size (which controls the malloc and byte swapping) gets set in things like RawDigger.
I put in some code to set data size at the beginning of kodak_jpeg_load_raw and it works flawlessly now. This isn't something I am comfortable with. I would very much like to understand how data_size is supposed to be set, given that it is buried in an "internal" struct, I am sure it is not an external parameter. Clearly, data_size is completely new to LibRaw and doesn't appear in the original dcraw.c source. But when I search on data_size in dcraw_common.cpp the only occurrences I find are reading it. Actually, I find no occurrence anywhere in LibRaw where this value is set.
What am I missing here?
And 32-bit version works fine too: https://www.dropbox.com/s/4azsj2qecpl4af9/Screenshot%202015-11-10%2019.1...
Sorry. looked under wrong #ifdef.
And (looked in RawDigger in debugger) data_size is correct. Looks like I need to switch to 32-bit version again?
What I am seeing at the beginning of kodak_jpeg_load_raw is the following:
// LibRaw's Kodak_jpeg_load_raw void CLASS kodak_jpeg_load_raw() { if(data_size < 1) throw LIBRAW_EXCEPTION_DECODE_JPEG;This is the source of the -100008 error I am getting. This is in dcraw_common.cpp.
I am building this with NO_JPEG not defined.
ok. thanks for clarifying this.
positive exposure shift may be non-linear (highlights compression), while auto-bright is linear.
BTW, LibRaw's dcraw_process() is only 'sample' processing. It is not ideal and not in development. We hope developers will implement own processing on top of LibRaw::open_file/unpack.
...kind of expected.
But if exp_shift works when auto brightness is enabled, why doesn't it darken the image again when using negativ exposure shift - think of it as means to overwrite the auto brightness functionality - or shift it :-)
We use LibRaw in 64-bit windows projects (Visual Studio 2010 and 2013) without any problem.
Could you please describe the problem in more details?
'negative' exposure shift darkens image (in linear fashion).
Auto-bright - brightens it.
It is expected, is not it?
Seems like this is due to
Using no_auto_bright = 1 seems to allow using values of 0.25 <= exp_shift < 1.0 !?
API docu doesn't indicate this constraint.
Sorry: I meant "Everything works fine when platform and target machine are x86"
Pages