Earlier quoted context omitted.
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 doub…
> 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. Quit…
EXIF orientation info in PNGs isn't used for image-orientation: from-image
81–90 of 91 posts
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#82Earlier quoted context omitted.
Eh, the coordinate frame can really be anything. It's important to disambiguate what is really meant. The convention in images is that images are +X-Y, but for certain applications, the PNG may represent data that is +X+Y, or mirrored -X+Y, landscape, or portrait. Is the coordinate system the camera coordinates or the world coordinates? It's true that automatic handling of all input images is difficult, but imo it's…
> Eh, the coordinate frame can really be anything. Well, in JPEG, there's exactly one coordinate frame in the absence of EXIF metadata: Left to right, top to bottom. So there's really only one.
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#83Earlier quoted context omitted.
Some systems seem to produce images where the pixel arrangement matches the sensor layout, which moves when you rotate the device, and they'll add EXIF metadata to indicate the orientation. Other cameras and phones and apps produce images where the device adjusts the aspect ratio and order of the array of pixels in the image regardless of the way the sensor was pointed, such that the EXIF orientation is always the de…
The advantage of the EXIF approach is you don't have to do nearly as much post processing of the data? In particular, I don't expect my camera application to need to change memory layout just because I have rotated my camera. So, if you want it to change the rows/columns on saving the image, that has to be post capture from the sensor. Right? I think this is what you meant by "some systems" there. But, I would expect…
And the odds are very high your camera app did already switch memory layouts when you rotated, at least for the UI. Doing that isn't a big deal.
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#84Earlier quoted context omitted.
> Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). Not really. It's hard to see the difference from the outside without actually digging into it first, but in my experience while there's plenty of "easy" bugs that aren't actually easy, there's also plenty of easy bugs that are actually easy and that apparently everyone…
Easy bugs might exist at small and medium size companies, but when you are a $1T+ company, there is no such thing as an easy fix. Your change could have unforeseen side effects that take down some critical revenue-generating service that causes us to lose $millions. It's got to go through multiple code reviews, have unit and integration tests written, be able to show those test passing more than once, it may need to…
And if you devote a whole team to simple fixes, those costs stop being a blocker. So I still like the idea.
And maybe those costs are justified at scale, but what comes with that is your small bugs affecting tons of users, so they shouldn't be ignored for scale-based reasons.
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#85Earlier quoted context omitted.
I firmly believe every product team needs to be split in two: one half works on the issue of highest importance, the other works on the easiest issues. If only to avoid the embarrassment of easy to fix bugs that were passed over for eons just because they weren't priority-high.
There's something to this, although I think the idea needs some refinement. Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). The way I've seen it implemented at a small company I worked at before was to explicitly endorse the "20% time" idea that Google made famous, where you may choose your own priorities for a fractio…
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#86Orientation in EXIF was an ugly hack and we're living with its fallout today. Cameras should have just rotated the actual image pixels when saving, instead of cheating. If that's too slow, implement it in hardware, or schedule a deferred process and don't let the images be exported until that's done.
> Orientation in EXIF was an ugly hack and we're living with its fallout today. No, it was an elegant hack given all the constraints which mostly no longer exist on modern hardware (although I wouldn't be so sure about really small embedded systems). Sure, modern cameras will have no issues loading the full JPEG into memory, but how would you have implemented this in cameras that only have enough for exactly one line…
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#87As 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 almos…
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#88Earlier quoted context omitted.
> 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.
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.
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#89As 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 almos…
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 doub…
Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image
#90Earlier quoted context omitted.
The advantage of the EXIF approach is you don't have to do nearly as much post processing of the data? In particular, I don't expect my camera application to need to change memory layout just because I have rotated my camera. So, if you want it to change the rows/columns on saving the image, that has to be post capture from the sensor. Right? I think this is what you meant by "some systems" there. But, I would expect…
The transpose is absolutely trivial compared to debayering and compression. It's a lot simpler to do it upfront and not worry about rotation at any later point. And the odds are very high your camera app did already switch memory layouts when you rotated, at least for the UI. Doing that isn't a big deal.
Do you expect the same when recording video if the user rotates the device while recording? Timestamping an orientation flag is trivial. Why not lean on that?