3 ms·

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

by ggm 1y ago

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"

SchemaLoad 1y ago
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.
- ggm 1y ago
  It's in sidecar files. Takeout gets them, some tools read them.
  - kccqzy 1y ago
    But there is no standardization of sidecar files, no? Whereas EXIF is pretty standard.
    - jeroenhd 1y ago
      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.
      - SchemaLoad 1y ago
        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.
        account42 1y ago
        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.
    - account42 1y ago
      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 https://en.wikipedia.org/wiki/Extensible_Metadata_Platform
- mbirth 1y ago
  IIRC osxphotos has an option to merge external metadata into the exported file.
luguenth 1y ago
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 https://www.media.mit.edu/pia/Research/deepview/exif.html [1] https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/
- ggm 1y ago
  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.

by ggm 1y ago

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"

SchemaLoad 1y ago

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.

ggm 1y ago
It's in sidecar files. Takeout gets them, some tools read them.
- kccqzy 1y ago
  But there is no standardization of sidecar files, no? Whereas EXIF is pretty standard.
  - jeroenhd 1y ago
    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.
    - SchemaLoad 1y ago
      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.
      - account42 1y ago
        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.
  - account42 1y ago
    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 https://en.wikipedia.org/wiki/Extensible_Metadata_Platform
mbirth 1y ago
IIRC osxphotos has an option to merge external metadata into the exported file.

luguenth 1y ago

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 https://www.media.mit.edu/pia/Research/deepview/exif.html [1] https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/

ggm 1y ago
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.