I loaded the .pro file into qt, told it I wanted a 64 bit build, and got errors. I have a screencap of them, but there appears to be no way to attach an explanatory image to a comment here?
libraw/libraw.h: No such file or directory - dcraw_emu.cpp, dcraw_half.c,prostprocessing_benchmark.cpp
jpeglib.h: No such file or directory - defines.h
...
There are more errors, but they are similar. Basically, it isn't finding the includes where they are supposed to be.
I have the latest MSVC, community edition, installed under Windows 10. I am attempting to build libraw inside a vanilla Windows 10 powershell.
Your directions:
Unpack the distribution package (if you have got no tar+gzip, take the LibRaw distribution package in the .ZIP format) and go to folder LibRaw-X.YYY.
Set the environment parameters so that the compiler/linker would find the libraries and include-files. For Visual C++, this is done by running vcvars32.bat.
Run
nmake -f Makefile.msvc
There is no "vcvars32.bat" file in the distribution in the base folder, or in the buildfiles folder. Should I be looking somewhere else?
"Makefile.msvc" is present. However, "nmake -f Makefile.msvc" returns an error:
The term "nmake" is not recognized as the name of a cmdlet, function, script file, or operable program
You said:
You need either recompile LibRaw from source with your compiler or use precompiled dll (+MSVC runtime)
A dll imposes issues I wish to avoid. I want the code securely inside the app with no install issues. Hence my desire to build a compile-time linkable library.
Alex,
I also added a T4iExample.CR2 to the dropbox share. The method I last suggested works without the LibRaw::unpack() call. My need for a valid black level is only required if the user does not wish to calibrate their astro images using BIAS frames. These BIAS frames are images shot with the lens cap on and at the fastest shutter speed of the camera. They are very easy to generate and they act as pixel-by-pixel black level references. A valid black level is vital for astro image calibration...especially for what is called FLAT frames so having the user resort to using the black level values we are discussing here is essentially a simplified estimate.
Alex,
I did try using the cblack[] values but they also were zero. I did find that the Canon.ChannelBlackLevel[] values were populated. I am going to check all three (imgdata.color.black, imgdata.color.cblack[] and Canon.ChannelBlackLevel[]). The first non-zero value I find will dictate what value I use. Do you agree?
The problem was related with openCV not rawpy or libraw. OpenCV uses BGR format,not RGB. so when i used cv2.imshow() after debayering using libraw , the colors swapped in R and B channel.
Sloution: convert RGB matrix to BGR before using cv2.imshow(). Open CV has a builtin function to do so, cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
Under Windows:
The problem may relate to FILE* pointer:
- you create one in your code (using runtime you specify on linking your code)
- and pass it to libjpeg.dll
You need to make sure that libjpeg.dll uses same runtime version with same FILE* structure layout.
(the problem is windows-specific, on Linux/Unix and Mac FILE* is handled by the single system runtime)
Thanks a lot for your support! This works. Somehow my code didn't work with release-DLL version, VCRT kept giving errors. However, it works nice with static lib or debug build. Go figure! :)
Again, thanks for your help. It gave me the assurance that I was on the right path.
I had the libraw-package of my distribution installed and g++ seams to find the files first, where the package-manager has put them. Deinstalling the package resolved the error. Everything works as expected now.
I could not see what exceptions you get.
This snippet, created from your code (removed _putenv, _snprintf_s replaced w/ simple sprintf) compiles and converts single ARW file to jpeg: https://www.dropbox.com/s/1lq7npmuip2xne5/raw2jpeg.zip?dl=0
example.txt cut to write function only (JPEG read complains about put_scanline_someplace, so entire JPEG reading code removed).
Needed #includes added to example.txt and main (stdlib.h)
Compiled/tested under FreeBSD (under Linux is should be the same) using this command line:
clang -I/usr/local/include -I../LibRaw -o raw2jpeg main.cpp example.cpp -L/usr/local/lib -ljpeg -L../LibRaw/lib -lraw -lcxxrt
libjpeg-turbo 2.0.2 is installed in /usr/local
LibRaw is compiled in ../LibRaw
nmake -f returns the following:
run nmake from visual studio shell (it will set all paths/etc)
I loaded the .pro file into qt, told it I wanted a 64 bit build, and got errors. I have a screencap of them, but there appears to be no way to attach an explanatory image to a comment here?
There are more errors, but they are similar. Basically, it isn't finding the includes where they are supposed to be.
I have the latest MSVC, community edition, installed under Windows 10. I am attempting to build libraw inside a vanilla Windows 10 powershell.
Your directions:
nmake -f Makefile.msvc
There is no "vcvars32.bat" file in the distribution in the base folder, or in the buildfiles folder. Should I be looking somewhere else?
"Makefile.msvc" is present. However, "nmake -f Makefile.msvc" returns an error:
You said:
A dll imposes issues I wish to avoid. I want the code securely inside the app with no install issues. Hence my desire to build a compile-time linkable library.
We provide both Makefile.msvc and qmake .pro files, so rebuilding should be easy.
I was really trying hard to avoid having to build libraw, but I will give it a shot. Thank you.
Libraries built with different compilers are *not* compatible under windows (esp. if C++ library is used).
You need either recompile LibRaw from source with your compiler or use precompiled dll (+MSVC runtime)
Most likely in 2020
X-Pro3 support will not be included in 0.19.x branch
When will the 0.19.6 with it available?
X-Pro3 is supported in current snapshot.
Black level calculated based on real black frame data (we consider/is) more accurate (compared to metadata values)
Alex,
I also added a T4iExample.CR2 to the dropbox share. The method I last suggested works without the LibRaw::unpack() call. My need for a valid black level is only required if the user does not wish to calibrate their astro images using BIAS frames. These BIAS frames are images shot with the lens cap on and at the fastest shutter speed of the camera. They are very easy to generate and they act as pixel-by-pixel black level references. A valid black level is vital for astro image calibration...especially for what is called FLAT frames so having the user resort to using the black level values we are discussing here is essentially a simplified estimate.
Peter
Thanks (I needed to look in the debugger to remember)
For (most/some) Canon files, black level is calculated based on dark frame values. So, it is only available after LibRaw::unpack() call
Alex,
Here is a dropbox link to a T5i and a T7i RAW file
Peter
https://www.dropbox.com/sh/qn0j23qun6gbuoo/AAB0aoKOhpzHchFar2Z4WKDsa?dl=0
Could you please share raw sample?
Alex,
I did try using the cblack[] values but they also were zero. I did find that the Canon.ChannelBlackLevel[] values were populated. I am going to check all three (imgdata.color.black, imgdata.color.cblack[] and Canon.ChannelBlackLevel[]). The first non-zero value I find will dictate what value I use. Do you agree?
Peter
You need to use both black and cblack[] values: https://www.libraw.org/docs/API-datastruct.html#libraw_colordata_t
The problem was related with openCV not rawpy or libraw. OpenCV uses BGR format,not RGB. so when i used cv2.imshow() after debayering using libraw , the colors swapped in R and B channel.
Sloution: convert RGB matrix to BGR before using cv2.imshow(). Open CV has a builtin function to do so, cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
Could you please share raw file?
Under Windows:
The problem may relate to FILE* pointer:
- you create one in your code (using runtime you specify on linking your code)
- and pass it to libjpeg.dll
You need to make sure that libjpeg.dll uses same runtime version with same FILE* structure layout.
(the problem is windows-specific, on Linux/Unix and Mac FILE* is handled by the single system runtime)
Thanks a lot for your support! This works. Somehow my code didn't work with release-DLL version, VCRT kept giving errors. However, it works nice with static lib or debug build. Go figure! :)
Again, thanks for your help. It gave me the assurance that I was on the right path.
I got it solved by myself:
I had the libraw-package of my distribution installed and g++ seams to find the files first, where the package-manager has put them. Deinstalling the package resolved the error. Everything works as expected now.
I could not see what exceptions you get.
This snippet, created from your code (removed _putenv, _snprintf_s replaced w/ simple sprintf) compiles and converts single ARW file to jpeg: https://www.dropbox.com/s/1lq7npmuip2xne5/raw2jpeg.zip?dl=0
example.txt cut to write function only (JPEG read complains about put_scanline_someplace, so entire JPEG reading code removed).
Needed #includes added to example.txt and main (stdlib.h)
Compiled/tested under FreeBSD (under Linux is should be the same) using this command line:
clang -I/usr/local/include -I../LibRaw -o raw2jpeg main.cpp example.cpp -L/usr/local/lib -ljpeg -L../LibRaw/lib -lraw -lcxxrt
libjpeg-turbo 2.0.2 is installed in /usr/local
LibRaw is compiled in ../LibRaw
It looks like it is simpler to implement it for one time in one of libraw samples: https://github.com/LibRaw/LibRaw/commit/52b7066b3ed285ed84c20a2442c59331...
Pages