• IFD namespaces — entries now report which IFD namespace they came from, via the new IfdKind enum (Tiff / Exif / Gps / Interop). This is orthogonal to IfdIndex, which continues to identify a position in the IFD chain: a GPS sub-IFD hanging off IFD0 is IfdIndex::MAIN + IfdKind::Gps.

  • ExifIterEntry::ifd_kind() on the lazy path.
  • Exif::entries() yielding the new ExifEntryRef on the eager path, plus Exif::get_by_code_in(ifd, kind, code).
  • TagOrCode::from_code_in(kind, code) and ExifTag::namespace() for namespace-aware tag resolution.
  • New ExifTag variants that were previously unnameable because their code was already taken: ProcessingSoftware, InteropIndex, InteropVersion. #68

• Interoperability sub-IFD is now parsed — InteropOffset (0xa005) is followed like ExifOffset and GPSInfo, so InteropIndex / InteropVersion entries are exposed instead of silently skipped. Files carrying an Interop IFD yield two extra entries.

• Entries were silently dropped when two IFDs shared a tag code — sub-IFDs inherit their parent's IfdIndex, and the duplicate filter keyed on (ifd_index, code), so a GPS tag whose code also appeared in IFD0 was discarded as a duplicate. A file with 0x000b in both IFD0 (ProcessingSoftware) and the GPS IFD (GPSDOP) lost the GPS value entirely. The filter and Exif's internal storage are now keyed on (ifd_index, ifd_kind, code). #68

• Tags were labelled with another namespace's name — codes were resolved against a single flat table, so IFD0's 0x000b (ProcessingSoftware) was reported as GPSDOP. Resolution now happens within the entry's namespace. #68

• PNG metadata before a large chunk was discarded on streaming sources — metadata found before a chunk larger than the parser buffer was lost when parsing resumed after ClearAndSkip, so an eXIf chunk preceding a large IDAT returned ExifNotFound for streaming sources even though the same bytes parsed fine from memory. The PNG cursor, EXIF source, tEXt entries and source priority are now carried across retries; zero-copy eXIf ranges are preserved while the buffer grows and materialized only before destructive skips, with retained copies bounded at 64 MiB. Thanks @nkgupta-dev. #67

• Exif::iter() / ExifEntry — ExifEntry exposes pub fields, so it cannot gain an ifd_kind accessor without a breaking change. Use Exif::entries() / ExifEntryRef instead. iter() keeps working and now resolves tag names per namespace, but still cannot tell a GPS entry from an IFD0 entry that shares its code.

• ExifTag::from_code and From<u16> for TagOrCode are unchanged and still resolve contested codes the way they always have (GPS wins).
• size_of::<ExifTag>() grows from 2 to 4 bytes: namespaces are encoded in the high 16 bits of the discriminant so that code() and the pre-existing ExifTag::X as u16 idiom keep returning the real tag code. Note that clippy's cast_enum_truncation now fires on as u16 for the three namespaced variants — prefer .code().

Full changelog: CHANGELOG.md · crates.io: nom-exif 3.8.0

• WebP (RIFF/WEBP) image support — detects RIFF/WEBP files and extracts EXIF/GPS from the EXIF chunk via the unified parse_exif / read_exif (sync + async) APIs. The chunk walker skips the image bitstream to reach the trailing EXIF chunk and is bounded by the RIFF size field. Scope is EXIF-only (no XMP). #61

Full changelog: CHANGELOG.md · crates.io: nom-exif 3.7.0

• ISO 6709 track GPS: fix seconds scaling and recover CRS-less altitude (#66) — for QuickTime/MP4 ©xyz / com.apple.quicktime.location.ISO6709 locations:
  • The fraction of a minute was stored unscaled in the seconds slot, a positional error of up to a full minute's worth of scaling (~350 m). It is now multiplied by 60 before storing hundredths, so +47.7199… decomposes to 47° 43' 11.64" instead of 47° 43' 0.19".
  • Apple's default +lat+lon+alt/ form has no CRS suffix, and iso6709parse only decodes altitude when a CRS tag follows, so the altitude was dropped. It is now recovered, e.g. +522.171 → 522.171 m.

This is a maintenance backport for users pinned to the 2.8 line. The same fix ships in 3.6.3.

crates.io: nom-exif 2.8.1

• Read 4-octet float Matroska/WebM Duration and stop the cursor desync — a Duration element stored as a 4-octet (f32) float was decoded from a zero-initialized buffer, so it always came back as 0 and, because the cursor was never advanced, every element following Duration inside Info was misread (either losing the duration or failing the whole parse). The 4-octet branch now reads the bytes and advances the cursor, matching the 8-octet form. #65

• Recover altitude from CRS-less ISO 6709 track GPS — Apple's default QuickTime location string (+lat+lon+alt/, no CRS suffix) lost its altitude because iso6709parse only decodes the altitude field when a CRS tag follows. GPSInfo::from_str now parses the trailing signed altitude field itself, so +47.7199-117.4931+522.171/ decodes to 522.171 m instead of dropping it. #66

Full changelog: CHANGELOG.md · crates.io: nom-exif 3.6.3

• Avoid overflow panic on malformed HEIF iloc extent offsets — a crafted or corrupt iloc box could produce extent/base offsets that overflow when summed, panicking in debug builds (and wrapping in release). Offset arithmetic in iloc/meta now uses checked addition and returns None for out-of-range extents instead of panicking, so Exif extraction fails gracefully on such files. #64

Full changelog: CHANGELOG.md · crates.io: nom-exif 3.6.2

Patch release for nom-exif.

• Split tokio feature into tokio and tokio-fs — the tokio feature now only pulls in tokio/io-util, enabling the async streaming API (AsyncMediaSource::seekable/unseekable/from_memory, MediaParser::parse_*_async) on wasm32-unknown-unknown. Path-based helpers (read_exif_async, read_track_async, read_metadata_async, AsyncMediaSource::open) moved to the new tokio-fs feature (implies tokio). Users who previously used features = ["tokio"] with read_exif_async etc. should switch to features = ["tokio-fs"]. #53

• Slice coercion in MotionPhoto attribute comparison — comparing extract_attr_value() against byte-string literals now uses explicit &b"..."[..] coercion, fixing a compile error when a crate like rkyv is present in the dependency graph. #58

Full changelog: CHANGELOG.md · crates.io: nom-exif 3.6.0

• Slice coercion in MotionPhoto attribute comparison — comparing extract_attr_value() against byte-string literals now uses explicit &b"..."[..] coercion, fixing a compile error when a crate like rkyv is present in the dependency graph. #58

Full changelog: CHANGELOG.md · crates.io: nom-exif 3.5.1