It’s a jungle out there.
As was more or less discussed in the post, EXIF concerns itself more or less with hardware and camera attributes and can be considered authoritative for that domain.
IPTC was added by photojournalism to cover more artistic metadata like a caption, author (photographer), keywords, etc.
Like the one XKCD strip, XMP seems to have come along to try and create a 3rd standard to replace the first two…
Happens a lot when standard is not specific enough.
But now it's quite different with LLMs. I recently updated my code and Claude had useful recommendations.
In particular, you probably don’t want the GPS coordinates of your house publicly available on your blog for everyone to see.
I would like my camera info, especially the body, lens, focal length, and settings in the image. I recently discovered that software like Darktable can even take a gpx file and photo timestamps to add coordinates to photos taken on a camera without a GNSS receiver.
People who can track down the original exif can recreate when, where and with what equipment the photo was taken. It's been great to identify places and people for posterity.
That sounds exactly like a file format to me. Are you suggesting that json is the only format developers might be aware of?
All of these, the author mentions. Now for SynthID[3], which both OpenAI and Google embed in the pixels of the images they generate. Needless to say, in mutually incompatible ways.
[1]: https://iptc.org/news/draft-for-public-comment-new-photo-met...
[2]: https://c2pa.org/
After a lot of investigation, we discovered that only photos uploaded by one specific (prolific) person had this issue. And it was caused by their software putting some nonsense exif DPI data in the image that was ignored as nonsense by every renderer except outlook. The format is a minefield of features with inconsistent support.
But I suppose that's part and parcel with actually being used. And that's somewhat better than the alternative.
> The actual behavior depends on the source image, OS, browser, file picker, app, export path, transformation pipeline, and receiving service.
It's a bit hair-pulling that Android now has a filter between the file system and app, that when an app asks for a JPEG file from the filesystem, the filter strips the EXIF. Yes, it's because as Douglas Adams observed, the universe is busy making more and more idiots (for example Zuck's zucking apps might not have location permissions but it can scan the EXIF GPS tags of all your images to determine where you've been), and the solution to that is also idiocy.
My primary goal was to have my core "xv" muscle-memory usable through a simple tool that didn't require me building the original xv (since you can't just apt install it), because these days I'm not using xv much.
But I've since added a few features that xv doesn't have like the Exif and also image annotation, plus beefed up the image enhancement to be very much like XVs.
Date of capture/scan vs date of scanned artefact.
It's a minefield.
Adhoc methods like "month zero" or "nonce time" suck too.
Then there's how Google, Apple and Microsoft don't agree if file acquired EXIF data is mutable. Side cars. Search terms. Modified in system or by an API? Another minefield.
Post edit. Same or different image? Perceptual hash fine but can I track source image by a field in edited image?
