File seems ok. It was a subtle synchronization problem in my code. I was just surprised it occured in the same method all the time. Thanks for the quick reply!
Btw, I'm running on 64-bit Windows 7 and doing openBuffer, unpack, dcraw_process, and dcraw_make_mem_image and checking the return codes for each call.
In the file wf_filtering.cpp we are getting a few warnings. Not sure if they are critical or not. This is using xcode 4.3 on the mac using the apple llvm 3.1 compiler. Below is the warning with the associated line numbers.
Control may reach end of non-void function
686
& has lower precedence than ==; == will be evaluated first
1169
1332
1623
1682
1703
1720
1759
1798
1857
1895
1934
OK, I'll change LibRaw_(big)file_datastream internals to save std::string instead of just pointer. It is safer way.
0.15 still in pre-Beta state, so I may change ABI/internals without saving compatibility :)
Also, I'll add open_wfile() call (under #ifdef WIN32) in next Alpha.
I did not realize the pointer to the path was not being copied. Once I made that change, it worked. We are using the c api and I was wondering if you were going to add a wchar_t version for the libraw_open_file call on windows? Currently I am doing that myself.
Could you please specify your working environment:
- what test-code do you use, dcraw_emu (or something else from LibRaw's samples)
- or your own code
Possibly, the source of error is:
1) LibRaw_file_datastream() constructor saves the pointer to filename you pass to LibRaw::open_file()
Note, the pointer is stored, not string copied!
2) the buffer with filename (passed to open_file) is destroyed before LibRaw::unpack() called
Lossy DNG files exported by LightRoom 4 seem to crash.
The call stack is:
#0 0x0000000116801719 in LibRaw_file_datastream::jpeg_src(void*) at /Users/tbrown/Documents/ProjectsOnOne/Suite6/LibRaw/src/libraw_datastream.cpp:280
#1 0x0000000116793de9 in LibRaw::lossy_dng_load_raw() ()
#2 0x00000001167c0751 in LibRaw::unpack() ()
#3 0x00000001167bc9de in libraw_unpack ()
when calling this line of code
jas_file = fopen(fname(),"rb");
The fname() returns a garbage string so that the fopen fails and then crashes soon after.
I am using the USE_JPEG8 flag when compiling. I have upgraded to the latest version of the jpeglib. Is there something else I need to do to get this working
It looks like your code uses different structure fields alignment than in compiled libraw.dll
LibRaw.dll is compiled using Makefile.msvc with Visual Studio 2010 on 64 bit machine. There are no additional compiler flags for structure fields alignment, defaults used.
LibRaw 0.14.7 (latest stable release) and 0.15-Alpha1 (current alpha version) are able to process Ricoh GR IV DNGs without any problem. So, latest digiKam should be able to work with these files.
DarkTable, AFAIK, uses RawSpeed library for most RAW files processing and LibRaw as a fallback. You should reconfigure/recompile darktable to use LibRaw as a main RAW processing engine (do not know exact details, sorry).
>In fact, unlike TIFF and TIFF/EP, DNG is proprietary and I'm under the impression that Adobe never really had any real intention to standardize it. Proof is the recent additions of the undocumented lossy and fast-load options that creates "DNG" files that only Adobe can read back safely.
I don't think this constitutes proof of nefarious intentions. If no DNG 1.4 specification is published, or if the license for the 1.4 functionality changes, I'd be inclined to agree with you. I don't think advancement is proof of anything other than forward thinking and the need for new functionality.
As to "only Adobe can read back safely", I'm not sure exactly what you are talking about. There are two basic issues. If you are speaking about the issue with Fast Load previews becoming unreadable, here is my understanding.
There is a flaw in the existing dcraw code that improperly treats an alternate IFD as the main IFD. (I think this has been corrected in newer dcraw code.) Since a lot of software uses dcraw, it makes this a widespread issue. The existing specification outlines how DNG readers should understand IFDs. Here's the relevant part of the 1.2 spec as I understand it.
"DNG 1.2.0.0 allows a new value for NewSubFileType equal to 10001.H. This value, used for alternative or non-primary rendered previews, allows for multiple renderings (not just multiple sizes of a single rendering) to be stored in a DNG file. DNG reading software that displays a preview for a DNG file should, by default, display a preview from an IFD with NewSubFileType equal to 1. Alternative renderings should only be displayed if requested by the user."
I believe that dcraw was grabbing the wrong IFD because it was not paying proper attention to the tag.
If your objection is based on the new lossy compressed options, then I'd simply say to wait a little while and see if Adobe continues to do what they have always done so far - fully document the changes and release free SDK code for other applications to make use of (some of) the new functionality.
As to the addition of lossy source image data, it's my understanding that this allows DNG to be a more suitable container for JPEG originals. There is a significant file size economy, which will be useful at times. I'm personally very happy about this addition, since it allows JPEG shooters to store their parametrically edited images in a more appropriate format. (I personally believe that stuffing the EDL back into the JPEG header is a bad hack.) There are other really good and interesting ways for lossy compression to be of use that anyone here should be able to imagine with a little thought.
You are certainly free to believe that any advancement in the specification is prima facie evidence that Adobe is up to no good. It is my hope that they will document and license the new DNG capabilities as they have done for the last few revisions, and that these capabilities will be used by many different software and hardware vendors in valuable ways. i think they have a good track record in this regard.
As to the ISO stuff, if you are really curious, then I suggest you ask them what's up.
Peter, I just ask you for the ISO submission number and date.
Not links to comments on blogs, posts on usenet, obscure bulletin boards or suggestion to use Google. I want to see a trace of it on http://www.iso.org, something OFFICIAL.
As far as I can tell, DNG was never submitted for standardization.
The post you mention is just from a single individual, and it does not say anything about DNG being submitted for standardization. TIFF/EP being revised with input from DNG ("[having] Adobe's permission to incorporate modifications and developments made for DNG") does not say the Adobe DNG 1.3 specification will become an ISO standard. In fact the post in question was a call for input from anyone, saying the group in charge of TIFF/EP was open to suggestions (which is hardly surprizing).
There is a fine line between incorporating elements of DNG into an existing standard, and making DNG a standard in itself even if DNG was indeed derived from the TIFF/EP. Unofficial Adobe voices (like yours) are riding that line and interpreting it in a way that makes people believe that DNG is a standard, or close to become one.
In fact, unlike TIFF and TIFF/EP, DNG is proprietary and I'm under the impression that Adobe never really had any real intention to standardize it. Proof is the recent additions of the undocumented lossy and fast-load options that creates "DNG" files that only Adobe can read back safely.
DNG just became a closed, opaque format as those additions (some of them turned on by default in recent Adobe software e.g. Lightroom 4.0 and 4.1) are breaking and the lack of documentation makes it very difficult at best for anyone else to read those files.
How do you correlate this recent behavior with a standard, documented and stable format? I call it bait-and-switch from a company working on securing its future more than anything else.
Axel,
A quick use of the Google shows that Dietmar Wueller, a member of TC42 WG18, claimed to receive the offer from Adobe in March of 2007. I was not at the Archiving conference this year where I would have probably talked to Herr Wueller in person. Here is the email referenced on the DNG Wikipedia page.
Perhaps you could write to him or to the secretariat of the working group to find out what the current thinking of the group is. Here is the Secretariat's info from the ISO website.
Secretariat direct:
The ISO keeps track on everything, submitted, rejected, retired, accepted, and lists the status of everything. I keep hearing from unofficial voices, bloggers, Adobe evangelists etc that DNG was submitted to the ISO, yet I could not find ANY trace of it at www.iso.org, which has a comprehensive search engine. In fact the ISO is a champion of traceability and exactly the opposite of a black hole. So, Peter, where is the DNG submission? Please be thorough and post the submission number and date.
Linking CXX executable luminance-hdr.exe
c:/progra~2/codebl~1/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
Hi, Im trying to build Luminance HDR using CodeBlocks. I've obtained libraw using this makefile but I'm getting some errors related to references in libraw.
Any idea how to solve it or the origin of this problem?
Thanks in advance!
Raissel
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2299): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x231b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x23e8): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x243b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2625): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2aab): more undefined references to `_Unwind_Resume' follow
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD1Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame+0x427): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream4getsEPci+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream9scanf_oneEPKcPv+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD0Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream16tempbuffer_closeEv+0x13): more undefined references to `__gxx_personality_v0' follow
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x7722): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x79aa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x98fa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa02e): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa636): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xbe07): more undefined references to `__chkstk_ms' follow
collect2: ld returned 1 exit status
mingw32-make.exe[2]: *** [luminance-hdr.exe] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/luminance-hdr.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
Info: resolving half::_eLut by linking to __imp___ZN4half5_eLutE (auto-import)
libraw_open_wfile/open_wfile_ex added in 0.15-Beta1
File seems ok. It was a subtle synchronization problem in my code. I was just surprised it occured in the same method all the time. Thanks for the quick reply!
Could you please check this file with dcraw_emu sample?
Both 0.14.7 and 0.15-Alpha4 (both - Windows version) works OK.
I use dcraw_emu sample for testing.
Btw, I'm running on 64-bit Windows 7 and doing openBuffer, unpack, dcraw_process, and dcraw_make_mem_image and checking the return codes for each call.
wf_debanding code is '3rd-party', contributed to LibRaw.
I'll ask author about these warnings.
In the file wf_filtering.cpp we are getting a few warnings. Not sure if they are critical or not. This is using xcode 4.3 on the mac using the apple llvm 3.1 compiler. Below is the warning with the associated line numbers.
Control may reach end of non-void function
686
& has lower precedence than ==; == will be evaluated first
1169
1332
1623
1682
1703
1720
1759
1798
1857
1895
1934
OK, I'll change LibRaw_(big)file_datastream internals to save std::string instead of just pointer. It is safer way.
0.15 still in pre-Beta state, so I may change ABI/internals without saving compatibility :)
Also, I'll add open_wfile() call (under #ifdef WIN32) in next Alpha.
I did not realize the pointer to the path was not being copied. Once I made that change, it worked. We are using the c api and I was wondering if you were going to add a wchar_t version for the libraw_open_file call on windows? Currently I am doing that myself.
Thanks for feedback.
Could you please specify your working environment:
- what test-code do you use, dcraw_emu (or something else from LibRaw's samples)
- or your own code
Possibly, the source of error is:
1) LibRaw_file_datastream() constructor saves the pointer to filename you pass to LibRaw::open_file()
Note, the pointer is stored, not string copied!
2) the buffer with filename (passed to open_file) is destroyed before LibRaw::unpack() called
Lossy DNG files exported by LightRoom 4 seem to crash.
The call stack is:
#0 0x0000000116801719 in LibRaw_file_datastream::jpeg_src(void*) at /Users/tbrown/Documents/ProjectsOnOne/Suite6/LibRaw/src/libraw_datastream.cpp:280
#1 0x0000000116793de9 in LibRaw::lossy_dng_load_raw() ()
#2 0x00000001167c0751 in LibRaw::unpack() ()
#3 0x00000001167bc9de in libraw_unpack ()
when calling this line of code
jas_file = fopen(fname(),"rb");
The fname() returns a garbage string so that the fopen fails and then crashes soon after.
I am using the USE_JPEG8 flag when compiling. I have upgraded to the latest version of the jpeglib. Is there something else I need to do to get this working
Thanks for any help you can give.
It looks like I need to set explicit alignment for public structure members.
OK.
Finally I have found a solution:
I added an alignment before some structures:
__declspec(align(8)) typedef struct
{
float iso_speed;
float shutter;
float aperture;
float focal_len;
time_t timestamp;
unsigned shot_order;
unsigned gpsdata[32];
char desc[512],
artist[64];
} libraw_imgother_t;
__declspec(align(8)) typedef struct
{
unsigned int progress_flags;
unsigned int process_warnings;
libraw_iparams_t idata;
libraw_image_sizes_t sizes;
libraw_colordata_t color;
libraw_imgother_t other;
libraw_thumbnail_t thumbnail;
libraw_rawdata_t rawdata;
ushort (*image)[4] ;
libraw_output_params_t params;
void *parent_class;
} libraw_data_t;
Everything works fine now and I am getting all correct metadata values (ISO...).
I guess, the default structure fields alignment on VS2010 is 8 bytes and not 4 bytes.
Thanks for your help :-)
It looks like your code uses different structure fields alignment than in compiled libraw.dll
LibRaw.dll is compiled using Makefile.msvc with Visual Studio 2010 on 64 bit machine. There are no additional compiler flags for structure fields alignment, defaults used.
LibRaw 0.14.7 (latest stable release) and 0.15-Alpha1 (current alpha version) are able to process Ricoh GR IV DNGs without any problem. So, latest digiKam should be able to work with these files.
DarkTable, AFAIK, uses RawSpeed library for most RAW files processing and LibRaw as a fallback. You should reconfigure/recompile darktable to use LibRaw as a main RAW processing engine (do not know exact details, sorry).
LibRaw 0.15 requires libjpeg 8.x for standard build (with lossy DNG support).
If you do not have libjpeg installed, you should remove /DUSE_JPEG from compiler command line.
http://www.my-spot.com/RHC/
http://www.my-spot.com/RHC/RHC_Demosiac.htm
Could you include in this great test the RAWHide program and its Advanced Chroma Corrective Demosaicing algorithm.
thanks
>In fact, unlike TIFF and TIFF/EP, DNG is proprietary and I'm under the impression that Adobe never really had any real intention to standardize it. Proof is the recent additions of the undocumented lossy and fast-load options that creates "DNG" files that only Adobe can read back safely.
I don't think this constitutes proof of nefarious intentions. If no DNG 1.4 specification is published, or if the license for the 1.4 functionality changes, I'd be inclined to agree with you. I don't think advancement is proof of anything other than forward thinking and the need for new functionality.
As to "only Adobe can read back safely", I'm not sure exactly what you are talking about. There are two basic issues. If you are speaking about the issue with Fast Load previews becoming unreadable, here is my understanding.
There is a flaw in the existing dcraw code that improperly treats an alternate IFD as the main IFD. (I think this has been corrected in newer dcraw code.) Since a lot of software uses dcraw, it makes this a widespread issue. The existing specification outlines how DNG readers should understand IFDs. Here's the relevant part of the 1.2 spec as I understand it.
"DNG 1.2.0.0 allows a new value for NewSubFileType equal to 10001.H. This value, used for alternative or non-primary rendered previews, allows for multiple renderings (not just multiple sizes of a single rendering) to be stored in a DNG file. DNG reading software that displays a preview for a DNG file should, by default, display a preview from an IFD with NewSubFileType equal to 1. Alternative renderings should only be displayed if requested by the user."
I believe that dcraw was grabbing the wrong IFD because it was not paying proper attention to the tag.
If your objection is based on the new lossy compressed options, then I'd simply say to wait a little while and see if Adobe continues to do what they have always done so far - fully document the changes and release free SDK code for other applications to make use of (some of) the new functionality.
As to the addition of lossy source image data, it's my understanding that this allows DNG to be a more suitable container for JPEG originals. There is a significant file size economy, which will be useful at times. I'm personally very happy about this addition, since it allows JPEG shooters to store their parametrically edited images in a more appropriate format. (I personally believe that stuffing the EDL back into the JPEG header is a bad hack.) There are other really good and interesting ways for lossy compression to be of use that anyone here should be able to imagine with a little thought.
You are certainly free to believe that any advancement in the specification is prima facie evidence that Adobe is up to no good. It is my hope that they will document and license the new DNG capabilities as they have done for the last few revisions, and that these capabilities will be used by many different software and hardware vendors in valuable ways. i think they have a good track record in this regard.
As to the ISO stuff, if you are really curious, then I suggest you ask them what's up.
Peter
Peter, I just ask you for the ISO submission number and date.
Not links to comments on blogs, posts on usenet, obscure bulletin boards or suggestion to use Google. I want to see a trace of it on http://www.iso.org, something OFFICIAL.
As far as I can tell, DNG was never submitted for standardization.
The post you mention is just from a single individual, and it does not say anything about DNG being submitted for standardization. TIFF/EP being revised with input from DNG ("[having] Adobe's permission to incorporate modifications and developments made for DNG") does not say the Adobe DNG 1.3 specification will become an ISO standard. In fact the post in question was a call for input from anyone, saying the group in charge of TIFF/EP was open to suggestions (which is hardly surprizing).
There is a fine line between incorporating elements of DNG into an existing standard, and making DNG a standard in itself even if DNG was indeed derived from the TIFF/EP. Unofficial Adobe voices (like yours) are riding that line and interpreting it in a way that makes people believe that DNG is a standard, or close to become one.
In fact, unlike TIFF and TIFF/EP, DNG is proprietary and I'm under the impression that Adobe never really had any real intention to standardize it. Proof is the recent additions of the undocumented lossy and fast-load options that creates "DNG" files that only Adobe can read back safely.
DNG just became a closed, opaque format as those additions (some of them turned on by default in recent Adobe software e.g. Lightroom 4.0 and 4.1) are breaking and the lack of documentation makes it very difficult at best for anyone else to read those files.
How do you correlate this recent behavior with a standard, documented and stable format? I call it bait-and-switch from a company working on securing its future more than anything else.
Axel,
A quick use of the Google shows that Dietmar Wueller, a member of TC42 WG18, claimed to receive the offer from Adobe in March of 2007. I was not at the Archiving conference this year where I would have probably talked to Herr Wueller in person. Here is the email referenced on the DNG Wikipedia page.
http://mail.kde.org/pipermail/digikam-devel/2007-April/012129.html
Perhaps you could write to him or to the secretariat of the working group to find out what the current thinking of the group is. Here is the Secretariat's info from the ISO website.
Secretariat direct:
Tel: +1 646-460-7897
Fax: +1 212 398 00 23
E-mail: jknopes@ansi.org
Peter
The ISO keeps track on everything, submitted, rejected, retired, accepted, and lists the status of everything. I keep hearing from unofficial voices, bloggers, Adobe evangelists etc that DNG was submitted to the ISO, yet I could not find ANY trace of it at www.iso.org, which has a comprehensive search engine. In fact the ISO is a champion of traceability and exactly the opposite of a black hole. So, Peter, where is the DNG submission? Please be thorough and post the submission number and date.
Unwind_resume is part of gcc's exception handler (according to goole :).
You need to enable exceptions library (e.g. via linking by g++, not gcc) on link stage.
Linking CXX executable luminance-hdr.exe
c:/progra~2/codebl~1/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
Hi, Im trying to build Luminance HDR using CodeBlocks. I've obtained libraw using this makefile but I'm getting some errors related to references in libraw.
Any idea how to solve it or the origin of this problem?
Thanks in advance!
Raissel
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2299): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x231b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x23e8): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x243b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2625): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2aab): more undefined references to `_Unwind_Resume' follow
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD1Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame+0x427): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream4getsEPci+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream9scanf_oneEPKcPv+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD0Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream16tempbuffer_closeEv+0x13): more undefined references to `__gxx_personality_v0' follow
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x7722): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x79aa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x98fa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa02e): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa636): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xbe07): more undefined references to `__chkstk_ms' follow
collect2: ld returned 1 exit status
mingw32-make.exe[2]: *** [luminance-hdr.exe] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/luminance-hdr.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
Info: resolving half::_eLut by linking to __imp___ZN4half5_eLutE (auto-import)
You may use LibRaw Visual Studio project files (in LibRaw/buildfiles catalog).
It works for me.
Pages