Recent comments

Reply to: Losing all benefits of Sigma (Foveon X3F) Merrill BW benefits   5 years 4 months ago
.

I think he refers to this thread = https://forum.affinity.serif.com/index.php?/topic/93631-outstanding-bw-o...

Reply to: Losing all benefits of Sigma (Foveon X3F) Merrill BW benefits   5 years 4 months ago
Also, you wrote:

Also, you wrote:
> This issue was escalated to the LibRaw dev team by the Affinity (Serif) devs about a year ago

Sure? Never heard of something like this

Reply to: Losing all benefits of Sigma (Foveon X3F) Merrill BW benefits   5 years 4 months ago
I can’t understand what kind

I can’t understand what kind of additional support you require from our library.

LibRaw provides access to RAW data for calling application (e.g. Affinity). Calling application is responsible for this data interpretation and processing (e.g. channel mixing if one want to treat Foveon image as BW).

Reply to: CR3 support   5 years 4 months ago
That's right.

That's right.
But package are built only on stable release :).

Cheers,

Reply to: CR3 support   5 years 4 months ago
current master is stable

current master is stable enough for production usage.

Reply to: CR3 support   5 years 4 months ago
I think I found the issue

I think I found the issue (mix of versions in my lib folder). Sorry for that.
Sorry to ask you that but do you have any idea about the date of the next stable release ?

Cheers,

Reply to: CR3 support   5 years 4 months ago
I also have a good tiff file.

I also have a good tiff file.
But for a reason a I don't understand, libraw_open_file returns an error.

Reply to: CR3 support   5 years 4 months ago
OK thanks. I've no doubt the

OK thanks. I've no doubt the issue is on my system then, thank you so much.

Stay safe,
Cyril

Reply to: CR3 support   5 years 4 months ago
I recloned the git repo.

I recloned the git repo.
I wrote:

printf("version: %s\n", LIBRAW_VERSION_STR);
return(libraw_open_file(rawdata, name));

And I have:

version: 0.20.0-WorkInProgress
Error in libraw Unsupported file format or not RAW file

I need to investigate then.

Reply to: CR3 support   5 years 4 months ago
I've tested with fresh git

I've tested with fresh git clone:

git clone https://github.com/LibRaw/LibRaw.git LibRaw.gh && cd LibRaw.gh && make -f Makefile.devel CXX=clang++ CC=clang -j4 && ./bin/dcraw_emu -T -w ~/1/canon_eos_m50_07.cr3

This results in ~/1/canon_eos_m50_07.cr3.tiff as expected

(note CXX=.. CC=.. is for my system with clang installed as c++ compiler).

Reply to: CR3 support   5 years 4 months ago
Thank you for the sample. I

Thank you for the sample. I do not see any problems with this file.

Please make sure you're using up-to-date master branch from Github,

Reply to: CR3 support   5 years 4 months ago
Attached one file, but I have

Attached one file, but I have same issue with other CR3,
Maybe I'm doing something wrong, but my code is working for all other formats. So I don't know.

https://www.dropbox.com/s/38yf9tcqtvnihll/canon_eos_m50_07.cr3?dl=0

Reply to: CR3 support   5 years 4 months ago
Could you please share sample

Could you please share sample file with us

Reply to: CR3 support   5 years 4 months ago
CR3 issue

Hello, with the master version I have the following error with m50 cr3:
Unsupported file format or not RAW file

Cheers,

Reply to: CR3 support   5 years 4 months ago
CR3 support is published in

CR3 support is published in Oct 2019.

Reply to: CR3 support   5 years 4 months 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 6 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 6 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 6 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 6 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 6 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 6 months ago
OK.

OK.
could you please also show backtrace from segfault?

Reply to: Segmentation Fault when processing some raw images   5 years 6 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 6 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 6 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

Pages

more