ConfigureHow

Photo metadata and organizing a library that survives

Published . 8 min read

Exif, IPTC and XMP are three separate standards that ride in the same file. Exif holds what the camera knew (exposure, lens, orientation, GPS, timestamps), IPTC holds what a person asserts about the picture (caption, creator, keywords, rights), and XMP is the XML/RDF container Adobe built to carry any of it. For a library that still opens in twenty years: dated folders on an ordinary filesystem, descriptive metadata inside the files, and every catalog treated as rebuildable.

What each standard actually holds

CIPA publishes Exif. The current English edition is Exif Version 3.1, document CIPA DC-008-Translation-2026, dated 2026-01-30, which CIPA lists as "the revised edition of CIPA DC-008-2024." ExifTool logged "Added new tags of the Exif 3.1 specification" in version 13.56 on April 15, 2026. Which cameras emit them is a separate question the standard does not answer. A second CIPA document, DC-010-2026, covers how Exif values get mirrored into XMP, which is why one capture time can legitimately exist twice in a file.

Exif is TIFF-shaped: ExifTool describes it as "formatted according to the TIFF specification," found in "JPG, TIFF, PNG, JP2" and "many TIFF-based RAW images." IPTC stays out of that territory deliberately. Its specification "does not include any technical metadata," because standards for those "are under the control of the camera manufacturers, their associations (such as CIPA) and others." The current text is version 2025.1 rev 1, dated 2025-11-26, on Core schema 1.5 and Extension schema 1.9.

IPTC then exists in two encodings, which is where confusion starts. The old one is IIM, a binary block ExifTool calls "an older meta information format, slowly being phased out in favor of XMP," with tiny fixed field limits: By-line (tag 80) tops out at 32 characters, CopyrightNotice (tag 116) at 128, Keywords (tag 25) at 64 per keyword. The modern encoding is the same properties expressed as XMP, "an XML/RDF-based metadata format which is being pushed by Adobe," an ISO standard (16684-1) since early 2012.

LayerWhat it carriesDate precisionWhere it lives
Exifcamera settings, orientation, GPS, timestampssub-seconds and UTC offset in separate tagsTIFF block in the image
IPTC IIMcaption, creator, keywords, copyrighttimezone offset, no sub-secondsbinary block in the image
XMPIPTC Core and Extension, plus mirrored Exifdate, sub-seconds and offset in one propertyembedded packet or sidecar

The three date fields, and why they disagree

Exif defines three date tags, and software reading a different one than you assumed is the cheapest explanation for a library that sorts itself into nonsense.

DateTimeOriginal (0x9003) is "the date and time when the original image data was generated," which for a still camera is the shutter. DateTimeDigitized (0x9004) is "the date and time when the image was stored as digital data," a distinct moment for scanned film. DateTime (0x0132) is documented in one self-contradicting sentence: "the date and time of image creation. In Exif standard, it is the date and time the file was changed." The second half is what implementations follow.

ExifTool then labels 0x9004 as CreateDate, "called DateTimeDigitized by the EXIF spec", and 0x0132 as ModifyDate, "called DateTime by the EXIF spec." So the field displayed as "Create Date" is the digitizing time: a scan of a 1974 negative reads as created the day it was scanned. And DateTime, whose spec name sounds most like a creation date, moves whenever any program rewrites the file.

