Thanks for your answer and suggestion.
I'm trying to compile a .cpp file using g++ and linking libraw, but i'm getting "undefined reference" error. This is the instruction that i'm using:
can you tell me please what i am doing wrong?, at least please point me in the right direction, i know the solution must be plain simple, but i'm not really an expert and i don't see it.
Confirmed, the CFLAGS approach works. Even though its needs some manual intervention.
I hope to can make the openSUSE package using this compiler flag. Thanks for the reply.
LibRaw is specially built as static (not dynamic) library under unix systems because ABI is changed frequently and there is no way to translate ABI of one version into data layout of another one.
However, it is possible to specify CFLAGS/CXXFLAGS/LDFLAGS on ./configure call.
For many (but not all) RAW formats, you can use this trick:
1) Call LibRaw::open_file()
2) Position to libraw_internal_data.unpacker_data.data_offset
3) Read libraw_internal_data.unpacker_data.data_size bytes
This method will work with Canon CR2, Nikon NEFs and many others.
This method will not work for tiled DNGs
Hi,
According to the sample code, the option "unprocessed_raw" extracts (mostly) unaltered RAW data including masked pixels data.
Is it possible to extract ALL unprocessed raw data, without the metadata and the thumbnail in order to save it into a new binary file?, can you please point me in the right direction to do this using LibRaw?.
I have not a look into dlraw source, so my assumptions are based on your short explanation.
It looks like you have own postprocessing pipeline, different from dcraws. I guess, you may use LibRaw's as RAW reading tool (open_file() and unpack() calls), then switch to own processing pipeline.
Licensing is not a problem: LibRaw is licensed under LGPL ('upgradeable' to your GPL3), demosaic-pack-GPL2 is licensed under GPL2+ (also no problem) and AMaZE is licensed under GPL3, no problem too.
I'm unable to reproduce crash, could you please make your problematic image available somewhere via file sharing service(s) like megaupload or rapidshare?
Finally, I've buildt it. If somebody else is interested in building the thread-safe library using MinGW, here the Makefile (for v. 0.11.3). It works fine.
Thanks for your help,
Davide
Luminance HDR Developer
--------------------------------------
all: library samples
# OpenMP support
#OPENMP_CFLAGS=-fopenmp
#NO_THREADS=-DLIBRAW_NOTHREADS
# LCMS support
#LCMS_DEF=-DUSE_LCMS -I/usr/local/include
#LCMS_LIB=-L/usr/local/lib -llcms
for gcc compiler, -pthread is for generating thread-safe code. At least, it should
- define _REENTRANT, so many #includes will change behaviour
- link with thread-safe C runtime
I'm not sure that MinGW has multi-thread safe runtime.
Unfortunately, the static build made by MinGW (I did it already) of the thread-safe library (libraw_r) gives me exactly the same error during the linking. I'll try with the one included in your link this evening and I'll let you know.
You can integrate C-code in MATLAB using the mex-API. I looked at this for dcraw, but got stuck, and I found that it was simply less work to make a thin MATLAB wrapper calling dcraw from the command-line.
I remember some frustrating aspects of doing anything to the dcraw code, hope that this project makes it easier.
LibRaw (and, so, dcraw_emu) contains 'auto-maximum' feature to deal with 'pink clouds' problem.
If you want to produce files which are binary identical to dcraw's results, you should switch this option off. Use -c 0 switch of dcraw_emu to do that.
So, if your code crashes in ::free(), it should crash in LibRaw's free() too. For pointer allocated by ::malloc() there is no difference between LibRaw::free() and ::free().
I cannot reproduce this problem in my Windows enviroment (VS2008 SP1, Win7/x64).
Could you please describe your enviroment in more detail (VS2008 patch level, Windows version, may be sample code)?
P.S. Sorry for very aggressive captcha. This is the only way to prevent forum/comments spam.
Please note, that registered/authorized users are not terrorized by captcha :)
What references are undefined?
Usually, you need math library added to linker command line (-lm switch)
Thanks for your answer and suggestion.
I'm trying to compile a .cpp file using g++ and linking libraw, but i'm getting "undefined reference" error. This is the instruction that i'm using:
g++ ext-raw-dat.cpp -o extract -I/usr/local/include/libraw -L/usr/local/lib -lraw
can you tell me please what i am doing wrong?, at least please point me in the right direction, i know the solution must be plain simple, but i'm not really an expert and i don't see it.
Thanks in advance.
Confirmed, the CFLAGS approach works. Even though its needs some manual intervention.
I hope to can make the openSUSE package using this compiler flag. Thanks for the reply.
LibRaw is specially built as static (not dynamic) library under unix systems because ABI is changed frequently and there is no way to translate ABI of one version into data layout of another one.
However, it is possible to specify CFLAGS/CXXFLAGS/LDFLAGS on ./configure call.
For many (but not all) RAW formats, you can use this trick:
1) Call LibRaw::open_file()
2) Position to libraw_internal_data.unpacker_data.data_offset
3) Read libraw_internal_data.unpacker_data.data_size bytes
This method will work with Canon CR2, Nikon NEFs and many others.
This method will not work for tiled DNGs
Hi,
According to the sample code, the option "unprocessed_raw" extracts (mostly) unaltered RAW data including masked pixels data.
Is it possible to extract ALL unprocessed raw data, without the metadata and the thumbnail in order to save it into a new binary file?, can you please point me in the right direction to do this using LibRaw?.
Thanks in advance for your kindly answer.
Thanks!
To be included into next releases!
I have not a look into dlraw source, so my assumptions are based on your short explanation.
It looks like you have own postprocessing pipeline, different from dcraws. I guess, you may use LibRaw's as RAW reading tool (open_file() and unpack() calls), then switch to own processing pipeline.
Licensing is not a problem: LibRaw is licensed under LGPL ('upgradeable' to your GPL3), demosaic-pack-GPL2 is licensed under GPL2+ (also no problem) and AMaZE is licensed under GPL3, no problem too.
Yes, DP1 images are unsupported.
I'm unable to reproduce crash, could you please make your problematic image available somewhere via file sharing service(s) like megaupload or rapidshare?
Thanks,
I'll modify distributed Makefile.mingw with possibility to build thread-safe
Finally, I've buildt it. If somebody else is interested in building the thread-safe library using MinGW, here the Makefile (for v. 0.11.3). It works fine.
Thanks for your help,
Davide
Luminance HDR Developer
--------------------------------------
all: library samples
# OpenMP support
#OPENMP_CFLAGS=-fopenmp
#NO_THREADS=-DLIBRAW_NOTHREADS
# LCMS support
#LCMS_DEF=-DUSE_LCMS -I/usr/local/include
#LCMS_LIB=-L/usr/local/lib -llcms
# Common flags
# WARNING: library order matters
COMMON_LIBS=-lws2_32 -lm ${LCMS_LIB}
CLIBS=-L./lib -lraw_r ${COMMON_LIBS}
CFLAGS=-O3 -I. -w -DLIBRAW_NODLL ${OPENMP_CFLAGS} ${NO_THREADS} -lpthread -D_REENTRANT
DCRAW_LIB_OBJECTS=object/libraw_cxx.o object/libraw_c_api.o object/dcraw_common.o object/dcraw_fileio.o
library: lib/libraw_r.a
samples: bin/raw-identify bin/simple_dcraw bin/dcraw_emu bin/dcraw_half bin/mem_image bin/mem_image bin/unprocessed_raw bin/4channels
install: library
@if [ -d /usr/local/include ] ; then cp -R libraw /usr/local/include/ ; else echo 'no /usr/local/include' ; fi
@if [ -d /usr/local/lib ] ; then cp lib/libraw_r.a /usr/local/lib/ ; else echo 'no /usr/local/lib' ; fi
install-samples: samples
@if [ -d /usr/local/bin ] ; then cp bin/[a-z]* /usr/local/bin/ ; else echo 'no /usr/local/bin' ; fi
# Samples
bin/raw-identify: lib/libraw_r.a samples/raw-identify.cpp
g++ ${LCMS_DEF} ${CFLAGS} -o bin/raw-identify samples/raw-identify.cpp ${CLIBS}
bin/unprocessed_raw: lib/libraw_r.a samples/unprocessed_raw.cpp
g++ ${LCMS_DEF} ${CFLAGS} -o bin/unprocessed_raw samples/unprocessed_raw.cpp ${CLIBS}
bin/4channels: lib/libraw_r.a samples/4channels.cpp
g++ ${LCMS_DEF} ${CFLAGS} -o bin/4channels samples/4channels.cpp ${CLIBS}
bin/simple_dcraw: lib/libraw_r.a samples/simple_dcraw.cpp
g++ ${LCMS_DEF} ${CFLAGS} -o bin/simple_dcraw samples/simple_dcraw.cpp ${CLIBS}
bin/mem_image: lib/libraw_r.a samples/mem_image.cpp
g++ ${LCMS_DEF} ${CFLAGS} -o bin/mem_image samples/mem_image.cpp ${CLIBS}
bin/dcraw_half: lib/libraw_r.a object/dcraw_half.o
gcc ${LCMS_DEF} ${CFLAGS} -o bin/dcraw_half object/dcraw_half.o ${CLIBS} -lstdc++
bin/dcraw_emu: lib/libraw_r.a samples/dcraw_emu.cpp
g++ ${LCMS_DEF} ${CFLAGS} -o bin/dcraw_emu samples/dcraw_emu.cpp ${CLIBS}
#Libraries
# Non-threaded library
object/dcraw_common.o: internal/dcraw_common.cpp
g++ -c ${LCMS_DEF} ${CFLAGS} -o object/dcraw_common.o internal/dcraw_common.cpp
object/dcraw_fileio.o: internal/dcraw_fileio.cpp
g++ -c ${LCMS_DEF} ${CFLAGS} -o object/dcraw_fileio.o internal/dcraw_fileio.cpp
object/libraw_cxx.o: src/libraw_cxx.cpp
g++ -c ${LCMS_DEF} ${CFLAGS} -o object/libraw_cxx.o src/libraw_cxx.cpp
object/libraw_c_api.o: src/libraw_c_api.cpp
g++ -c ${LCMS_DEF} ${CFLAGS} -o object/libraw_c_api.o src/libraw_c_api.cpp
object/dcraw_half.o: samples/dcraw_half.c
gcc -c ${LCMS_DEF} ${CFLAGS} -o object/dcraw_half.o samples/dcraw_half.c
lib/libraw_r.a: ${DCRAW_LIB_OBJECTS}
-rm -f lib\\libraw_r.a
ar crv lib/libraw_r.a ${DCRAW_LIB_OBJECTS}
ranlib lib/libraw_r.a
# Clean
clean:
rm -f bin\\*.dSYM
rm -f lib\\lib*.a bin\\*.exe object\\*.o
for gcc compiler, -pthread is for generating thread-safe code. At least, it should
- define _REENTRANT, so many #includes will change behaviour
- link with thread-safe C runtime
I'm not sure that MinGW has multi-thread safe runtime.
What does -pthread stays for? My compiler (GCC 4.4.0 on MinGW) says that it is a unrecognized option.
Oh,
MinGW library is compiled without thread-safeness. You may try:
1) Add -pthread to CFLAGS in Makefile.mingw
2) Remove -DLIBRAW_NOTHREADS from all compilation rules.
I've added it to TODO for 0.12-Beta3 too
Unfortunately, the static build made by MinGW (I did it already) of the thread-safe library (libraw_r) gives me exactly the same error during the linking. I'll try with the one included in your link this evening and I'll let you know.
Thanks,
Davide
There are two different Win32 distributions of 0.11:
-Win32, compiled and linked by Visual Studio 2008
-Win32-MinGW - made by MinGW with gcc 4.4
These versions are not compatible.
MinGW version does not contain any .dll, only libraw.a for static linking.
You need either rebuild LibRaw from sources using mingw (mingw32-make -f Makefile.mingw) or download already built -MinGW version.
Direct link to 0.11.3/MinGW: http://www.libraw.org/data/LibRaw-0.11.3-Win32-MinGW.zip
Link to Rawnalyze backup copy: http://rawnalyze.rawtherapee.com/
Thanks for your patch.
It is integrated into LibRaw 0.11.3 and into coming LibRaw 0.12
You can integrate C-code in MATLAB using the mex-API. I looked at this for dcraw, but got stuck, and I found that it was simply less work to make a thin MATLAB wrapper calling dcraw from the command-line.
I remember some frustrating aspects of doing anything to the dcraw code, hope that this project makes it easier.
(the spam-filter here really hurts!)
Yes, output is converted to 8-bit only on file/memory writing stage (i.e. on output).
So, you may call dcraw_make_mem_image() to create 3-component 8-bit bitmap.
LibRaw (and, so, dcraw_emu) contains 'auto-maximum' feature to deal with 'pink clouds' problem.
If you want to produce files which are binary identical to dcraw's results, you should switch this option off. Use -c 0 switch of dcraw_emu to do that.
New versions of LibRaw are imported in KDE (libkdcraw) very fast. Usually in 1-2 days. So you just need to update your KDE extra libs from KDE trunk
The only real and easy solution is to write your files in .DNG format. Sure, there is no way to write CR2
Please see:
http://www.barrypearson.co.uk/articles/dng/specification.htm#areas
Using dng_validate or an EXIF metadata viewer should be able to tell you the resolutions of the various areas in your DNG file.
The libraw_memmgr::free() is very simple, it just calls upper level ::free than forgets the pointer:
So, if your code crashes in ::free(), it should crash in LibRaw's free() too. For pointer allocated by ::malloc() there is no difference between LibRaw::free() and ::free().
I cannot reproduce this problem in my Windows enviroment (VS2008 SP1, Win7/x64).
Could you please describe your enviroment in more detail (VS2008 patch level, Windows version, may be sample code)?
P.S. Sorry for very aggressive captcha. This is the only way to prevent forum/comments spam.
Please note, that registered/authorized users are not terrorized by captcha :)
Pages