←back to thread

94 points justin-reeves | 10 comments | | HN request time: 0.435s | source | bottom
1. postalcoder ◴[] No.46005113[source]
As a former metadata completionist, my mind starts to dissociate when I think about my battles with EXIF metadata, vendor-specific metadata, and the way different software supports, or refuses to support, any of it.

It gets even worse when ingesting images into Apple Photos, where you have to confront papercut bugs that you know will never be fixed.

I love ExifTool. It’s one of the great utilities. It works for almost every file I throw at it. But reading its output can be unsettling. It’s like getting a glimpse of eudaimonia, only to have it rudely interrupted by the reality of Apple Photos misreading every lens in your collection.

replies(4): >>46005520 #>>46005609 #>>46006247 #>>46006517 #
2. foobarian ◴[] No.46005520[source]
I'm comforted that it's not only me :D. I made a tool to index/exfiltrate media from phone backups and DSLR storage and the behavior has been changing over the years without me changing anything.
3. netsharc ◴[] No.46005609[source]
I guess orientation isn't even metadata any more, but data: the RGB(A) value of each pixel is data, and the location of this pixel is also data. But the location of the pixel changes depending on the orientation. Of course absent of any orientation it can be understood as "information of the image is stored in the file describing the image" in left-to-right, top-to-bottom order (but with BMPs it's bottom to top!), but with orientation "metadata", it's whatever is defined there.

So yeah, I think "Stripping all EXIF metadata doesn't change an image" deserves an entry as a "falsehood programmers believe about...".

replies(1): >>46005647 #
4. pavlov ◴[] No.46005647[source]
The same applies to color space. You can’t interpret the pixel data without knowing the color space. If it’s not in the metadata, you just have to assume sRGB and hope for the best.

It’s the same with rotation. Both are essential information on how to interpret the pixel data for display, but we’re so very used to assuming certain defaults that it’s easy to forget about this.

5. ziml77 ◴[] No.46006247[source]
I've been trying to create clean metadata for a collection of Blu-ray rips recently. The MKV format has a bunch of defined metadata fields but handling of it is inconsistent between players. VLC seems to be the worst in that it doesn't even bother displaying important pieces of the metadata. You can work around that by effectively duplicating the important parts in the track name, but then other software ends up doubling up on that because it's displaying both the track name and the values pulled from the other track metadata. And I'm being driven crazy on how I should use the subtitle track flags that indicate if a track is Forced or Default, because it seems like the auto-selection behavior based on those flags arbitrary from player to player.

I should probably just give up and let it all be a mess. Not sure I'll be able to though. The only thing that freed me from metadata obsession when it came to my music collection is that I switched to streaming services.

replies(1): >>46010549 #
6. concinds ◴[] No.46006517[source]
> It gets even worse when ingesting images into Apple Photos, where you have to confront papercut bugs that you know will never be fixed.

I wish they open-sourced their built-in macOS apps.

replies(1): >>46006605 #
7. pstuart ◴[] No.46006605[source]
A nice compromise would be to open source the libraries that consume and emit data as well as core processing. Then they can add their own secret sauce UX and integration.

Likewise, that will never happen either.

replies(1): >>46008953 #
8. AlanYx ◴[] No.46008953{3}[source]
Yes, they used to compromise more along these lines in the past. e.g., Samba's vfs_fruit would never have gotten as good as it is without Apple open sourcing their SMBClient. Everyone benefits, even Apple (I'm sure they're running vfs_fruit on their server storage arrays internally). Wish they'd do it more.
9. aidenn0 ◴[] No.46010549[source]
> And I'm being driven crazy on how I should use the subtitle track flags that indicate if a track is Forced or Default, because it seems like the auto-selection behavior based on those flags arbitrary from player to player.

Oh, this seems to be more or less completely ignored when selecting subtitles, though some players will at least list "English (forced)" or "English (default)" &c. when selecting a subtitle. Quite a pain with dubbed foreign-films when the subtitles are used for translating on-screen text; you really want the forced subtitle in that case!

replies(1): >>46011348 #
10. namibj ◴[] No.46011348{3}[source]
You almost always want to see what's in the forced subs; but if you're reading a different language then it has to be translated first. Also compression and color/HDR mapping prefers the text be separate from the image.