I have generated the backtrace from valgrind. Here you go:
==23395== Process terminating with default action of signal 11 (SIGSEGV)
==23395== Bad permissions for mapped region at address 0x5185000
==23395== at 0x4EC4DBB: LibRaw::adobe_coeff(unsigned int, char const*, int) (colordata.cpp:1697)
==23395== by 0x4EAC172: LibRaw::GetNormalizedModel() (normalize_model.cpp:1157)
==23395== by 0x4E9C07D: LibRaw::identify() (identify.cpp:1071)
==23395== by 0x4EC7C95: LibRaw::open_datastream(LibRaw_abstract_datastream*) (open.cpp:376)
==23395== by 0x4EC94F0: LibRaw::open_file(char const*, long long) (open.cpp:52)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== HEAP SUMMARY:
==23395== in use at exit: 298,973 bytes in 9 blocks
==23395== total heap usage: 27 allocs, 18 frees, 343,743 bytes allocated
==23395==
==23395== Searching for pointers to 9 not-freed blocks
==23395== Checked 1,382,688 bytes
==23395==
==23395== 8 bytes in 1 blocks are still reachable in loss record 1 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x5E1A868: ??? (in /usr/lib64/libgomp.so.1.0.0)
==23395== by 0x5E2968B: ??? (in /usr/lib64/libgomp.so.1.0.0)
==23395== by 0x5E18EC6: ??? (in /usr/lib64/libgomp.so.1.0.0)
==23395== by 0x400F4C2: _dl_init (in /usr/lib64/ld-2.17.so)
==23395== by 0x40011A9: ??? (in /usr/lib64/ld-2.17.so)
==23395== by 0x2: ???
==23395== by 0x1FFF0003D2: ???
==23395== by 0x1FFF0003DF: ???
==23395== by 0x1FFF0003E2: ???
==23395==
==23395== 37 bytes in 1 blocks are still reachable in loss record 2 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x58C4CF8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58C6580: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58C69B7: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x4E56AA5: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:56)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 40 bytes in 1 blocks are still reachable in loss record 3 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x4EC947F: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 240 bytes in 1 blocks are still reachable in loss record 4 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x4E56AEA: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:70)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 568 bytes in 1 blocks are still reachable in loss record 5 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x64D458C: __fopen_internal (in /usr/lib64/libc-2.17.so)
==23395== by 0x58834FF: std::__basic_file::open(char const*, std::_Ios_Openmode, int) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58BE7F9: std::basic_filebuf >::open(char const*, std::_Ios_Openmode) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x4E56B06: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:74)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 2,560 bytes in 1 blocks are still reachable in loss record 6 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x4ECC062: malloc (libraw_alloc.h:49)
==23395== by 0x4ECC062: LibRaw::malloc(unsigned long) (utils_libraw.cpp:239)
==23395== by 0x4EA59D4: LibRaw::parse_makernote(int, int) (makernotes.cpp:527)
==23395== by 0x4E93820: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:503)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9DC41: LibRaw::identify() (identify.cpp:719)
==23395== by 0x4EC7C95: LibRaw::open_datastream(LibRaw_abstract_datastream*) (open.cpp:376)
==23395== by 0x4EC94F0: LibRaw::open_file(char const*, long long) (open.cpp:52)
==23395==
==23395== 4,096 bytes in 1 blocks are still reachable in loss record 7 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x4EC670C: libraw_memmgr (libraw_alloc.h:36)
==23395== by 0x4EC670C: LibRaw::LibRaw(unsigned int) (init_close_utils.cpp:26)
==23395== by 0x400D75: main (simple_dcraw.cpp:64)
==23395==
==23395== 8,192 bytes in 1 blocks are still reachable in loss record 8 of 9
==23395== at 0x4C2AB5B: operator new[](unsigned long) (vg_replace_malloc.c:433)
==23395== by 0x58BE1CB: std::basic_filebuf >::_M_allocate_internal_buffer() (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58BE811: std::basic_filebuf >::open(char const*, std::_Ios_Openmode) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x4E56B06: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:74)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 283,232 bytes in 1 blocks are definitely lost in loss record 9 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x4EC6BFF: LibRaw::LibRaw(unsigned int) (init_close_utils.cpp:104)
==23395== by 0x400D75: main (simple_dcraw.cpp:64)
==23395==
==23395== LEAK SUMMARY:
==23395== definitely lost: 283,232 bytes in 1 blocks
==23395== indirectly lost: 0 bytes in 0 blocks
==23395== possibly lost: 0 bytes in 0 blocks
==23395== still reachable: 15,741 bytes in 8 blocks
==23395== of which reachable via heuristic:
==23395== stdstring : 37 bytes in 1 blocks
==23395== suppressed: 0 bytes in 0 blocks
==23395==
==23395== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
[siddaharth.suman@sid samples]$
I am using CentOS and I have built it using the following steps:
-Removed all the libraw files from /usr/local/lib
-Removed all the libraw header files /usr/local/include
-git cloned libraw from github
-cd into LibRaw folder
-autoreconf --install
-./configure
-make
-sudo make install
I have built the sample/simple_dcraw.cpp using the command:
g++ -I/usr/local/include -L/usr/local/lib -lraw -o simple_dcraw simple_dcraw.cpp
Then I just run the command:
./simple_dcraw -v example.CR3 (Where example.CR3 is a raw file)
After which I get:
Processing file example.CR3
Segmentation fault
This is the first time I have built the LibRaw library and I directly built it from the 201910 snapshot. I don't think I have a outdated libraw.so issue.
Ok, I found the problem. It didn't really involve lcms.
I had removed pkgconfig from /usr/local/lib. However pkgconfig is required for static libraries (specifically libraw_r.a which I was trying to use). I restored pkgconfig and compiled and ran my code.
Thanks for your help.
I tried to play with the settings in Rawprocessor->imgdata.params, but couldn't figure it out.
My code looks now something like this (not production code):
int LoadRaw(char *charBuffer, int size)
{
RawProcessor->open_file(charBuffer);
// Result if enabled : http://neuland.wtf/img/camera_wb.jpeg
RawProcessor->imgdata.params.use_camera_wb = 0;
// Result if enabled: http://neuland.wtf/img/auto_wb.jpeg
RawProcessor->imgdata.params.use_auto_wb = 1;
RawProcessor->unpack();
RawProcessor->dcraw_process();
}
Followup:
in your code sample you make a copy of RawProcessor.imgdata by this line:
libraw_data_t imgD = RawProcessor.imgdata;
Than change your copy, not RawProcessor.imgdata.params
Is this a typo in code sample (you really use reference in your real code)?
Both DNG and NEF are TIFF/EP containers, so the spec you're after is the TIFF/EP spec. On top of that there is custom tags in both formats: the DNG ones are described in its spec (surprised you couldn't find it), the NEF ones you can glimpse maybe from e.g. ExifTool, but I don't think it's published by Nikon. I think you pretty much have to come up with your own writer, or use some TIFF library and extend it.
I thought that at least there should be some specs about the DNG file format. The SDK is great!
This might help me a bit.
But the thing I really need is NEF editing. If anyone has any hints please tell :-)
I found rawpy which uses libraw and reads NEF files. Loads the undemosaiced raw data.
Only thing missing now is a way to overwrite the file.
Looks like issue is earlier in the process.
One of the load_stream/unpack/dcraw_process is silently failing to allocate some memory, so when it comes to the dcraw_make_mem_image it is being told that width/height/etc are all 0, hence no error, but no return data.
If I can determine where it is failing I'll pass it on, otherwise - feel free to ignore me for now :)
Follow-up:
After looking at how the code fails in my app, it appears that:
this method is returning an object, but the `data_size` property is 0 (zero).
I guess it is possible that the call to dcraw_process also failed.
I'm going to go back to the debugger and ensure valid data is being presented - I will update when I have confirmed one way or the other.
If, on top of this, you also need accurate color reproduction, an alternative approach would be to construct a DNG from your raw bytestream, e.g. in 2 steps:
1) see e.g. rawtopgm from netpbm tools, or use ImageMagick/GraphicsMagick raw 'GRAY' format to convert to a widely known and simple PGM
2) use http://a1ex.magiclantern.fm/bleeding-edge/pgm2dng.c (adjust metadata accordingly in the source or using e.g. exiftool afterwards); see also https://github.com/fastvideo/pgm2dng
However, you'd need some (not so trivial) sensor characterization work to be able to fill the DNG metadata (basically build your own DCP). LibRaw would need this information anyway even if you went with the open_bayer() route and want more accurate color reproduction. The upside of the DNG route is that you can use many more processors/libraries in the future.
I have generated the backtrace from valgrind. Here you go:
==23395== Process terminating with default action of signal 11 (SIGSEGV)
==23395== Bad permissions for mapped region at address 0x5185000
==23395== at 0x4EC4DBB: LibRaw::adobe_coeff(unsigned int, char const*, int) (colordata.cpp:1697)
==23395== by 0x4EAC172: LibRaw::GetNormalizedModel() (normalize_model.cpp:1157)
==23395== by 0x4E9C07D: LibRaw::identify() (identify.cpp:1071)
==23395== by 0x4EC7C95: LibRaw::open_datastream(LibRaw_abstract_datastream*) (open.cpp:376)
==23395== by 0x4EC94F0: LibRaw::open_file(char const*, long long) (open.cpp:52)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== HEAP SUMMARY:
==23395== in use at exit: 298,973 bytes in 9 blocks
==23395== total heap usage: 27 allocs, 18 frees, 343,743 bytes allocated
==23395==
==23395== Searching for pointers to 9 not-freed blocks
==23395== Checked 1,382,688 bytes
==23395==
==23395== 8 bytes in 1 blocks are still reachable in loss record 1 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x5E1A868: ??? (in /usr/lib64/libgomp.so.1.0.0)
==23395== by 0x5E2968B: ??? (in /usr/lib64/libgomp.so.1.0.0)
==23395== by 0x5E18EC6: ??? (in /usr/lib64/libgomp.so.1.0.0)
==23395== by 0x400F4C2: _dl_init (in /usr/lib64/ld-2.17.so)
==23395== by 0x40011A9: ??? (in /usr/lib64/ld-2.17.so)
==23395== by 0x2: ???
==23395== by 0x1FFF0003D2: ???
==23395== by 0x1FFF0003DF: ???
==23395== by 0x1FFF0003E2: ???
==23395==
==23395== 37 bytes in 1 blocks are still reachable in loss record 2 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x58C4CF8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58C6580: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58C69B7: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x4E56AA5: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:56)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 40 bytes in 1 blocks are still reachable in loss record 3 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x4EC947F: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 240 bytes in 1 blocks are still reachable in loss record 4 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x4E56AEA: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:70)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 568 bytes in 1 blocks are still reachable in loss record 5 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x64D458C: __fopen_internal (in /usr/lib64/libc-2.17.so)
==23395== by 0x58834FF: std::__basic_file::open(char const*, std::_Ios_Openmode, int) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58BE7F9: std::basic_filebuf >::open(char const*, std::_Ios_Openmode) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x4E56B06: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:74)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 2,560 bytes in 1 blocks are still reachable in loss record 6 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x4ECC062: malloc (libraw_alloc.h:49)
==23395== by 0x4ECC062: LibRaw::malloc(unsigned long) (utils_libraw.cpp:239)
==23395== by 0x4EA59D4: LibRaw::parse_makernote(int, int) (makernotes.cpp:527)
==23395== by 0x4E93820: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:503)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9331D: LibRaw::parseCR3(unsigned long long, unsigned long long, short&, char*, short&, short&) (cr3_parser.cpp:519)
==23395== by 0x4E9DC41: LibRaw::identify() (identify.cpp:719)
==23395== by 0x4EC7C95: LibRaw::open_datastream(LibRaw_abstract_datastream*) (open.cpp:376)
==23395== by 0x4EC94F0: LibRaw::open_file(char const*, long long) (open.cpp:52)
==23395==
==23395== 4,096 bytes in 1 blocks are still reachable in loss record 7 of 9
==23395== at 0x4C29E96: malloc (vg_replace_malloc.c:309)
==23395== by 0x4EC670C: libraw_memmgr (libraw_alloc.h:36)
==23395== by 0x4EC670C: LibRaw::LibRaw(unsigned int) (init_close_utils.cpp:26)
==23395== by 0x400D75: main (simple_dcraw.cpp:64)
==23395==
==23395== 8,192 bytes in 1 blocks are still reachable in loss record 8 of 9
==23395== at 0x4C2AB5B: operator new[](unsigned long) (vg_replace_malloc.c:433)
==23395== by 0x58BE1CB: std::basic_filebuf >::_M_allocate_internal_buffer() (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x58BE811: std::basic_filebuf >::open(char const*, std::_Ios_Openmode) (in /usr/lib64/libstdc++.so.6.0.19)
==23395== by 0x4E56B06: LibRaw_file_datastream::LibRaw_file_datastream(char const*) (libraw_datastream.cpp:74)
==23395== by 0x4EC948D: LibRaw::open_file(char const*, long long) (open.cpp:38)
==23395== by 0x400DDC: main (simple_dcraw.cpp:122)
==23395==
==23395== 283,232 bytes in 1 blocks are definitely lost in loss record 9 of 9
==23395== at 0x4C2A4B6: operator new(unsigned long) (vg_replace_malloc.c:344)
==23395== by 0x4EC6BFF: LibRaw::LibRaw(unsigned int) (init_close_utils.cpp:104)
==23395== by 0x400D75: main (simple_dcraw.cpp:64)
==23395==
==23395== LEAK SUMMARY:
==23395== definitely lost: 283,232 bytes in 1 blocks
==23395== indirectly lost: 0 bytes in 0 blocks
==23395== possibly lost: 0 bytes in 0 blocks
==23395== still reachable: 15,741 bytes in 8 blocks
==23395== of which reachable via heuristic:
==23395== stdstring : 37 bytes in 1 blocks
==23395== suppressed: 0 bytes in 0 blocks
==23395==
==23395== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
[siddaharth.suman@sid samples]$
OK.
could you please also show backtrace from segfault?
I executed the ldd command and got the following:
$ ldd simple_dcraw
linux-vdso.so.1 => (0x00007ffcabadf000)
libraw.so.19 => /usr/local/lib/libraw.so.19 (0x00007fd0f3b6d000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fd0f385a000)
libm.so.6 => /lib64/libm.so.6 (0x00007fd0f3558000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd0f3342000)
libc.so.6 => /lib64/libc.so.6 (0x00007fd0f2f7e000)
libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007fd0f2d29000)
libz.so.1 => /lib64/libz.so.1 (0x00007fd0f2b13000)
liblcms2.so.2 => /lib64/liblcms2.so.2 (0x00007fd0f28b8000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fd0f2692000)
/lib64/ld-linux-x86-64.so.2 (0x000055a89c51c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd0f2475000)
I also checked my /usr/local/lib for all the libraw files:
$ ll | grep libraw
-rw-r--r-- 1 root root 7138434 Feb 20 06:59 libraw.a
-rwxr-xr-x 1 root root 942 Feb 20 06:59 libraw.la
-rw-r--r-- 1 root root 7138434 Feb 20 06:59 libraw_r.a
-rwxr-xr-x 1 root root 956 Feb 20 06:59 libraw_r.la
lrwxrwxrwx 1 root root 18 Feb 20 06:59 libraw_r.so -> libraw_r.so.19.0.0
lrwxrwxrwx 1 root root 18 Feb 20 06:59 libraw_r.so.19 -> libraw_r.so.19.0.0
-rwxr-xr-x 1 root root 3595488 Feb 20 06:59 libraw_r.so.19.0.0
lrwxrwxrwx 1 root root 16 Feb 20 06:59 libraw.so -> libraw.so.19.0.0
lrwxrwxrwx 1 root root 16 Feb 20 06:59 libraw.so.19 -> libraw.so.19.0.0
-rwxr-xr-x 1 root root 3595488 Feb 20 06:59 libraw.so.19.0.0
--Siddaharth Suman
Please make sure your compiled sample uses libraw.so you've installed, not older/other one.
ldd command may help.
I am using CentOS and I have built it using the following steps:
-Removed all the libraw files from /usr/local/lib
-Removed all the libraw header files /usr/local/include
-git cloned libraw from github
-cd into LibRaw folder
-autoreconf --install
-./configure
-make
-sudo make install
I have built the sample/simple_dcraw.cpp using the command:
g++ -I/usr/local/include -L/usr/local/lib -lraw -o simple_dcraw simple_dcraw.cpp
Then I just run the command:
./simple_dcraw -v example.CR3 (Where example.CR3 is a raw file)
After which I get:
Processing file example.CR3
Segmentation fault
Anything that I could be missing on here?
-- Siddaharth Suman
I do not know what build environment you use.
If it is Linux, it may already contain (older) LibRaw
Hi Alex,
Thanks for your reply.
This is the first time I have built the LibRaw library and I directly built it from the 201910 snapshot. I don't think I have a outdated libraw.so issue.
-- Siddaharth Suman
Please make sure you do not have outdated libraw.so somewhere in dynamic linker search path
Hello,
Is it planned to port more recent version of libraw library to Android?
Thanks
Ok, I found the problem. It didn't really involve lcms.
I had removed pkgconfig from /usr/local/lib. However pkgconfig is required for static libraries (specifically libraw_r.a which I was trying to use). I restored pkgconfig and compiled and ran my code.
Thanks for your help.
If you use ./configure script to build libraw, use --disable-lcms to disable lcms auto-detection.
Alternatively you can use make -f Makefile.dist, LCMS section is disabled (commented out) by default.
There are rawpy: https://pypi.org/project/rawpy/
And several other libraries (googled by 'libraw python')
unpack_thumb() provides largest available thumbnail/preview/whatever-it-called.
Great to hear you've fixed the problem w/ white balance.
Haha oh man, thanks for the answer!
I'm stupid, I just wanted it to be done and didn't look right at my garbage.
I fixed the code and the Whitebalance probleme disapeared.
But unfortunaly I ran into another problem.
The red colors seems to be shifted, so brown colors appears bluish.
Also blue seems to become orange.
Here is the correct image as jpg Converted from Photoshop
http://neuland.wtf/img/correct.jpg
and the source Raw file:
http://neuland.wtf/img/srcraw.CR3
I tried to play with the settings in Rawprocessor->imgdata.params, but couldn't figure it out.
My code looks now something like this (not production code):
int LoadRaw(char *charBuffer, int size) { RawProcessor->open_file(charBuffer); // Result if enabled : http://neuland.wtf/img/camera_wb.jpeg RawProcessor->imgdata.params.use_camera_wb = 0; // Result if enabled: http://neuland.wtf/img/auto_wb.jpeg RawProcessor->imgdata.params.use_auto_wb = 1; RawProcessor->unpack(); RawProcessor->dcraw_process(); }Followup:
in your code sample you make a copy of RawProcessor.imgdata by this line:
libraw_data_t imgD = RawProcessor.imgdata;
Than change your copy, not RawProcessor.imgdata.params
Is this a typo in code sample (you really use reference in your real code)?
It is hard to discuss such kind of problem without having raw file sample on hands.
DNG specs are available at Adobe site: https://wwwimages2.adobe.com/content/dam/acom/en/products/photoshop/pdfs...
AFAIK, there is no public specs for NEFs
LibRaw is not able to write raw files.
Both DNG and NEF are TIFF/EP containers, so the spec you're after is the TIFF/EP spec. On top of that there is custom tags in both formats: the DNG ones are described in its spec (surprised you couldn't find it), the NEF ones you can glimpse maybe from e.g. ExifTool, but I don't think it's published by Nikon. I think you pretty much have to come up with your own writer, or use some TIFF library and extend it.
Thank you for your reply!
I thought that at least there should be some specs about the DNG file format. The SDK is great!
This might help me a bit.
But the thing I really need is NEF editing. If anyone has any hints please tell :-)
I found rawpy which uses libraw and reads NEF files. Loads the undemosaiced raw data.
Only thing missing now is a way to overwrite the file.
Looks like issue is earlier in the process.
One of the load_stream/unpack/dcraw_process is silently failing to allocate some memory, so when it comes to the dcraw_make_mem_image it is being told that width/height/etc are all 0, hence no error, but no return data.
If I can determine where it is failing I'll pass it on, otherwise - feel free to ignore me for now :)
Follow-up:
After looking at how the code fails in my app, it appears that:
this method is returning an object, but the `data_size` property is 0 (zero).
I guess it is possible that the call to dcraw_process also failed.
I'm going to go back to the debugger and ensure valid data is being presented - I will update when I have confirmed one way or the other.
LibRaw reads RAW files, but not writes into them.
To create DNG file you may use Adobe DNG SDK
If, on top of this, you also need accurate color reproduction, an alternative approach would be to construct a DNG from your raw bytestream, e.g. in 2 steps:
1) see e.g. rawtopgm from netpbm tools, or use ImageMagick/GraphicsMagick raw 'GRAY' format to convert to a widely known and simple PGM
2) use http://a1ex.magiclantern.fm/bleeding-edge/pgm2dng.c (adjust metadata accordingly in the source or using e.g. exiftool afterwards); see also https://github.com/fastvideo/pgm2dng
However, you'd need some (not so trivial) sensor characterization work to be able to fill the DNG metadata (basically build your own DCP). LibRaw would need this information anyway even if you went with the open_bayer() route and want more accurate color reproduction. The upside of the DNG route is that you can use many more processors/libraries in the future.
Pages