if you're using win32\Makefile.msc doesn't that mean that the build will be for 32bit systems? Can you later link to a x64 project?
If not, is there a way around the issue or should I just use the latest release?
I think I managed to overcome my previous problem, and build LibRaw, but when I try to link it to my VS project I g and compile it can't find the definitions of functions I'm trying to use. e.g.
: error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z) referenced in function myFunction
Please use
1) release library (LibRaw 0.17), not development branch
2) Build the static library using
nmake -f Makefile.msvc
and use lib\libraw_static.lib for your application.
So I've managed to build the libraries, but when I try to link to my project I am getting the following errors
main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z) referenced in function GetColordataBlack
Sorry, no Linux on hands, so could not check the advice:
1) ./configure --enable-shared=no
2) make clean && make # to rebuild
This will remove shared (.so) libraries and will build static (.a) instead
Than build your sample.
If you have installed libraw libraries somewhere in system (/usr/local/lib or so) you may need to deinstall it
Hi, what do you mean by static build and compile.
I am kinda new to this so if you could please help.
the linkage is supposed to be in the "g++" command right?
There is no 'format list' this works different way:
each decoder may have 'flag' LIBRAW_DECODER_TRYRAWSPEED
(to get flags, call get_decoder_info).
Also, there are some exclusions (based mostly on make/model) hardcoded in LibRaw::unpack()
Speedup is not due to multicore (we use RawSpeed in single-threaded way)
We use LibRaw+RawSpeed in our projects (RawDigger, FastRawViewer) with success on both Windows and Mac.
Please note, that we use 'master' (stable) branch of RawSpeed, not the up-to-date 'devel' branch.
Speedup is very different depending on file format. It is very significant for lossless-JPEG compressed files (e.g. Canon CR2) and not so big for other formats.
I did download zlib.h and zconf.h added to include files. Or I should build it and add as a dependency? Are there any other external dependencies that I should be aware of? like perhaps libjpeg?
Thanks for the reply.
So I hope, there is actually scope for further optimization.
The problem is, a 2MP raw image is taking more than 2 seconds for processing, which is undesirable considering the requirement. (I am using HummingBoard with iMX6Q uSoM - by solidrun, running ubuntu 12.04 )
'From the box': you may use OpenMP acceleration to speed-up some demosaic methods. Just compile with Openmp (not tested with modern openmp implementations, this code is unchanged for years).
Standard processing do not use intermediate YUV representation, all processing is done in RGB. AHD interpolation uses temporary luminocity map to extrapolate data, but it is possible to use other demosaic methods without such map (e.g. bilinear interpolation or 'half' demosaic). These methods works entirely in RGB.
The only thing LibRaw can do for you is simplify EXIF parsing: you may install your own callback to receive all EXIF tags to catch tag 0x119 (as raw tag dump)
There is no barrel correction code in LibRaw postprocessing.
Unfortunately, lensfun (used bu darktable) doesn't correct the barrel distortion completely,
I have a wide angle shot with my Lumix DMC-FZ1000 where there are still distortions and dark areas near the corners which are not present if the raw file is processed by Silkypix (software distributed with the camera).
Lensfun does not use the embedded lens distortion parameters which are stored in each .rw2 raw file -
see https://syscall.eu/#pana
Which infrastructure of libraw could be used to implement distortion correction based on these data?
win32\Makefile.msc works ok for both 32 and 64 builds. Just use it from corresponding Visual studio shell (32 or 64-bit).
Link error: do you use LibRaw as static or as dynamic (dll) build?
Thank you for your answer,
if you're using win32\Makefile.msc doesn't that mean that the build will be for 32bit systems? Can you later link to a x64 project?
If not, is there a way around the issue or should I just use the latest release?
I think I managed to overcome my previous problem, and build LibRaw, but when I try to link it to my VS project I g and compile it can't find the definitions of functions I'm trying to use. e.g.
: error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z) referenced in function myFunction
In our Windows programs (RawDigger, FastRawViewer) we use zlib build by zlib's win32\Makefile.msc
No extra zlibwapi.lib is used, just zlib.lib (not zdll.lib which points to zlib.dll)
I just added include path to build specification, but I'm still getting the same error.
Sorry, I cannot continue this way.
Please use
1) release library (LibRaw 0.17), not development branch
2) Build the static library using
nmake -f Makefile.msvc
and use lib\libraw_static.lib for your application.
I didn't define it as LIBRAW_NODLL, but even after fixing that the same errors remain.
#ifdef WIN32
#ifdef LIBRAW_NODLL
# define DllDef
#else
# ifdef LIBRAW_BUILDLIB
# define DllDef __declspec( dllexport )
# else
# define DllDef __declspec( dllimport )
# endif
#endif
#else
# define DllDef
#endif
this how the libraw_types now looks like
Have you defined LIBRAW_NODLL on library and your application build?
If not, LibRaw will link as dllexport, while your app expect it as dllimport (more details are in libraw_types at DllDef define)
Hi again,
So I've managed to build the libraries, but when I try to link to my project I am getting the following errors
main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z) referenced in function GetColordataBlack
and more like it, what might be the issue?
Sorry, no Linux on hands, so could not check the advice:
1) ./configure --enable-shared=no
2) make clean && make # to rebuild
This will remove shared (.so) libraries and will build static (.a) instead
Than build your sample.
If you have installed libraw libraries somewhere in system (/usr/local/lib or so) you may need to deinstall it
Hi, what do you mean by static build and compile.
I am kinda new to this so if you could please help.
the linkage is supposed to be in the "g++" command right?
Regards
try to use static build and static linking.
Looks like you broke your project file in some way
There is no 'format list' this works different way:
each decoder may have 'flag' LIBRAW_DECODER_TRYRAWSPEED
(to get flags, call get_decoder_info).
Also, there are some exclusions (based mostly on make/model) hardcoded in LibRaw::unpack()
Speedup is not due to multicore (we use RawSpeed in single-threaded way)
Thanks for the quick reply. We will give it a go.
Is there a table of the formats that would use RawSpeed?
Also...is all the speed improvement in RawSpeed due to the use of multithreading?
Thanks!
Hi again, I built zlib and added it to dependencies and now I am getting
Error 11 error LNK1181: cannot open input file 'release\dcraw_emu.obj' C:\Users\HP\Documents\LibRaw\LibRaw-master\buildfiles\LINK dcraw_emu
Error 34 error LNK1181: cannot open input file 'release\dcraw_fileio.obj' C:\Users\HP\Documents\LibRaw\LibRaw-master\buildfiles\LINK libraw
And these errors.
We use LibRaw+RawSpeed in our projects (RawDigger, FastRawViewer) with success on both Windows and Mac.
Please note, that we use 'master' (stable) branch of RawSpeed, not the up-to-date 'devel' branch.
Speedup is very different depending on file format. It is very significant for lossless-JPEG compressed files (e.g. Canon CR2) and not so big for other formats.
You need to build it and add as a dependency.
All other dependencies (e.g. libjasper for jpeg2000 files) are optional, including jpeg (you can build libraw without jpeg compression support).
This one is not yet, because 0.18 branch is far from finished
I did download zlib.h and zconf.h added to include files. Or I should build it and add as a dependency? Are there any other external dependencies that I should be aware of? like perhaps libjpeg?
Libraw 0.18 (development branch) needs zlib (zlib.net) to support deflated DNG files.
This it to be changed (this dependency will change to optional) in some future update before 0.18-release.
we will gladly accept optimization patches and/or additional code.
Thanks for the reply.
So I hope, there is actually scope for further optimization.
The problem is, a 2MP raw image is taking more than 2 seconds for processing, which is undesirable considering the requirement. (I am using HummingBoard with iMX6Q uSoM - by solidrun, running ubuntu 12.04 )
'From the box': you may use OpenMP acceleration to speed-up some demosaic methods. Just compile with Openmp (not tested with modern openmp implementations, this code is unchanged for years).
Standard processing do not use intermediate YUV representation, all processing is done in RGB. AHD interpolation uses temporary luminocity map to extrapolate data, but it is possible to use other demosaic methods without such map (e.g. bilinear interpolation or 'half' demosaic). These methods works entirely in RGB.
The only thing LibRaw can do for you is simplify EXIF parsing: you may install your own callback to receive all EXIF tags to catch tag 0x119 (as raw tag dump)
There is no barrel correction code in LibRaw postprocessing.
Unfortunately, lensfun (used bu darktable) doesn't correct the barrel distortion completely,
I have a wide angle shot with my Lumix DMC-FZ1000 where there are still distortions and dark areas near the corners which are not present if the raw file is processed by Silkypix (software distributed with the camera).
Lensfun does not use the embedded lens distortion parameters which are stored in each .rw2 raw file -
see https://syscall.eu/#pana
Which infrastructure of libraw could be used to implement distortion correction based on these data?
Many thanks for a hint,
Helmut
Pages