Crash when opening sony .ARW file

Hi I don’t see a way to file a bug report on the project’s bitbucket page so I’ll put it here:

I’m getting a crash with the following error message when attempting to open the below-linked Sony .ARW file.

terminate called after throwing an instance of ‘Glib::ConvertError’

the .ARW file: https://drive.google.com/file/d/1Dce4tdK34npGoM2Do3WvticC13XipQcK/view?usp=sharing

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 :slight_smile:

Platform is arch linux x64, ART installed via AUR (en) - art-rawconverter

not that it should matter, but this is running in a Crostini VM on chromeOS host

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…

No problem here with ART version from agriggio / ART / Downloads — Bitbucket

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.

:dog2: :dog: :smiling_face_with_three_hearts:

No problem as well with latest Art from GitHub.

https://archlinux.org/packages/?q=libraw

January 2020???

I thought Arch was supposed to be this fantastic rolling-release distro?

ldconfig shows:

[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

so it looks like I do also have latest

My point was that Arch’s latest is out of date. 20.0.2 is the latest official release.

There also have been two snapshot releases since 20.0.2, and one of those is necessary for Sony lossless ARW.

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)

Newer Sonys (ones with the BIONZ XR) support lossless compressed raw.

1 Like

Ping @guzzisti if this is an arch-specific issue

@BSLprints what version of libraw do you use?

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.

Arch is not out of date, it uses the latest official release published at Download | LibRaw.

Snapshot version will most likely not make it into the community repo, its called snapshot for a reason. :wink:

As mentioned on the libraw homepage:

  • Major releases (for example, 0.20) are published once every year and a half to two years.

just tested a normal build from the projects git (rather than through AUR) and it had the same issue.

what version of libraw do you use?

[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 :slight_smile:

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.

Well, that’s already the case.

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)