Hacker News Reader

Hacker News

Comment by ggm | Hacker News Reader

Full thread

ggm

Somebody needs to manage human time/date approximates in a way other people in s/w will align to.

"photo scanned in 2025, is about something in easter, before 1940 and after 1920"

View on HN

In EXIF, you have DateTimeDigitized [0]

For ambiguous dates there is the EDTF Spec[1] which would be nice to see more widely adopted.

[0] https://www.media.mit.edu/pia/Research/deepview/exif.html

[1] https://www.loc.gov/standards/datetime/

I remember reading about this in a web forum mainly for dublin core fanatics. Metadata is fascinating.

Different software reacts in different ways to partial specifications of yyyy/mm/dd such that you can try some of the cute tricks but probably only one s.w. package honours it.

And the majors ignore almost all fields other than a core set of one or two, disagree about their semantics, and also do wierd stuff with file name and atime/mtime.

The issue that gets me is that Google Photos and Apple photos will let you manually pick a date, but they won't actually set it in the photo EXIF, so when you move platforms. All of the images that came from scans/sent without EXIF lose their dates.

It's in sidecar files. Takeout gets them, some tools read them.

But there is no standardization of sidecar files, no? Whereas EXIF is pretty standard.

EXIF inside of PNGs is new. You can make it work by embedding structured chunks into the file, but it's not official in any way (well, not until the new spec, at least). Sidecar files have some kind of interoperable format that at least don't break buggy PNG parsers when you open the image file. The sidecar files themselves differ in format, but at least they're usually formatted according to their extension.

The usual sidecar files, XMP files, are standardised (in that they follow a certain extensible XML structure) and can (and often do) include EXIF file information.

Pretty much all the photos in Apple/Google photos are going to be JPEG and HEIF which do support EXIF. But both services basically will not touch what came out of the camera at all. If you add a description or date, it gets stored externally to the image so when you export your data, those changes are lost. Or they get dumped in a JSON file requiring you to use some custom script to handle it.

Not touching the image for metadata changes is a good thing as that makes backups more efficient/simpler. Embedded metadata is also a security issue as users may share more information than they realize which is why it is common to strip it automatically in many places.

XMP [0] is a standard but no idea of Google and Apple use it (Darktable does). You could also store EXIF data as sidecar files but I don't think that has better support.

[0] https://en.wikipedia.org/wiki/Extensible_Metadata_Platform

IIRC osxphotos has an option to merge external metadata into the exported file.

Reply on news.ycombinator.com