Thanks for you reply. And I have another question.when I read the part of source code in libraw_cxx.cpp, the part of source code is :
char name[100], value[100];
utf2char(P[i].name,name);
utf2char(P[i].value,value);
if (!strcmp (name, "ISO"))
imgdata.other.iso_speed = atoi(value);
I am confused with this part of source code. when you developed this libraw library,how can you read "ISO speed" from Raw file to iso_speed variable of libraw?
Have not used XCode GUI mode.
To re-build LibRaw from command line, start with OS X tuned version (http://www.libraw.org/data/LibRaw-0.16.2-MacOSX.zip). To rebuild it just use
make -f Makefile.dist
It should works fine
Could you possibly explain the steps required to compile those samples? Preferably using xcode?
Also building a command line tool from the modified sample file, how could I do this on a linux system?
I have no experience with working with c++.
I essentially need to extract out the thumbnail from a raw but be able to specify the output directory of the file.
Since I am watching the dir, when any new files are added I process them, but do not want to add the thumbnail to the same directory for several reasons. dcraw does not seem to have a flag to specify an output directory when extracting the thumbnail.
It also is creating strange images when we apply the color profile.
I would love to be able to dig into libraw and start creating dedicated command line tools for our processing, if you could direct me in the right direction to things I would need to learn and tools I would use.
Also, since this is going to run on raspberry pi, would you be able to recommend a build process that would work for a device like that?
I know this may be a lot to ask. Sorry for the newbie questions. Any help is greatly appreciated.
LibRaw's dcraw_emu intended to be used instead of dcraw in most (but not all) cases. If you need some specific command-line tool, start with simple_dcraw sample and modify it at your taste.
I was able to associate the libraw.dll and libraw.h with matlab using loadlibrary function. It builds a function table and I am able to open a raw file and so on. However, I haven't gotten to the point where I can open the bayer pixel data. It has something to do with how pointers are used. In any case, I wanted to let you know it is possible to interface with Matlab.
You may use LibRaw to read RAW image and convert it to RGB bitmap (in memory).
To create JPEG image from this bitmap you'll need another software (LibJPEG or so)
I want to convert raw image to JPEG image including exif information,and get some information like DCT coefficients and so on. Can I do that using libraw library?
I was just trying to build LibRaw with the supplied makefile and then link the created "libraw.lib" or "libraw_static.lib" to my project. So it should already be compiled, just being read by my project when it calls the functions. Is this not an appropriate way to include the source code? It has to be compiled within my code?
If you build LibRaw within your project, you need to set this define for compiler.
If you build LibRaw using supplied Makefile.msvc (as starting point), all things are already set-up.
Just tested with VisualStudio 2013 (it complains about /arch:SSE2, because this option is default now, but compiles LibRaw and examples OK)
So I tried compiling by running "nmake /DLIBRAW_BUILDLIB -f Makefile.msvc" but it said "NMAKE: fatal error U1065: invalid option 'W' Stop."
I'm probably putting that flag in the wrong spot, but I tried to hack around it by swapping the dllimport and dllexport in libraw_types.h, so that it uses dllexport if I don't define that flag, which is what I'm trying to do anyway.
Doing that, I start compiling by running "nmake -f Makefile.msvc" but I get a bunch of errors (it won't let me post all of them because it thinks it's spam, but they all generally look like the following):
libraw_datastream.obj : error LNK2019: unresolved external symbol "__declspec(dl
limport) const LibRaw_windows_datastream::`vftable'" (__imp_??_7LibRaw_windows_d
atastream@@6B@) referenced in function "public: __thiscall LibRaw_windows_datast
ream::LibRaw_windows_datastream(void *)" (??0LibRaw_windows_datastream@@QAE@PAX@
Z)
libraw_c_api.obj : error LNK2019: unresolved external symbol "__declspec(dllimpo
rt) public: int __thiscall LibRaw::COLOR(int,int)" (__imp_?COLOR@LibRaw@@QAEHHH@
Z) referenced in function _libraw_COLOR
demosaic_packs.obj : error LNK2001: unresolved external symbol "__declspec(dllim
port) public: int __thiscall LibRaw::COLOR(int,int)" (__imp_?COLOR@LibRaw@@QAEHH
H@Z)
bin\libraw.dll : fatal error LNK1120: 29 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\cl.EXE"' : return code '0x2'
Please check, that you've build DLL correctly:
- you need to add /DLIBRAW_BUILDLIB to compiler flags when you compile DLL parts
- and do not add this flag if you compile user code that uses libraw.
LibRaw do not care about in-camera crops like 16:9 and always returns full image.
So, if you want to completely repeat Adobe DNG convertor behavior, you need to parse Exif/makernotes metadata (and, possibly, add vendor-specific or camera-specific hints).
AFAIK, Adobe default cropping is because of
- let some space for demosaic (so ignore pixels very close to border)
- let some space for sensor positioning errors (seen in some cameras, within several pixels)
- also, physical masking may produce border effects (like diffraction) close to mask edge.
Thank you, that's very helpful. I'll go with LibRaw's sensor-size and ActiveArea then.
I actually care mostly about the DefaultCrop since that's what the users sees. I guess Adobe reads the final size from the MakerNotes (e.g., Sony has a FullImageSize tag) and then probably centers it in the ActiveArea. Will see if I can extract some of those with libexiv2.
To make it more complicated, there are also ImageWidth/Height Exif tags at least for Canon/Sony, which seem to also include user settings like 16:9 crop. Adobe (in DNG 1.4) interestingly translates that to DefaultUserCrop, which means the DNG includes 4 nested crops (sensor size, active area, default crop, default user crop)...
Unfortunately, there is no any 'system' in LibRaw margin (ActiveArea) size.
- some of values are derived from dcraw without change
- some of values are read from RAW metadata
- some of values are assigned by hand with 'maximum possible area' in mind.
For entire sensor size, Adobe DNG convertor crops sensor data for some cameras for unknown reason. Also, this cropping may change with DNG convertor version change (I've seen this at least on some Fuji cameras).
Sensor size is definitely right in LibRaw. Wrong raw_width will result in completely distorted image, wrong (too small) raw_height will result in buffer overrun.
This piece of code is related only to foveon images with own (non-EXIF) metadata format
Thanks for you reply. And I have another question.when I read the part of source code in libraw_cxx.cpp, the part of source code is :
char name[100], value[100];
utf2char(P[i].name,name);
utf2char(P[i].value,value);
if (!strcmp (name, "ISO"))
imgdata.other.iso_speed = atoi(value);
I am confused with this part of source code. when you developed this libraw library,how can you read "ISO speed" from Raw file to iso_speed variable of libraw?
Have not used XCode GUI mode.
To re-build LibRaw from command line, start with OS X tuned version (http://www.libraw.org/data/LibRaw-0.16.2-MacOSX.zip). To rebuild it just use
make -f Makefile.dist
It should works fine
Thank you Alex.
Could you possibly explain the steps required to compile those samples? Preferably using xcode?
Also building a command line tool from the modified sample file, how could I do this on a linux system?
I have no experience with working with c++.
I essentially need to extract out the thumbnail from a raw but be able to specify the output directory of the file.
Since I am watching the dir, when any new files are added I process them, but do not want to add the thumbnail to the same directory for several reasons. dcraw does not seem to have a flag to specify an output directory when extracting the thumbnail.
It also is creating strange images when we apply the color profile.
I would love to be able to dig into libraw and start creating dedicated command line tools for our processing, if you could direct me in the right direction to things I would need to learn and tools I would use.
Also, since this is going to run on raspberry pi, would you be able to recommend a build process that would work for a device like that?
I know this may be a lot to ask. Sorry for the newbie questions. Any help is greatly appreciated.
Thank you!
LibRaw's dcraw_emu intended to be used instead of dcraw in most (but not all) cases. If you need some specific command-line tool, start with simple_dcraw sample and modify it at your taste.
Thank you for this resource, as always. - Kirk
Unfortunately, I know nothing about matlab extensions.
I was able to associate the libraw.dll and libraw.h with matlab using loadlibrary function. It builds a function table and I am able to open a raw file and so on. However, I haven't gotten to the point where I can open the bayer pixel data. It has something to do with how pointers are used. In any case, I wanted to let you know it is possible to interface with Matlab.
Sorry for delayed answer (all forum posts are pre-moderated due to forum spam).
You may use LibRaw to read RAW data and convert it to RGB bitmap.
To pack to JPEG you'll need another library (libjpeg or so)
You may use LibRaw to read RAW image and convert it to RGB bitmap (in memory).
To create JPEG image from this bitmap you'll need another software (LibJPEG or so)
I want to convert raw image to JPEG image including exif information,and get some information like DCT coefficients and so on. Can I do that using libraw library?
You're able to build samples, right?
Samples are build by very simple command (assuming DLL has build before):
cl $(COPT) /Feoutputfilename.exe sample-source.cpp lib\libraw.dll
You may need to adjust COPT variable (in Makefile.msvc) accoriding to your project build flags (runtime library, exception handling).
I was just trying to build LibRaw with the supplied makefile and then link the created "libraw.lib" or "libraw_static.lib" to my project. So it should already be compiled, just being read by my project when it calls the functions. Is this not an appropriate way to include the source code? It has to be compiled within my code?
Also, you do not need to swap dllimport/export in libraw_types.h
If you build LibRaw within your project, you need to set this define for compiler.
If you build LibRaw using supplied Makefile.msvc (as starting point), all things are already set-up.
Just tested with VisualStudio 2013 (it complains about /arch:SSE2, because this option is default now, but compiles LibRaw and examples OK)
Isn't that what you told me to do in your previous comment?
You do not need to pass anything to Makefile.msvc, all flags are set OK within this Makefile
So I tried compiling by running "nmake /DLIBRAW_BUILDLIB -f Makefile.msvc" but it said "NMAKE: fatal error U1065: invalid option 'W' Stop."
I'm probably putting that flag in the wrong spot, but I tried to hack around it by swapping the dllimport and dllexport in libraw_types.h, so that it uses dllexport if I don't define that flag, which is what I'm trying to do anyway.
Doing that, I start compiling by running "nmake -f Makefile.msvc" but I get a bunch of errors (it won't let me post all of them because it thinks it's spam, but they all generally look like the following):
libraw_datastream.obj : error LNK2019: unresolved external symbol "__declspec(dl
limport) const LibRaw_windows_datastream::`vftable'" (__imp_??_7LibRaw_windows_d
atastream@@6B@) referenced in function "public: __thiscall LibRaw_windows_datast
ream::LibRaw_windows_datastream(void *)" (??0LibRaw_windows_datastream@@QAE@PAX@
Z)
libraw_c_api.obj : error LNK2019: unresolved external symbol "__declspec(dllimpo
rt) public: int __thiscall LibRaw::COLOR(int,int)" (__imp_?COLOR@LibRaw@@QAEHHH@
Z) referenced in function _libraw_COLOR
demosaic_packs.obj : error LNK2001: unresolved external symbol "__declspec(dllim
port) public: int __thiscall LibRaw::COLOR(int,int)" (__imp_?COLOR@LibRaw@@QAEHH
H@Z)
bin\libraw.dll : fatal error LNK1120: 29 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\cl.EXE"' : return code '0x2'
Please check, that you've build DLL correctly:
- you need to add /DLIBRAW_BUILDLIB to compiler flags when you compile DLL parts
- and do not add this flag if you compile user code that uses libraw.
The trick is within libraw_types.h:
So, when you compile DLL, all needed functions are marked as dllexport
That should say I've added a #include < libraw.h > without the spaces but I guess it thought I was trying to add some kind of HTML tag
LibRaw do not care about in-camera crops like 16:9 and always returns full image.
So, if you want to completely repeat Adobe DNG convertor behavior, you need to parse Exif/makernotes metadata (and, possibly, add vendor-specific or camera-specific hints).
AFAIK, Adobe default cropping is because of
- let some space for demosaic (so ignore pixels very close to border)
- let some space for sensor positioning errors (seen in some cameras, within several pixels)
- also, physical masking may produce border effects (like diffraction) close to mask edge.
Thank you, that's very helpful. I'll go with LibRaw's sensor-size and ActiveArea then.
I actually care mostly about the DefaultCrop since that's what the users sees. I guess Adobe reads the final size from the MakerNotes (e.g., Sony has a FullImageSize tag) and then probably centers it in the ActiveArea. Will see if I can extract some of those with libexiv2.
To make it more complicated, there are also ImageWidth/Height Exif tags at least for Canon/Sony, which seem to also include user settings like 16:9 crop. Adobe (in DNG 1.4) interestingly translates that to DefaultUserCrop, which means the DNG includes 4 nested crops (sensor size, active area, default crop, default user crop)...
Unfortunately, there is no any 'system' in LibRaw margin (ActiveArea) size.
- some of values are derived from dcraw without change
- some of values are read from RAW metadata
- some of values are assigned by hand with 'maximum possible area' in mind.
For entire sensor size, Adobe DNG convertor crops sensor data for some cameras for unknown reason. Also, this cropping may change with DNG convertor version change (I've seen this at least on some Fuji cameras).
Sensor size is definitely right in LibRaw. Wrong raw_width will result in completely distorted image, wrong (too small) raw_height will result in buffer overrun.
Solved, now I'm able to get the exact match.
Thank you!
P.S. Please note -h key (half interpolation), because AHD interpolation is slightly different in LibRaw and dcraw.
For binary comparison, you may use -q 1 (VNG interpolation, same in LibRaw and dcraw).
Pages