Wrote a parser to extract image metadata once, and got massively frustrated with the amount of undocumented, semi-documented, wrongly documented, or partially documented attributes. You’ll find references online, but most of them lack half of what you encounter in images. Every image processing app under the sun adds its own range. Some use metric values, some imperial; finding out which can be guesswork. Aperture is given in f-stops, decimals, or literal fraction strings. Some attributes hold sentinel values. Some vendors have custom conventions for undefined data.
Yes. I run a niche webapp[1] that extracts exif and xmp (Lightroom edits) from images. At one point I tried to write my own exif parser. It's not that complicated, but very quickly you'll run into weird legacy, vendor-specific nuances (apart from what the parent mentioned, you have to handle both big & little endian exif). And the long tail of those edge cases is, well, very long. Exiftool handles pretty much all of that.
I work on the receiving end of media processing nowadays, and the overlap of variety in formats, codecs, and configurations is frustrating. No two encoders work the same way, and they often "innovate" in fun and varied ways that almost feel like renewed attempts to make decoders crash.
Apple engineers partnered with Sony, Canon, Nokia, Adobe, Microsoft to try and hammer out a specification that addresses when different metadata flavors overlap (EXIF, IPTC, XMP) [1]. It was not comprehensive (to be sure) but covered the most common properties.
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…
A few years ago I wrote an exif parser too, solely for reading/editing text comments, which is much simpler than what you did. Even then, yes, it's not pretty, very frustrating. There are multiple places to put text in exif, and it took a while to find most (all?) the edge cases.
But now it's quite different with LLMs. I recently updated my code and Claude had useful recommendations.
I worked at a company that displayed user-uploaded photos online and in email newsletters. Some small portion of photos displayed very incorrectly only in the email newsletters as displayed by outlook. They were fine everywhere else.
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.
> Do not assume the operating system strips Exif, or any other metadata, when you upload an image.
> 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.
FYI: I just recently added simple Exif viewing/editing/clearing to my "xv"-inspired image editor pxv: https://github.com/linsomniac/pxv
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.
As with most standards, there are three almost overlapping standards for image metadata. EXIF, IPTC and XMP. IPTC incidentally is hot again because certain generative AI providers add IPTC metadata[1] to the images they generate. Incidentally, OpenAI uses another standard for the same purpose, C2PA[2].
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.
I wouldnt recommend exiftool in a commercial image pipeline. way too slow compared to libexif or tagging your images with in the image lib.
We store everything in tiff tags and exif tags, as our database. But we also embed yaml as comment for everything not covered.
Exif is great but here is your obligatory reminder that if you are publishing images you should strip out some of the identifying information that cameras and image editing software likes to embed.
In particular, you probably don’t want the GPS coordinates of your house publicly available on your blog for everyone to see.
Conversely, as a hobbyist photographer, I want to do the exact opposite for most photos I take.
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.
This why I have my phones track themselves (started with Moostrax on the Blackberry then iOS, Moves on iOS until Facebook killed it, now it's OwnTracks on iOS logging to my server + Arc Timeline + Gyroscope + some others, I think) - even without the "where was this photo taken?" helpfulness (for camera shots + phone shots with stripped location), it's also good for "where was that cafe / coffee shop / craft shop / whatever?" kind of questions (obviously assuming you can remember vaguely what date and time...)
I should get better at taking contemporaneous notes, really, but since that hasn't happened in 30+ years, I doubt it's going to stick now.
It's so stupid that we have to do geotagging as a post processing step with separate software. That could be built in to the camera with a GNSS receiver or smartphone Bluetooth link with minimal impact on cost or battery life. And yet even today many high end cameras lack such basic functionality. It's like the camera manufacturers aren't even trying anymore.
Most publication and messaging tools strip exif data, which is incredibly frustrating when friends send you pictures taken together as you no longer have the time stamp, nor GPS coordinate.
On the other hand, the fact that exif is such a widespread standard has been a great tool for photo archaeology.
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.
Exif is totally unlike what modern developers would think of as a "file format". It's more like dumping a set of binary block data structures from memory to disk. This was efficient on old digital cameras with minimal hardware resources. But making any significant edits requires doing pointer arithmetic, which can be an alien concept for developers who have only ever used memory-safe programming languages.
I'm suggesting that newer developers will find Exif to be quite different from hierarchical file formats that use delimiters between data elements, as is common practice lately with XML / JSON / YAML / etc. And it is technically somewhat challenging to manipulate Exif using the most popular high-level languages. Obviously competent developers can overcome these challenges.
Date. Date and time. Approximate date. Conjectural dates like "before 1932" or "Easter, but maybe before 1905"
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?
Wrote a parser to extract image metadata once, and got massively frustrated with the amount of undocumented, semi-documented, wrongly documented, or partially documented attributes. You’ll find references online, but most of them lack half of what you encounter in images. Every image processing app under the sun adds its own range. Some use metric values, some imperial; finding out which can be guesswork. Aperture is given in f-stops, decimals, or literal fraction strings. Some attributes hold sentinel values. Some vendors have custom conventions for undefined data.
It’s a jungle out there.
Yes. I run a niche webapp[1] that extracts exif and xmp (Lightroom edits) from images. At one point I tried to write my own exif parser. It's not that complicated, but very quickly you'll run into weird legacy, vendor-specific nuances (apart from what the parent mentioned, you have to handle both big & little endian exif). And the long tail of those edge cases is, well, very long. Exiftool handles pretty much all of that.
[1] https://pixelpeeper.com/
Pixelpeeper looks amazing, by the way. Such a great idea, thank you for sharing.
I work on the receiving end of media processing nowadays, and the overlap of variety in formats, codecs, and configurations is frustrating. No two encoders work the same way, and they often "innovate" in fun and varied ways that almost feel like renewed attempts to make decoders crash.
Apple engineers partnered with Sony, Canon, Nokia, Adobe, Microsoft to try and hammer out a specification that addresses when different metadata flavors overlap (EXIF, IPTC, XMP) [1]. It was not comprehensive (to be sure) but covered the most common properties.
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…
[1] https://en.wikipedia.org/wiki/Metadata_Working_Group
Sounds like a worse version of non-standard (X-*) HTTP headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
Happens a lot when standard is not specific enough.
My hell was trying too make sense or and organise audio/music ID3 tags. What a nightmare that is. EXIF seems much nicer to me.
Picard is far from perfect, but it does more or less impose a semblance of uniformity across a large library.
Yes, that's what I ended up using. I was wanting to program something myself but it was too difficult. MusicBrainz Picard [1] is excellent.
[1] https://picard.musicbrainz.org/
A few years ago I wrote an exif parser too, solely for reading/editing text comments, which is much simpler than what you did. Even then, yes, it's not pretty, very frustrating. There are multiple places to put text in exif, and it took a while to find most (all?) the edge cases.
But now it's quite different with LLMs. I recently updated my code and Claude had useful recommendations.
production-grade interpreters are always full of dirty works.
that sounds endlessly frustrating
I worked at a company that displayed user-uploaded photos online and in email newsletters. Some small portion of photos displayed very incorrectly only in the email newsletters as displayed by outlook. They were fine everywhere else.
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.
> Do not assume the operating system strips Exif, or any other metadata, when you upload an image.
> 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.
FYI: I just recently added simple Exif viewing/editing/clearing to my "xv"-inspired image editor pxv: https://github.com/linsomniac/pxv
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.
As with most standards, there are three almost overlapping standards for image metadata. EXIF, IPTC and XMP. IPTC incidentally is hot again because certain generative AI providers add IPTC metadata[1] to the images they generate. Incidentally, OpenAI uses another standard for the same purpose, C2PA[2].
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/
[3]: https://arxiv.org/abs/2510.09263
I suppose watermarks are metadata. Never considered it that way.
Exif is technical debt in the most flattering sense. Messy, old, and still quietly useful decades later.
I wouldnt recommend exiftool in a commercial image pipeline. way too slow compared to libexif or tagging your images with in the image lib. We store everything in tiff tags and exif tags, as our database. But we also embed yaml as comment for everything not covered.
Yep, exiftool is great for CLI use, but in a production pipeline a library is the way to go over shelling out.
Exif is great but here is your obligatory reminder that if you are publishing images you should strip out some of the identifying information that cameras and image editing software likes to embed.
In particular, you probably don’t want the GPS coordinates of your house publicly available on your blog for everyone to see.
Conversely, as a hobbyist photographer, I want to do the exact opposite for most photos I take.
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.
Yup. Looking back I wish I had location data on some of the photos I took. Can't share them but can't also remember where I took them. Unfortunate.
This why I have my phones track themselves (started with Moostrax on the Blackberry then iOS, Moves on iOS until Facebook killed it, now it's OwnTracks on iOS logging to my server + Arc Timeline + Gyroscope + some others, I think) - even without the "where was this photo taken?" helpfulness (for camera shots + phone shots with stripped location), it's also good for "where was that cafe / coffee shop / craft shop / whatever?" kind of questions (obviously assuming you can remember vaguely what date and time...)
I should get better at taking contemporaneous notes, really, but since that hasn't happened in 30+ years, I doubt it's going to stick now.
Yes, as another privacy "aficionado" many years ago I had taken so many photos that I don't remember where I took, and I can't ask around either :'(
Apparently AI models have gotten decent at geoguessr... Might be worth a shot?
https://news.ycombinator.com/item?id=43724935
It's so stupid that we have to do geotagging as a post processing step with separate software. That could be built in to the camera with a GNSS receiver or smartphone Bluetooth link with minimal impact on cost or battery life. And yet even today many high end cameras lack such basic functionality. It's like the camera manufacturers aren't even trying anymore.
Most publication and messaging tools strip exif data, which is incredibly frustrating when friends send you pictures taken together as you no longer have the time stamp, nor GPS coordinate.
Incredibly frustrating but absolutely to be expected.
Publication (Facebook, insta, reddit etc...), yes, messaging not so much.
On the other hand, the fact that exif is such a widespread standard has been a great tool for photo archaeology.
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.
Exif is totally unlike what modern developers would think of as a "file format". It's more like dumping a set of binary block data structures from memory to disk. This was efficient on old digital cameras with minimal hardware resources. But making any significant edits requires doing pointer arithmetic, which can be an alien concept for developers who have only ever used memory-safe programming languages.
>It's more like dumping a set of binary block data structures from memory to disk.
That sounds exactly like a file format to me. Are you suggesting that json is the only format developers might be aware of?
I'm suggesting that newer developers will find Exif to be quite different from hierarchical file formats that use delimiters between data elements, as is common practice lately with XML / JSON / YAML / etc. And it is technically somewhat challenging to manipulate Exif using the most popular high-level languages. Obviously competent developers can overcome these challenges.
"A boring standard that aged well" --so true. I love, love exif.
Date. Date and time. Approximate date. Conjectural dates like "before 1932" or "Easter, but maybe before 1905"
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?
[flagged]
[flagged]