Loading other image formats seems to work fine, and the .ARW file loads fine.in rawtherapee (dev branch) on the same machine. If this isn’t a known bug I can recompile in debug and get a backtrace just let me know
I can’t access Drive from my current location, but:
Specifying which Sony camera generated this ARW file and what compression settings you used would likely help. For example, while ART should be able to handle lossless compressed RAW of newer Sonys since it uses libraw, it isn’t nearly as well tested since it’s a fairly new format and not many people own cameras that support it yet, and I can tell you that lossless compressed ARW is not supported at all in RT right now.
Edit: ODD that you found something RT handles but ART does not… So it definitely isn’t lossless compressed…
Maybe try this one? Just extract and run, no need to install anything. I believe the developer doesn’t have much influence on the builds provided by the distros. If they make any mistake while building, he can’t fix it.
[katrina@penguin art-rawconverter-git]$ ldconfig -v | grep libraw
ldconfig: Path `/usr/lib64' given more than once
(from <builtin>:0 and <builtin>:0)
ldconfig: Can't stat /usr/libx32: No such file or directory
libraw1394.so.11 -> libraw1394.so.11.1.0
libraw1394.so.11 -> libraw1394.so.11.1.0
libraw_r.so.20 -> libraw_r.so.20.0.0
libraw.so.20 -> libraw.so.20.0.0
running the prebuilt binary on arch requires building libselinux from a user repository, building that requires all sorts of other dependencies on arch so not a good route on this distro.
I’ll try doing a build of the latest git just to be sure, but I think the arch AUR package already does this
I doubt this is a sony lossless, this was just a random ARW i download from the internet for testing. I presume by lossless you mean different than uncompressed raw, correct? (I use that all the time in RT with my a7r4)
ART makes use of libraw only if it is version >= 0.21 which means at the moment you need to use the libraw-git package until an official release is published.
The shared image works fine for me on Arch with art-rawconverter-git and libraw-git built today.
It might be an issue with the vendored dcraw.c (which is replaced by libraw if the version requirement is meet) or its a bug in the latest release that is already fixed on current main.
[katrina@penguin art-master-release]$ ldconfig -v | grep libraw
ldconfig: Path `/usr/lib64' given more than once
(from <builtin>:0 and <builtin>:0)
ldconfig: Can't stat /usr/libx32: No such file or directory
libraw1394.so.11 -> libraw1394.so.11.1.0
libraw1394.so.11 -> libraw1394.so.11.1.0
libraw_r.so.20 -> libraw_r.so.20.0.0
libraw.so.20 -> libraw.so.20.0.0
so dows art need libraw >= 0.21 even though RT does not for the same file? I’m comparing latest commit of art vs latest commit of RT
ART does need libraw >= 0.21 cause @agriggio decided to only support this versions. IRC it is due to a breaking change in the libraw API between 0.20 and the upcoming 0.21 which would have required additional refactoring.
I don’t know if RT uses libraw at all. Maybe RT works with libraw cause it uses 0.20 while ART falls back to the vendored dcraw.c which doesn’t properly support this kind of ARWs - but this is pure speculation on my side.
RT doesn’t use libraw afaik. Anyway, I’d say that if this works with libraw enabled in ART, then we can consider this closed, as I see no point in fixing the legacy code – it’s legacy for a reason after all
interesting! Well I have a debug build compiling now so I can at least get a backtrace so hopefully that will help.
@agriggio if @guzzisti is correct, then before closing the bug, CMakeLists should probably be updated to check for libraw >=0.21 as should the AUR makepkg script. Linking against an old version of a library I personally would consider a build system bug.
Anyway, I’m not sure this is libraw-related, the error message you posted makes me think this might be due to some unicode decoding failure, so it might have to do with metadata. If you can post a backtrace, it would be useful.
if CMakeList is already requiring libraw >=0.21 how was I able to compile it with 0.20?
this backtrace is rather uninformative:
[Detaching after fork from child process 13379]
terminate called after throwing an instance of 'Glib::ConvertError'
Thread 1 "ART" received signal SIGABRT, Aborted.
0x00007ffff51b934c in ?? ()
(gdb) bt
#0 0x00007ffff51b934c in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffcdf0
(gdb)
