After unpack(), I'm trying to use the raw_image as an input to opencv demosaicing (with cvtColor and type CV_BayerGB2RGB), and thus avoid the use of dcraw_process for demosaicing. opencv here requires a 1-channel data image. Yet when I use the raw data after unpac(), starting from the first visible pixel, it gives me some rubbish image.
As far as you know at least on the Libraw's side, am I getting the raw CFA data wrong? See below:
int raw_width = (int) rawProcess.imgdata.sizes.raw_width;
int top_margin = (int) rawProcess.imgdata.sizes.top_margin;
int left_margin = (int) rawProcess.imgdata.sizes.left_margin;
int first_visible_pixel = (int) (raw_width * top_margin + left_margin);
cv::Mat imRaw(naxis2, naxis1, CV_16UC1);
ushort *rawP = imRaw.ptr<ushort>(0);
for (int i = 0; i < nPixels; i++)
{
rawP[i] = (ushort) rawProcess.imgdata.rawdata.raw_image[i+first_visible_pixel];
}
cv::Mat demosaiced16;
cvtColor(imRaw, demosaiced16, CV_BayerGB2RGB);
Above, imRaw.ptr is the pointer to the data buffer in the cv::Mat object where I want to copy my raw_image data.
I know they can be vendor specific but I wondered if you would take patches for decoding such information?
For example to get access to the Canon data, parse_makernote() would need code around line 8686 something like:
else if (tag == 0x0098) // CropInfo
{
unsigned short CropLeft = get2();
unsigned short CropRight = get2();
unsigned short CropTop = get2();
unsigned short CropBottom = get2();
fprintf (stderr, " Cropinfo %d %d %d %d\n", CropLeft, CropRight, CropTop, CropBottom);
}
else if (tag == 0x009a) // AspectInfo
{
unsigned int ratio = get4();
unsigned int CroppedWidth = get4();
unsigned int CroppedHeight = get4();
unsigned int CropLeft = get4();
unsigned int CropTop = get4();
fprintf (stderr, " AspectInfo %d %d %d %d %d\n", ratio, CroppedWidth, CroppedHeight,
CropLeft, CropTop);
}
}
Obviously this would need storing somewhere useful rather than simply printing it out, but that could then be passed back to the real crop functionality
I've managed creating dynamically loaded libraries of LibRaw for Mac, Win32 and Win64 now. The only thing that remains are dynamic libraries for Linux32 and Linux64. I would very much appreciate your help with this. When running the make file I end up with .a, .la and .lib files only.
I appreciate your help in creating a 64 bit version of LibRaw for Windows. I can interface with this library version from a 64 bit Java VM using BridJ, but if I try to call the init() method of LibRaw when compiled as a 64 bit dll it crashes. I get EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x00007ffdd79069ac, pid=6876, tid=6592. Any clue on what I can do?
LibRaw assumes *full* raw file is available. If not, the file may be rejected.
In some cases only some part of file is sufficient for metadata parse, but there is no general rule: it is possible that RAW data is recorded before some other metadata (this is the case for Canon CRW files, for example.
You may implement own I/O layer which will ask downloader to download requested file part(s)
I will take a look at this, but I am probably not going to pick up the next release right away. I got into this because my dcraw "adaptation" wasn't working as well as it should and I thought LibRaw might save me a lot of work. It certainly has, because all in all, dcraw is a monolithic global-variable mess. It might sort of be OK for a stand-alone program, but I am not even sure of that. I do know that it is very difficult for someone to maintain the way it is.
So I have my little graphics interface DLL now working with the updated dcraw code and this brings it into the more "modern era". I have also brought in a faster JPEG decoder and I believe this will benefit the applications that use this DLL greatly. So now I get to spend a bunch of time working on those applications with a lot more confidence in the graphics DLL.
Checked all old kodak files with current (-development) LibRaw branch with both open_file() and open_buffer(). All OK.
development branch to be updated on GitHub in few days
I used vcvars32.bat initially to build the correct libraw.dll but then figured i should use vcvarsall.bat for 64 bit build, though there was no difference. If that's not the correct way, how do you rebuild it with 64bit? Thanks a lot again
Thank you for your response. So when machine module type and target is set to x86, everything works fine. When I convert both to x64 From Release Target in Configuration Manager and Linker -> Advanced -> Target Machine, I get the following output:
1>------ Rebuild All started: Project: LibrawReader, Configuration: Release x64 ------
1> readFile.cpp
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(98): warning C4251: 'LibRaw_file_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(101): warning C4251: 'LibRaw_file_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(200): warning C4251: 'LibRaw_bigfile_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(203): warning C4251: 'LibRaw_bigfile_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl LibRaw::~LibRaw(void)" (__imp_??1LibRaw@@UEAA@XZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl LibRaw::recycle(void)" (__imp_?recycle@LibRaw@@QEAAXXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::raw2image(void)" (__imp_?raw2image@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::unpack(void)" (__imp_?unpack@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z)
1>c:\users\imnet\documents\visual studio 2013\Projects\LibrawReader\x64\Release\LibrawReader.exe : fatal error LNK1120: 6 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
OK, mystery solved. I use current (our development) branch for testing.
This branch to be pushed on GitHub within 2-3 weeks, our repository is here.
Or just add these lines to apply_tiff:
1Mb malloc is not much in today raw processing. 50Mpix Canon RAW, processed in full-res in float (16 bytes per pixel) is slightly less than 1Gb (and my phone have 2GB RAM)
Working on embedded systems and games with as little as 128 BYTES of RAM conditions one in different ways and makes one think a bit before doing some things.
I can see where it would be good to set data_size in apply_tiff, but in the code I downloaded from libraw.org it isn't happening. Seems like the statement
data_size = tiff_ifd[i].bytes
would be a good idea to have there, but in the 0.17 code it is not there.
We'll release massive update to 'master' Github branch in 2-3 weeks. The update will include support for this data format. Follow us on GitHub: https://github.com/LibRaw/LibRaw
After unpack(), I'm trying to use the raw_image as an input to opencv demosaicing (with cvtColor and type CV_BayerGB2RGB), and thus avoid the use of dcraw_process for demosaicing. opencv here requires a 1-channel data image. Yet when I use the raw data after unpac(), starting from the first visible pixel, it gives me some rubbish image.
As far as you know at least on the Libraw's side, am I getting the raw CFA data wrong? See below:
int raw_width = (int) rawProcess.imgdata.sizes.raw_width; int top_margin = (int) rawProcess.imgdata.sizes.top_margin; int left_margin = (int) rawProcess.imgdata.sizes.left_margin; int first_visible_pixel = (int) (raw_width * top_margin + left_margin); cv::Mat imRaw(naxis2, naxis1, CV_16UC1); ushort *rawP = imRaw.ptr<ushort>(0); for (int i = 0; i < nPixels; i++) { rawP[i] = (ushort) rawProcess.imgdata.rawdata.raw_image[i+first_visible_pixel]; } cv::Mat demosaiced16; cvtColor(imRaw, demosaiced16, CV_BayerGB2RGB);Above, imRaw.ptr is the pointer to the data buffer in the cv::Mat object where I want to copy my raw_image data.
The expected image (which I get after dcraw_process) is:
https://www.dropbox.com/s/unn695en6hpdr3j/dcraw_process.jpg?dl=0
And instead, I have this:
https://www.dropbox.com/s/c1f8s3fjgqy0tit/Failed_demosaic.jpg?dl=0
I know they can be vendor specific but I wondered if you would take patches for decoding such information?
For example to get access to the Canon data, parse_makernote() would need code around line 8686 something like:
else if (tag == 0x0098) // CropInfo
{
unsigned short CropLeft = get2();
unsigned short CropRight = get2();
unsigned short CropTop = get2();
unsigned short CropBottom = get2();
fprintf (stderr, " Cropinfo %d %d %d %d\n", CropLeft, CropRight, CropTop, CropBottom);
}
else if (tag == 0x009a) // AspectInfo
{
unsigned int ratio = get4();
unsigned int CroppedWidth = get4();
unsigned int CroppedHeight = get4();
unsigned int CropLeft = get4();
unsigned int CropTop = get4();
fprintf (stderr, " AspectInfo %d %d %d %d %d\n", ratio, CroppedWidth, CroppedHeight,
CropLeft, CropTop);
}
}
Obviously this would need storing somewhere useful rather than simply printing it out, but that could then be passed back to the real crop functionality
Kevin
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-9.90/html/TagName...
thanks
1st google result for lensfun is http://lensfun.sourceforge.net/
Sorry to say that I am new in this field.
what is this lensfun?
No.
Use lensfun.
Sorry, I know nothing about Linux shared libraries creation.
./configure should work, meanwhile.
It's a huge makefile, any tip on what to change there?
yes, you need to change makefile, or use ./configure stuff.
I've managed creating dynamically loaded libraries of LibRaw for Mac, Win32 and Win64 now. The only thing that remains are dynamic libraries for Linux32 and Linux64. I would very much appreciate your help with this. When running the make file I end up with .a, .la and .lib files only.
LibRaw (C++ API) do not have init() method. So, I do not know what you call.
I appreciate your help in creating a 64 bit version of LibRaw for Windows. I can interface with this library version from a 64 bit Java VM using BridJ, but if I try to call the init() method of LibRaw when compiled as a 64 bit dll it crashes. I get EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x00007ffdd79069ac, pid=6876, tid=6592. Any clue on what I can do?
LibRaw assumes *full* raw file is available. If not, the file may be rejected.
In some cases only some part of file is sufficient for metadata parse, but there is no general rule: it is possible that RAW data is recorded before some other metadata (this is the case for Canon CRW files, for example.
You may implement own I/O layer which will ask downloader to download requested file part(s)
I will take a look at this, but I am probably not going to pick up the next release right away. I got into this because my dcraw "adaptation" wasn't working as well as it should and I thought LibRaw might save me a lot of work. It certainly has, because all in all, dcraw is a monolithic global-variable mess. It might sort of be OK for a stand-alone program, but I am not even sure of that. I do know that it is very difficult for someone to maintain the way it is.
So I have my little graphics interface DLL now working with the updated dcraw code and this brings it into the more "modern era". I have also brought in a faster JPEG decoder and I believe this will benefit the applications that use this DLL greatly. So now I get to spend a bunch of time working on those applications with a lot more confidence in the graphics DLL.
Checked all old kodak files with current (-development) LibRaw branch with both open_file() and open_buffer(). All OK.
development branch to be updated on GitHub in few days
Thank you Alex. It Worked. I am very very grateful. All the best.
And vcvarsall without x64 will create x86 environment, just first lines from this .bat:
vcvars32 surely will set x32 environment.
To rebuild 64-bit libraw.dll I succesfully use this:
I used vcvars32.bat initially to build the correct libraw.dll but then figured i should use vcvarsall.bat for 64 bit build, though there was no difference. If that's not the correct way, how do you rebuild it with 64bit? Thanks a lot again
unresolved symbols mean you cannot link with correct .dll (or lib).
Are you sure you've rebuilt libraw.dll with 64 bit?
Thank you for your response. So when machine module type and target is set to x86, everything works fine. When I convert both to x64 From Release Target in Configuration Manager and Linker -> Advanced -> Target Machine, I get the following output:
1>------ Rebuild All started: Project: LibrawReader, Configuration: Release x64 ------
1> readFile.cpp
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(98): warning C4251: 'LibRaw_file_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(101): warning C4251: 'LibRaw_file_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_file_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(200): warning C4251: 'LibRaw_bigfile_datastream::filename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>c:\users\imnet\downloads\compressed\libraw-0.17.0_2\libraw-0.17.0\libraw\libraw_datastream.h(203): warning C4251: 'LibRaw_bigfile_datastream::wfilename' : class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'LibRaw_bigfile_datastream'
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl LibRaw::~LibRaw(void)" (__imp_??1LibRaw@@UEAA@XZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl LibRaw::recycle(void)" (__imp_?recycle@LibRaw@@QEAAXXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::raw2image(void)" (__imp_?raw2image@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::unpack(void)" (__imp_?unpack@LibRaw@@QEAAHXZ)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z)
1>readFile.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z)
1>c:\users\imnet\documents\visual studio 2013\Projects\LibrawReader\x64\Release\LibrawReader.exe : fatal error LNK1120: 6 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
What do you think is the problem?
OK, mystery solved. I use current (our development) branch for testing.
This branch to be pushed on GitHub within 2-3 weeks, our repository is here.
Or just add these lines to apply_tiff:
data_offset = tiff_ifd[i].offset; +#ifdef LIBRAW_LIBRARY_BUILD + data_size = tiff_ifd[i].bytes; +#endif tiff_flip = tiff_ifd[i].t_flip;1Mb malloc is not much in today raw processing. 50Mpix Canon RAW, processed in full-res in float (16 bytes per pixel) is slightly less than 1Gb (and my phone have 2GB RAM)
These days, a malloc under 1MB isn't huge at all.
Working on embedded systems and games with as little as 128 BYTES of RAM conditions one in different ways and makes one think a bit before doing some things.
I can see where it would be good to set data_size in apply_tiff, but in the code I downloaded from libraw.org it isn't happening. Seems like the statement
would be a good idea to have there, but in the 0.17 code it is not there.
data_size is set within apply_tiff() code.
malloc is not 'huge': Kodak JPEG-codec cameras are DC50 (0.5Mpix) and DC120 (1Mpix). Real data size is less than 1Mb.
We'll release massive update to 'master' Github branch in 2-3 weeks. The update will include support for this data format. Follow us on GitHub: https://github.com/LibRaw/LibRaw
LibRaw 0.17 will *not* be updated.
Pages