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 :-)
Most likely, this is some 'approximation' if 1st word is Canon, than second is model name.
This camera was produces ~20years ago, current canon models do not use 'Inc' in maker/model
I find it interesting that the latest EXIFTool incorrectly reports the camera manufacturer as "Canon" and the model as "Inc.". Any reference to the actual camera model (which appears to be properly encoded in the data) is missing. I looked (briefly) at the EXIFTool source and it is far, far beyond what I want to get into.
If you have an EXIFTool which reports the name of the camera model correctly, can you please share? (if nothing else, you can upload it to ftp.infinadyne.com - it takes anonymous uploads in the root.
I could run EXIFTool against all the raw files I have from various sources, but if they do not properly reflect the camera model, it isn't really all that useful.
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"
data_size is not used in kodak_jpeg_load_raw(), so it is not critical.
All Kodak files from your link are processed OK by our FastRawViewer and RawDigger (LibRaw used internally).
dcraw_emu.exe -4 -T -w -o 0 looks OK too.
-4: equal to gamm[0]=gamm[1] = no_auto_bright = 1; output_bps=16
-w - use camera WB
-o 0 - RAW color
You can download the RAW here.
The output of the following command looks ok.
Find a thumbnail of the output here
Seems like I don't use the correct options on LibRaw or GraphicsMagick is causing the problem.
Most likely, this is some 'approximation' if 1st word is Canon, than second is model name.
This camera was produces ~20years ago, current canon models do not use 'Inc' in maker/model
I find it interesting that the latest EXIFTool incorrectly reports the camera manufacturer as "Canon" and the model as "Inc.". Any reference to the actual camera model (which appears to be properly encoded in the data) is missing. I looked (briefly) at the EXIFTool source and it is far, far beyond what I want to get into.
If you have an EXIFTool which reports the name of the camera model correctly, can you please share? (if nothing else, you can upload it to ftp.infinadyne.com - it takes anonymous uploads in the root.
I could run EXIFTool against all the raw files I have from various sources, but if they do not properly reflect the camera model, it isn't really all that useful.
Pages