ART-cli aborts with uncaught Exiv2::Error ("Failed to read input data") ~85% through export

[brownphotographic]

ART-cli crashes (std::terminate, SIGABRT) partway through exporting certain Leica M10-R DNG files. The RAW demosaic itself completes successfully (progress reaches 85%), then the process aborts with an uncaught C++ exception from Exiv2 while apparently re-reading/embedding metadata into the output. The same DNG opened interactively in the ART GUI also fails to save its own metadata sidecar, with an identical underlying error.

The affected files are not corrupted — a current system Exiv2 (0.28.6, separate from ART's bundled copy) reads them, their full tag set, and all three embedded preview images cleanly. A DNG from the same shoot with an otherwise-identical structure exports without issue, so this looks like a metadata-handling bug/incompatibility in the Exiv2 version bundled with this ART build, not simple file corruption.

Environment

• ART version: 1.26.7 (AppImage build)
• OS: Fedora Linux, 7.1.3-201.fc44.x86_64
• Camera / file format: Leica M10-R, compressed-RAW DNG (PhotometricInterpretation = CFA / 32803), 7872×5208, ~48–50 MB per file
• Files live on an NFS mount; ruled out as a factor (see "What I ruled out" below)

Steps to reproduce

1. Take a DNG from a Leica M10-R with the in-camera "Digital Shift Assistant" (perspective/leveling) correction data embedded (visible as an Xmp.xmpDSA.* block in the file's embedded XMP packet — see below).
2. Run ART-cli on it directly, e.g.:

ART-cli -o /tmp/out.jpg -j92 -Y -V --progress -d -S -c /path/to/photo.DNG
3. Observe progress climb normally to 85%, then:

terminate called after throwing an instance of 'Exiv2::Error'
what(): Failed to read input data

3. The process aborts (SIGABRT) and dumps core; no output file is produced.

This reproduces 100% of the time on the affected files, with a fresh output path, and identically whether or not an external .xmp sidecar is present next to the DNG (tested both ways — removing the sidecar entirely made no difference).

The interactive ART GUI shows the same underlying failure when closing the editor on one of these files (it's attempting to write its own edit sidecar):

ERROR saving metadata for /path/to/photo.DNG to /path/to/photo.DNG.xmp: Failed to read input data

Expected behavior

Either:

• ART-cli/ART successfully reads whatever metadata it's trying to read and completes the export/sidecar-save, or
• if the file genuinely has something ART's Exiv2 can't handle, it should fail gracefully with a catchable error (not an uncaught C++ exception that aborts the whole process).

Actual behavior

Uncaught Exiv2::Error exception reaches std::terminate, aborting the process with SIGABRT after RAW processing has already completed (progress was at 85%).

What I ruled out

• Not file corruption: file reports a normal, well-formed DNG/TIFF header on the affected files. A separately-installed system exiv2 (0.28.6, not the version bundled in this ART build) successfully reads the full EXIF/XMP tag set (136 tags, identical tag names to a working file from the same shoot — only values differ, as expected), all three embedded preview images (exiv2 -pp/-ep), and the embedded Exif.Image.XMLPacket (the raw embedded XMP), which I decoded and diffed byte-for-byte against a working file's XMP — both are well-formed, complete ( present, not truncated), and structurally identical, including the xmlns:xmpDSA="http://leica-camera.com/digital-shift-assistant/1.0/" block and its NormalizedCropCorners/PitchAngle/RollAngle fields — only the actual numeric/timestamp values differ between files, as expected.
• Not an external sidecar: removed the pre-existing .xmp sidecar next to the DNG entirely and re-ran ART-cli -d -S — crash was identical.
• Not a fresh/colliding output path: reproduced with a brand-new, never-before-used output filename.
• Not NFS flakiness: reproduced 3/3 consecutive runs against the same file with no other load on the system; the crash happens at a consistent point (~85%) each time, not a hang or intermittent failure.

Given all of the above, this looks like a genuine bug in the Exiv2 version bundled with this ART build's handling of some specific metadata construct in this camera's DNG output — possibly related to the Leica-specific xmpDSA namespace, or something in how/when ART-cli re-opens the source file late in the pipeline to copy metadata into the export. I wasn't able to narrow it down further without access to ART's own Exiv2 build/source to bisect against.

Sample files

I can provide one or both of the affected DNGs (and a same-shoot DNG that exports successfully, for comparison) if that would help — they're large (~48–50 MB each) so let me know the best way to share them.

Additional (likely unrelated) observation

Separately, launching the ART AppImage GUI logs:

g_module_open() failed for /tmp/tmp.XXXXXXXXXX-ART/ART/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so: cannot open shared object file: No such file or directory

on every launch (the AppImage self-extracts to a fresh /tmp/tmp.-ART/ directory each time, presumably because FUSE mounting isn't available in this environment). I don't believe this is related to the Exiv2 crash above — it's a GTK pixbuf loader used for GUI thumbnails, an entirely separate code path from Exiv2's metadata handling — but flagging it in case it's a symptom of an incomplete AppImage bundle.

[agriggio]

Thanks for the detailed description! If you could share the files (via google drive or similar) I will take a look

[brownphotographic]

Thanks for your attention. Here are a couple of files that seem to fail with the CLI. Could you try exporting them with the CLI please?

I am creating an app that uses ART CLI. It could be user error. Most images seem to export fine, but a few throw the error.

https://www.dropbox.com/scl/fo/iuqatoppzr1yrj2zltplz/ADglrn4Cr0n36LcIV7U66l4?rlkey=lfg1vmaof9azplwyw193rmsls&st=hf1oiobj&dl=0

[agriggio]

Hi, do you also have the offending .arp sidecar files? I'm failing to reproduce the problem and I wonder whether it could be something there. Thanks!

[brownphotographic]

Hi, I am in the middle of debugging to see if this is on my end with the way I am invoking the CLI. There seems to be indeed a problem with the metadata files (arp, xmp). I will report back after I have done more digging.

[brownphotographic]

OK, I did some further debugging. Using the CLI outside of the app I am building I am able to reproduce this error. I used claude code to help the diagnosis

A markdown file with more detail on the deep dive analysis along with two other files (good and bad one) are in this link below.

I guess the easiest thing to do is see if your CLI passes or fails on both these files.

Thanks for your attention!

https://www.dropbox.com/scl/fo/h2wzak6o1lsvprirtekij/AO4tNVPyp-96CI06iWI1Ajg?rlkey=jex7fvkakqxuvx4s9ilqm52fn&st=08nk12un&dl=0

[brownphotographic]

Re-ran with some retry logic, but it didn't work. Updated the bug report in the dropbox folder and pasted below

One note - maybe not the reason: I downloaded the appimage (1.26.7), then extracted the CLI from that using squashfs-root

ART-cli aborts with uncaught Exiv2::Error ("Failed to read input data") when copying EXIF from a Leica M10-R DNG into its output

Summary

ART-cli crashes (SIGABRT, uncaught C++ exception) very reliably while processing a
specific Leica M10-R DNG, with:

terminate called after throwing an instance of 'Exiv2::Error'
  what():  Failed to read input data

The strongest lead: any invocation whose processing profile has [MetaData] Mode=1
(ART's "copy these EXIF tags from the original RAW into the output" setting) crashes this
file 11 times out of 12 attempts across a saved sidecar, a hand-trimmed sidecar, and an
unrelated bundled profile — all with Mode=1. Forcing Mode=0 on an otherwise-identical
profile produced 4 clean exports out of 4 attempts. See Diagnostics below.

There is also a second, less-understood crash variant: with -d (default profile, no
sidecar at all) the crash instead happened immediately on opening the file, before any
--progress output — in 2 of 4 trials. It isn't yet confirmed whether this shares the
Mode=1 codepath (ART's default profile may itself have metadata copy enabled) or is a
separate issue elsewhere in ART-cli's Exiv2 usage — flagging it rather than papering over
it, since the two crash sites produce identical error text but fire at very different
points in the run.

Environment

• ART version: 1.26.7 (official Linux AppImage build)
• OS: Fedora Linux, kernel 7.1.3-201.fc44.x86_64
• Source files are on an NFS mount, but confirmed not a factor (see Diagnostics)
• Bundled libexiv2.so.28 inside the AppImage reports version 0.28.8
• System-installed exiv2 (separate, not used by ART) is version 0.28.6, for comparison

Files

Two DNGs from the same Leica M10-R, same session, similar size — one reliably triggers
the crash, the other does not:

• Crashes: 20260712_15-29-24.DNG (~52 MB, 7872×5208)
• Does not crash: 20260712_14-35-23.DNG (~47 MB, 7872×5208)

Both: Make=Leica Camera AG, Model=LEICA M10-R, Firmware/Software=30.25.50.34.

(Files available on request — not attached here.)

Steps to reproduce

# With a saved .arp sidecar next to the DNG (produced by editing+saving in the ART GUI,
# [MetaData] Mode=1 in the saved profile) - crashed 4/4 attempts:
ART-cli -o out.jpg -j92 -Y -V --progress -s -c 20260712_15-29-24.DNG


# With no sidecar at all, using only the default profile - crashed 2/4 attempts, but at a
# different point (immediately on open, not during metadata copy - see Summary):
ART-cli -o out.jpg -j92 -Y -V --progress -d -c 20260712_15-29-24.DNG


# Applying an arbitrary bundled profile via -p (also Mode=1) - crashed 1/2 attempts:
ART-cli -o out.jpg -j92 -Y -V --progress -p "Portra 400.arp" -c 20260712_15-29-24.DNG


# The same saved sidecar, hand-edited so only "[MetaData] Mode=1" is changed to
# "Mode=0" (everything else byte-identical) - 0/4 crashes:
ART-cli -o out.jpg -j92 -Y -p sidecar-with-mode0.arp -c 20260712_15-29-24.DNG

Running the exact same command repeatedly against 20260712_15-29-24.DNG gives a mix of
clean exits and crashes for every Mode=1 variant tried (11 crashes across 12 attempts
total, pooling the -s, hand-trimmed-sidecar, and -p "Portra 400.arp" runs) - so not
strictly deterministic, but close to it in practice. The Mode=0 variant has not crashed
in 4/4 attempts. 20260712_14-35-23.DNG has not been observed to crash across a smaller
set of trials (2 attempts, both -d), so it's a plausible "doesn't reproduce as often on
this file" comparison point rather than a confirmed-clean file.

Example crash output

ART, version 1.26.7, command line.
  Processing: .../20260712_15-29-24.DNG
  Merging default raw processing profile.
terminate called after throwing an instance of 'Exiv2::Error'
  what():  Failed to read input data
[1]    <pid> Aborted (core dumped)  ART-cli ...

A separate run of the same command crashed later in processing instead:

...
80


85
terminate called after throwing an instance of 'Exiv2::Error'
  what():  Failed to read input data
[1]    <pid> Aborted (core dumped)  ART-cli ...

Diagnostics already ruled out

1. Not the .arp sidecar's content. Reproduces with the real saved sidecar, with a
   hand-trimmed minimal sidecar (single [MetaData] section, 2 EXIF keys instead of the
   full list), and with a completely unrelated bundled profile (-p "Portra 400.arp").
   Also reproduces with no sidecar at all (-d, default profile only).

2. Not file corruption. The system's independently-installed exiv2 binary
   (v0.28.6) reads this file's full metadata cleanly, 10/10 runs:
   exiv2 -pa 20260712_15-29-24.DNG → exit 0 every time.

3. Not disk/network I/O. The file is fully page-cache-resident (bulk read completes
   in single-digit milliseconds at the time of testing), and the crash still occurs
   intermittently against the cached file. NFS server ping latency to the storage host is
   sub-millisecond and stable throughout testing.

4. Not a bug in the bundled Exiv2 build itself. Loaded ART's own bundled
   libexiv2.so.28 (0.28.8) into the system exiv2 CLI via LD_LIBRARY_PATH and pointed
   it at the same file: 5/5 clean reads, no crash. So the library, driven single-threaded
   by a different caller, handles this file's metadata without issue — the crash only
   shows up when ART-cli itself processes the file.

5. Strongly correlated with [MetaData] Mode=1. Taking the real saved sidecar and
   changing nothing except Mode=1 → Mode=0 (same profile otherwise) turned a file that
   had just crashed 4/4 times in a row into 4/4 clean exports. Mode=1 is ART's own
   "re-read the RAW's EXIF via Exiv2 and copy specific tags into the output" step, which
   (per the --progress output) runs late in the pipeline, around 85% — matching where the
   -s/-p crashes were observed to abort.

Given (4) plus (5), this looks like a bug specifically in ART-cli's [MetaData] Mode=1
metadata-copy-to-output step's use of Exiv2 — not file corruption, not Exiv2 itself, and
not (based on the evidence gathered here) simple disk/network I/O. The residual
non-determinism (11/12 rather than 12/12 crashes on the Mode=1 side) and the separate
early-crash variant seen under plain -d (immediately on open, 2/4 trials, not obviously
tied to Mode=1 at all) suggest either a race condition in how/when that step touches the
Exiv2::Image object relative to other pipeline work, or more than one distinct bug
sharing the same generic Exiv2 exception text - both are plausible from what's been
isolated so far and worth keeping separate during investigation rather than assuming a
single root cause.

Impact

Any headless/scripted use of ART-cli with metadata copy-back enabled ([MetaData] Mode=1, which is ART's default when copying to a sidecar-driven export) against affected
files is unreliable to the point of being effectively broken — the same invocation
crashes (uncaught C++ exception, SIGABRT) on the large majority of runs, with no graceful
error path for a calling application to work around beyond disabling that feature entirely.

Suggested next steps for maintainers

• Start with the [MetaData] Mode=1 copy-to-output code path specifically (the step that
  re-reads the original RAW's EXIF via Exiv2 late in processing, ~85% through) - this is
  the most reliably reproducible trigger found so far (11/12 crashes with it enabled, 0/4
  with it disabled on an otherwise-identical profile).
• Separately check whether the default raw processing profile used by plain -d also has
  Mode=1 set - if so, the early-open-time crash seen under -d may be the same bug
  firing at a different call site; if not, treat it as a second, distinct issue rather than
  assuming one fix covers both.
• Audit where that code path reads/writes the Exiv2::Image metadata relative to other
  threads that may hold or use the same image object concurrently (demosaic/output-encode
  workers, -V/--progress reporting, etc.) for a missing lock or a use-after-free/dangling
  reference - a debug build under ThreadSanitizer/Valgrind reproducing this file's crash
  would likely surface it quickly given how reliably it reproduces and how cleanly it's
  isolated from Exiv2 itself.

[brownphotographic]

I implemented a workaround to use mode=0 and exiftool to allow metadata to write. So for me this is a lower priority bug, but maybe something that eventually needs attention.

Thank you!

[agriggio]

Hi, thanks for the info but I'd prefer to reproduce on my side and draw my own conclusions on this if possible. For that, having an .arp sidecar that triggers the crash would be really helpful. You can attach it directly here, just change the extension to .txt and it should work.
Thanks again!

[brownphotographic]

Thanks Albert, I made two folders with the DNG and their sidecars included:

• files that pass CLI (x2)
• files that fail CLI (x2)

https://www.dropbox.com/scl/fo/iuqatoppzr1yrj2zltplz/ADglrn4Cr0n36LcIV7U66l4?rlkey=lfg1vmaof9azplwyw193rmsls&st=wgroblqq&dl=0

Hopefully this is just a problem on my side. Thanks for the attention!

[agriggio]

Thanks! The folders seem to be empty though...

[brownphotographic]

#response_container_BBPPID{font-family: initial; font-size:initial; color: initial;} Oh sorry! I will correct that tonight. Sync problem from my Linux machine to dropbox From: ***@***.***: 20 July 2026 9:55 amTo: ***@***.*** to: ***@***.***: ***@***.***; ***@***.***: Re: [artraweditor/ART] ART-cli aborts with uncaught Exiv2::Error ("Failed to read input data") ~85% through export (Issue #511) agriggio left a comment (artraweditor/ART#511) Thanks! The folders seem to be empty though... —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[brownphotographic]

I synced the files I also tried running the CLI via my terminal on those same files on my local disk (when I found the problem, originally I was running on a server via an NFS connection), results below, *and could not reproduce the problem. * I then tried running the code I have (which invokes the CLI) pointed at the same files on my local drive, and also on the NFS share. I could not reproduce the problem. So my only guess here is that it is some kind of race condition happening. I suggest that given the above evidence, and the fact this may be a rare edge case that we close this ticket (won't solve). I have a workaround in place which works, which involves invoking exiftool to get around this problem. Thanks for your attention Alberto, but I won't waste your time on this any further.

…

---------- ***@***.***:~/Downloads/bugtest/fail$ # Saved sidecar (Mode=1) — uses 20260609_08-07-10.DNG.arp automatically /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-07-10.jpg -j80 -Y -V --progress -s -c 20260609_08-07-10.DNG # Default profile (Mode=1, assuming default has copy-metadata enabled) /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-07-10.jpg -j80 -Y -V --progress -d -c 20260609_08-07-10.DNG # Control: Mode=0 # First make a copy of the real sidecar and hand-edit "[MetaData] Mode=1" to "Mode=0": cp 20260609_08-07-10.DNG.arp 20260609_08-07-10_mode0.arp # (edit 20260609_08-07-10_mode0.arp now) /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-07-10_mode0.jpg -j80 -Y -p 20260609_08-07-10_mode0.arp -c 20260609_08-07-10.DNG ART, version 1.26.7, command line. #Processing: 20260609_08-07-10.DNG (1/1) Merging sidecar procparams. 50 60 65 70 72 75 77 80 85 87 100 ART, version 1.26.7, command line. #Processing: 20260609_08-07-10.DNG (1/1) Merging default raw processing profile. 50 60 65 70 72 75 77 80 85 87 100 ART, version 1.26.7, command line. Processing: 20260609_08-07-10.DNG Merging procparams #0 ***@***.***:~/Downloads/bugtest/fail$ /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-13-23.jpg -j80 -Y -V --progress -s -c 20260609_08-13-23.DNG /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-13-23.jpg -j80 -Y -V --progress -d -c 20260609_08-13-23.DNG cp 20260609_08-13-23.DNG.arp 20260609_08-13-23_mode0.arp # (edit 20260609_08-13-23_mode0.arp now) /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-13-23_mode0.jpg -j80 -Y -p 20260609_08-13-23_mode0.arp -c 20260609_08-13-23.DNG ART, version 1.26.7, command line. #Processing: 20260609_08-13-23.DNG (1/1) Merging sidecar procparams. 50 60 65 70 72 75 77 80 85 87 100 ART, version 1.26.7, command line. #Processing: 20260609_08-13-23.DNG (1/1) Merging default raw processing profile. 50 60 65 70 72 75 77 80 85 87 100 ART, version 1.26.7, command line. Processing: 20260609_08-13-23.DNG Merging procparams #0 ***@***.***:~/Downloads/bugtest/fail$ cd /home/rbrown/Downloads/bugtest/work ***@***.***:~/Downloads/bugtest/work$ /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260103_14-58-50.jpg -j80 -Y -V --progress -s -c 20260103_14-58-50.DNG /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260103_14-58-50.jpg -j80 -Y -V --progress -d -c 20260103_14-58-50.DNG ART, version 1.26.7, command line. #Processing: 20260103_14-58-50.DNG (1/1) Merging sidecar procparams. 50 60 65 70 72 75 77 80 85 87 100 ART, version 1.26.7, command line. #Processing: 20260103_14-58-50.DNG (1/1) Merging default raw processing profile. 50 60 65 70 72 75 77 80 85 87 100 ***@***.***:~/Downloads/bugtest/work$ /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-05-23.jpg -j80 -Y -V --progress -s -c 20260609_08-05-23.DNG /home/rbrown/AppImages/squashfs-root/ART-cli -o 20260609_08-05-23.jpg -j80 -Y -V --progress -d -c 20260609_08-05-23.DNG ART, version 1.26.7, command line. #Processing: 20260609_08-05-23.DNG (1/1) Merging sidecar procparams. 50 60 65 70 72 75 77 80 85 87 100 ART, version 1.26.7, command line. #Processing: 20260609_08-05-23.DNG (1/1) Merging default raw processing profile. 50 60 65 70 72 75 77 80 85 87 100 ***@***.***:~/Downloads/bugtest/work$

On Mon, Jul 20, 2026 at 4:12 PM Rob Brown ***@***.***> wrote: Oh sorry! I will correct that tonight. Sync problem from my Linux machine to dropbox *From:* ***@***.*** *Sent:* 20 July 2026 9:55 am *To:* ***@***.*** *Reply to:* ***@***.*** *Cc:* ***@***.***; ***@***.*** *Subject:* Re: [artraweditor/ART] ART-cli aborts with uncaught Exiv2::Error ("Failed to read input data") ~85% through export (Issue #511) *agriggio* left a comment (artraweditor/ART#511) <#511 (comment)> Thanks! The folders seem to be empty though... — Reply to this email directly, view it on GitHub <#511?email_source=notifications&email_token=AFRYDP3IWSTW2FMXN2DRHPL5FYQF3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGMYDINBWHE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5023044699>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFRYDP7X3SVJ6PH2RF2DEB35FYQF3AVCNFSNUABFKJSXA33TNF2G64TZHM4DSNJXGM2TENJSHNEXG43VMU5TIOJRHA4DIOJXGAZKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AFRYDP6GSJ7XBWLKXP65ZK35FYQF3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGMYDINBWHE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AFRYDP7GZEFZOTWKNNXNCGT5FYQF3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGMYDINBWHE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[agriggio]

Ok, I'll keep it open but won't address this for now. If you see this again feel free to add more comments