Recent comments

Reply to: CR3 support   5 years 3 weeks ago
How's the support for CR3

How's the support for CR3 coming along? Thanks!

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
OK.

OK.
We'll disable gcc version less than 4.9 for 0.20 release.

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
Thanks Alex,

Thanks Alex,

I updated my gcc to 7.3.1 and the issue was resolved!

--Siddaharth Suman

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
You're correct! My gcc

You're correct! My gcc version is at 4.8.5. Let me update and try again. I'll post the end result here.

--Siddaharth Suman

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
Looks like (known) gcc 4.8x

Looks like (known) gcc 4.8x problem with this code: https://github.com/LibRaw/LibRaw/issues/264

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
I have generated the

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]$

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
OK.

OK.
could you please also show backtrace from segfault?

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
I executed the ldd command

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

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
Please make sure your

Please make sure your compiled sample uses libraw.so you've installed, not older/other one.

ldd command may help.

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
I am using CentOS and I have

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

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
I do not know what build

I do not know what build environment you use.
If it is Linux, it may already contain (older) LibRaw

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
Hi Alex,

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

Reply to: Segmentation Fault when processing some raw images   5 years 2 months ago
Please make sure you do not

Please make sure you do not have outdated libraw.so somewhere in dynamic linker search path

Reply to: Libraw Android Port on GitHub   5 years 2 months ago
Libraw Android Port on GitHub

Hello,

Is it planned to port more recent version of libraw library to Android?

Thanks

Reply to: Don't want to use LCMS   5 years 3 months ago
Don't want to use LCMS

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.

Reply to: Don't want to use LCMS   5 years 3 months ago
If you use ./configure script

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.

Reply to: Python API   5 years 3 months ago
There are rawpy: https://pypi

There are rawpy: https://pypi.org/project/rawpy/
And several other libraries (googled by 'libraw python')

Reply to: unpack_thumb unpacks previews instead   5 years 3 months ago
unpack_thumb() provides

unpack_thumb() provides largest available thumbnail/preview/whatever-it-called.

Reply to: Cr3 Raw wrong Whitebalance   5 years 3 months ago
Great to hear you've fixed

Great to hear you've fixed the problem w/ white balance.

Reply to: Cr3 Raw wrong Whitebalance   5 years 3 months ago
almost solved

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();
}
Reply to: Cr3 Raw wrong Whitebalance   5 years 3 months ago
Followup:

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)?

Reply to: Cr3 Raw wrong Whitebalance   5 years 3 months ago
It is hard to discuss such

It is hard to discuss such kind of problem without having raw file sample on hands.

Reply to: Overwriting/Generating fake Nikon .NEF raw files   5 years 3 months ago
DNG specs are available at

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

Reply to: Overwriting/Generating fake Nikon .NEF raw files   5 years 3 months ago
LibRaw is not able to write

LibRaw is not able to write raw files.

Reply to: Overwriting/Generating fake Nikon .NEF raw files   5 years 3 months ago
Both DNG and NEF are TIFF/EP

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.

Pages

more