Repository navigation
fix(export): write complete, valid EXIF for RAW sources - #1897
Merged
Merged
Conversation
RAW exports took their EXIF from RapidRAW's metadata cache, which holds display strings, and only read the RAW's typed values when that cache was missing. Capture dates were written as "2026-09-12 13:41:33", which is not valid EXIF, so Explorer and Immich showed no date taken, and white balance, flash, metering mode, exposure program and exposure bias were dropped (CyberTimon#1808, CyberTimon#1612). Always read the typed EXIF from the RAW first, also writing shutter speed, aperture value and lens specification, then let the cache override the fields it carries, with its dates converted to EXIF format. Add the ExifVersion, FlashpixVersion and (for JPEG) ComponentsConfiguration tags the spec requires. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
7 of 17 tasks
Owner
|
LGTM, thanks so much!! |
2 tasks done
FabianWeiss90
added a commit
to FabianWeiss90/RapidRAW
that referenced
this pull request
Oct 11, 2026
CyberTimon#1897 split write_image_with_metadata into write_exif_metadata and embed_xmp, while this branch had split the same function differently to get at the gathered metadata before encoding. Resolved in favour of the upstream structure: the gathering step is extracted out of write_exif_metadata into collect_metadata_from_source again, which the TIFF encoder calls before writing any pixels. ExifVersion and FlashpixVersion, which CyberTimon#1897 adds, sit in that shared step now, so TIFF carries them as well and exiftool -validate passes without warnings.
8 of 17 tasks
|
thank you for this! I was in the process of writing up a bug for this and was delighted to find that not only was there a bug filed but a fix has already been merged! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #1808 and #1612.
Exports from RAW files wrote incomplete and partly invalid EXIF. For RAW sources, the export took its values from RapidRAW's metadata cache, which stores display strings. It only read the RAW's own typed values when that cache was missing, which almost never happens once a folder has been browsed. As a result:
DateTimeOriginal/CreateDatewere written as2026-09-12 13:41:33. EXIF requires2026:09:12 13:41:33, so Windows Explorer's "Date taken" and Immich ignored the date (exiftool -validateflags it).ExifVersion,FlashpixVersionandComponentsConfigurationwere missing, though the spec requires them.Now the RAW's typed EXIF is always read first. The cache then overrides only the fields it already handled, so things like the Nikon lens name recovered from the MakerNote (#1823) are kept. Its dates are converted to EXIF format.
Type of Change
Changes Made
exif_processing.rs:apply_exif_from_rawler(the former inline fallback block) now runs for every RAW source, before the cache values are applied. It also writesShutterSpeedValue,ApertureValueandLensInfo(lens specification).format_creation_datetime(.., EXIF_DATETIME_FORMAT), which shares the parsing with the existingfmt_date_str.ExifVersion(0232) andFlashpixVersion(0100) are always written, andComponentsConfigurationis written for JPEG.read_raw_metadata,read_raw_metadata_from_pathand both rawler apply functions now share one loader (raw_metadata_from_source) and two rational helpers (rawler_to_ur64/rawler_to_ir64, next to the existingto_ur64/to_ir64).Screenshots/Videos
This one was already present, just showing no regression :
Testing
Checked on NEF (Nikon D810), ARW (three Sony files, one with GPS), CR3, CR2, RAF and DNG:
Test Configuration:
Checklist
Additional Notes
FocalLengthIn35mmFilmholds the real focal length rather than the 35mm equivalent. That was already the case before this PR, and the export still writes it from the cache.AI Disclaimer:
Please state the involvement of AI in this PR:
🤖 Generated with Claude Code