Found via
Independent exiftool-parity audit comparing oxidex against a freshly pulled ExifTool 13.55 tag database (just compare-exiftool-full + scripts/find_tag_gaps.py).
Bug
Values pulled from APP11 (JPEG-HDR) / APP12 (Ducky/Camera info) segments come out garbled in JPEG output:
EXIF:ApertureValue shows the literal string "F2.8" instead of a computed numeric valueEXIF:DateTimeOriginal shows a raw integer (883639173) instead of a formatted date- One rational value (
Ln0) showed as 13635833219286100554547200000 instead of ExifTool's 0.122262
This looks like a field-offset/byte-order alignment bug in the segment reader, not a missing-tag gap — the tags are present but their bytes are being misinterpreted.
Scope
JPEG format. Part of the 352 JPEG value-differences found in the audit; this specific class likely accounts for a meaningful chunk of them.
Repro
Run just compare-exiftool-format JPEG against a JPEG fixture containing APP11/APP12 segments and diff against exiftool -G1 -s.
Found via
Independent exiftool-parity audit comparing oxidex against a freshly pulled ExifTool 13.55 tag database (
just compare-exiftool-full+scripts/find_tag_gaps.py).Bug
Values pulled from APP11 (JPEG-HDR) / APP12 (Ducky/Camera info) segments come out garbled in JPEG output:
EXIF:ApertureValueshows the literal string"F2.8"instead of a computed numeric valueEXIF:DateTimeOriginalshows a raw integer (883639173) instead of a formatted dateLn0) showed as13635833219286100554547200000instead of ExifTool's0.122262This looks like a field-offset/byte-order alignment bug in the segment reader, not a missing-tag gap — the tags are present but their bytes are being misinterpreted.
Scope
JPEG format. Part of the 352 JPEG value-differences found in the audit; this specific class likely accounts for a meaningful chunk of them.
Repro
Run
just compare-exiftool-format JPEGagainst a JPEG fixture containing APP11/APP12 segments and diff againstexiftool -G1 -s.