The three Exif date tags and the names software prints for them Three rows, one per Exif date tag, showing the spec name, the label ExifTool prints, and what the tag actually records. DateTimeOriginal, tag 0x9003, keeps its name in both and holds the date and time when the original image data was generated, which for a still camera is the shutter. DateTimeDigitized, tag 0x9004, is labelled CreateDate and holds the date and time when the image was stored as digital data, so a scan of a 1974 negative reads as created the day it was scanned. DateTime, tag 0x0132, is labelled ModifyDate and in the Exif standard is the date and time the file was changed, so it moves whenever any program rewrites the file. Each tag has a matching offset tag from 0x9010 to 0x9012, but Exif had no way to record a time zone before version 2.31 in July 2016. One capture, three Exif date tags Exif spec name ExifTool label What it actually records DateTimeOriginal 0x9003 DateTimeOriginal same name in both the date and time when the original image data was generated For a still camera, the shutter. DateTimeDigitized 0x9004 CreateDate not the capture time the date and time when the image was stored as digital data A scan of a 1974 negative reads as created the day it was scanned. DateTime 0x0132 ModifyDate not a creation date In Exif standard, it is the date and time the file was changed Moves whenever any program rewrites the file. Each has a matching offset tag, 0x9010 to 0x9012. Exif had no way to record a time zone before version 2.31 in July 2016, so anything older carries a wall clock with nothing anchoring it.
Both renamed tags read as creation dates in a file browser, which is why a library sorted on the wrong one looks plausible right up until you check a scan.

OffsetTime, OffsetTimeOriginal and OffsetTimeDigitized (0x9010 to 0x9012) each record the "time difference from Universal Time Coordinated including daylight saving time" for their matching date tag. But Exif had no way to record a time zone before version 2.31 in July 2016. Any photo older than that, or written by software that leaves the offset empty, carries a wall-clock reading with nothing anchoring it. The true UTC instant is not in the file.

Conversion between the three is lossy by design. IPTC's mapping guidance: "Exif's DateTimeOriginal holds both date and time, SubSecTimeOriginal the time's sub-seconds, OffsetTimeOriginal the offset of a local timezone; XMP's photoshop:DateCreated holds date, time with sub-seconds and timezone offset; IIM's Date Created holds the date, Time Created holds the time (without sub-seconds) and a timezone offset." The instruction that follows is blunt: "for IIM the sub-seconds should be ignored." Push a burst through a tool that writes IIM and the frames' order within that second is gone.

Dates that break without anyone editing the photo

The filesystem fails independently of Exif. GNU cp will not carry the source modification time across unless asked: --preserve=timestamps is documented as "preserve the times of last access and last modification, when possible," with -p as shorthand for --preserve=mode,ownership,timestamps. Tested on coreutils 9.4, a file stamped 2019-03-04 copied with bare cp came out stamped with today's date, while cp -p kept 2019. Copy 40,000 photos off an old drive without the flag and an organizer sorting by date collapses the archive into one month.

Filesystems also disagree about what a timestamp means. Microsoft: "The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer." A file saved at 3:00pm PST in Washington "is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York on a FAT volume." Camera cards are FAT or exFAT and your desktop drive probably is not, so one file reports two times depending on its volume. On FAT, "write time has a resolution of 2 seconds," so sub-second burst ordering dies there too.

The same saved file read from an NTFS volume and a FAT volume One file saved at 3:00pm PST in Washington, then read in New York from two different volumes. NTFS stores time values in UTC format, so the file is seen as 6:00pm EST and is not affected by changes in time zone or daylight saving time. FAT stores time values based on the local time of the computer, so the same file is seen as 3:00pm EST, and FAT write time has a resolution of 2 seconds, which destroys sub-second burst ordering. Camera cards are FAT or exFAT and a desktop drive usually is not, so one file reports two times. One saved instant, two volumes, two clocks Saved at 3:00pm PST in Washington one instant, written once NTFS volume stores time values in UTC format reads in New York as 6:00pm EST not affected by changes in time zone or daylight saving time FAT volume stores time values based on the local time of the computer reads in New York as 3:00pm EST write time has a resolution of 2 seconds, so burst order dies Camera cards are FAT or exFAT and your desktop drive probably is not, so one file reports two times. Filesystem dates are never the source of truth. DateTimeOriginal is.
Nothing in the file changed between the two readings. Only the volume's convention for storing the number did, which is why the drift appears the moment photos move off the card.

Take a position once and hold it: filesystem dates are never the source of truth, DateTimeOriginal is. Before any rename or folder scheme, dump metadata across a few hundred representative files and count the empty OffsetTimeOriginal values. That number decides whether a UTC-normalized naming scheme is possible.

Sidecars versus embedded metadata

digiKam documents the choice cleanly. Its Sidecars settings offer "Write to item and XMP Sidecar," which "will write to both item and sidecar at the same time," and "Write to XMP sidecar for read-only item only," which "will write to sidecars for non-writable items only, such as video or RAW files." A Lazy Synchronization option decides when writing happens: "When unchecked, synchronization and writing of metadata occurs immediately." Checked, it defers writes until you apply pending changes or quit.

Embed wherever the format allows it, use sidecars only where a proprietary RAW or video container forces your hand, and leave lazy synchronization off during an archive pass so writes reach disk before the program closes. The failure mode of a sidecar is separation: a second file sharing a basename, orphaned by any copy made by selecting files, any upload of just the JPEGs, any sort by type. Copy directories, not files.

Folders outlive catalogs

Apple states what a Photos library is: "New photos and videos that you add to Photos are stored in this library. The library is located in the Pictures folder on your Mac." Then the warning: "To avoid accidentally deleting or corrupting a photo library, do not manually access or alter the contents of a library in the Finder." That is a container whose layout you do not own and are told not to touch. It works until you want the files elsewhere, and then export stands between you and your own photographs.

A scheme of YYYY/YYYY-MM-DD-event folders costs nothing and has no vendor attached. It sorts chronologically in any file manager and gives backup tools stable paths to diff. People, places, ratings and captions belong in IPTC and XMP fields inside the file, so any future indexer can rebuild the database you lost.

Preserve one more thing on that pass. The IPTC Extension schema now carries AI declaration fields: AI Prompt Information, AI Prompt Writer Name, AI System Used and AI System Version Used, alongside Digital Source Type, which "indicates the media source from which the digital image was created" from a controlled list at cv.iptc.org. That list separates digitalCapture from trainedAlgorithmicMedia and compositeWithTrainedAlgorithmicMedia, the latter "augmentation, correction or enhancement using a Generative AI model, such as with inpainting or outpainting operations." ExifTool added them in version 13.40 on October 24, 2025, eight days after Extension schema 1.9 was approved. Any copying script older than that drops them silently.

Deduplicating without destroying originals

Two problems share one name. Byte-identical copies are a hashing problem, safe to detect mechanically. Files that look identical but were resized or re-compressed never hash-match, and finding them needs perceptual comparison, a separate mode in both tools.

Czkawka just changed shape. Its README now reads: "Version 12.0 is the last released version - no new binaries will be provided. New users and existing users are encouraged to switch to Krokiet." Release 12.0.0 landed 2026-06-28. Krokiet, its Slint-based replacement for the old GTK 4 interface, keeps the same split between "Duplicates - Finds duplicates based on file name, size or hash" and a separate "Similar Images" mode. The 12.0 notes add "geometric invariance support for similar images mode, allowing mirrored, flipped, and rotated images to be matched." Download Krokiet; the Czkawka GTK build older articles link to is dead.

dupeGuru is what those older articles recommend, and its design is sound: "its reference directory system as well as its grouping system prevent you from deleting files you didn't mean to delete," you can "move or copy them elsewhere" instead of deleting, and it has "a special Picture mode that can scan pictures fuzzily." Its most recent release is 4.3.1, dated 2022-07-09. Four years without a release is worth knowing before aiming it at an irreplaceable archive.

The rule that saves you regardless of tool: no first pass deletes. Move candidates into a quarantine directory on the same volume and leave them through one full backup cycle before emptying. When two files look identical but are not byte-identical, keep the larger pixel dimensions and fuller metadata block. Never break the tie on file dates, for every reason above.

Sources