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.
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...".
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.
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.
Browsers starting to rotate images based on EXIF is such a pain. I maintain an image annotation tool and all of a sudden images were shown differently to users depending on the browser they used. Then you have to jump through all sorts of hoops to ignore the EXIF orientation again. In some cases you are not allowed to see if the orientation was changed for security reasons. And then the only way to control this is through a CSS attribute which only works if the element is in the DOM.
The amount of time I've spent dealing with this over the years is just incredible.. It's gotten to the point where during ingestion we auto-rotate everything just in case and strip out exif orientation metadata and never have to deal with it again.
Yes. I wrote a little image uploader script to easily upload images from my phone for embedding in web forums etc, and it strips out all the EXIF orientation and just converts it to the correct orientation. Aside from that I'm always having to fiddle with it in my image tools and hope every software I use supports it. It's such a crap feature. Just rotate the damn image, phones!
Isn't it a touch on the required side, though? I'm assuming the orientation is a common metadata element of phone produced images, in particular. I'd assume same for decent cameras.
Would love to see a good rundown of when you should rely on different approaches? Another thread pointed out that you should also use the color space metadata.
> Further findings: neither Safari, Chrome, or Firefox respects exiftool's default output, which appends EXIF to the end of a PNG.
Makes sense. I have to imagine there is a performance impact to waiting until you've downloaded the entire image _just in case_ there's some metadata telling you to rotate it right at the end of the stream.
Interesting. I was not aware that was a thing. Orientation info seems way less useful in a lossless format like PNG. It makes sense in JPEG for instance because rotating and re-encoding would be lossy and slightly degrade the image.
It's hella useful when the encoder doesn't have the RAM to hold the entire image. But this is a pretty rare case.
JPEG rotation only has to be lossy when the image is not evenly divisible into macro blocks - rather than transcoding just rotate the macro blocks, and where they're placed.
The image could have been encoded with a high compression ratio, or even something like OxiPNG. In that case, while re-encoding it wouldn't lose quality, it could still have the side-effect of making the file bigger.
The orientation data is defined as part of Exif. Both JPEG and PNG has officially supported ways of embedding Exif data. It's not defined specifically for PNG, but you would expect the Exif tag to work the same way regardless of image data format.
Orientation 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's worth of compression blocks?
> or schedule a deferred process and don't let the images be exported until that's done.
Good luck doing this on a battery-powered camera writing directly to an SD card that's expected to be mountable after removing it from the camera without an intransparent postprocessing step.
> 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.
What if I want to rotate an image by 90 degrees because my camera didn't correctly detect up & down?
To my understanding rotation is lossless, where as moving the data will incur quality loss (except for certain exceptions).
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 important to document.
An example I recently encountered is that in neurological imaging, the axes are patient's right, anterior, superior whereas in radiology they are patient's left, anterior superior. Tricky to get right...
I personally like the status quo that PNGs don't encode orientation. I can dump PNGs when I'm debugging and I know I'm looking at the bits the same way up as the code is!
PNG now does - and they've been as vague as they could be in the spec about whether any exif data should affect the image display or not. The spec says:
"It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only."
Instead of either saying: "yes you must rotate it" or "no you shall not rotate it" to make everyone do the same thing. And if it were yes, they should also have made this a mandatory chunk since now they made it optional to read.
EXIF orientation has always been a massive pain to deal with. Specially with HEIC that keeps getting updated libheifs and causing all sorts of compatibility issues.
See also: The VLC bug that incorrectly applies right crops as left crops [1]. This bug report is from 2023, however the bug has existed as long as VLC has as far as I know.
I'm always surprised to see bugs like this where an extremely easy to test part of the spec just seemingly isn't tested and ends up as a bug that never gets fixed until many years later.
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.
When it got fixed, some sites were still depending on the old behavior of not rotating JPEGs, and had to add "image-orientation:none" to explicitly ignore EXIF:
I once had to deal with an old website that ignored the orientation flag in jpg, so my iPhone portrait photos showed up landscape when I uploaded them.
Thankfully Finder in macOS has a way to remove the flag:
> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
Someone probably thought it was interesting, and based on the fact it's on the front page and receiving comments, at least some other people agree.
[+] [-] postalcoder|4 months ago|reply
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.
[+] [-] netsharc|4 months ago|reply
So yeah, I think "Stripping all EXIF metadata doesn't change an image" deserves an entry as a "falsehood programmers believe about...".
[+] [-] ziml77|4 months ago|reply
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.
[+] [-] foobarian|4 months ago|reply
[+] [-] concinds|4 months ago|reply
I wish they open-sourced their built-in macOS apps.
[+] [-] pyuser583|4 months ago|reply
[+] [-] mzur|4 months ago|reply
[+] [-] Linkd|4 months ago|reply
[+] [-] coldpie|4 months ago|reply
[+] [-] bastawhiz|4 months ago|reply
This is only true for cross-origin images, no? Which is expected: you can't access data loaded from another origin unless it's been loaded with CORS.
[+] [-] taeric|4 months ago|reply
Would love to see a good rundown of when you should rely on different approaches? Another thread pointed out that you should also use the color space metadata.
[+] [-] stackedinserter|4 months ago|reply
It's shame that after so many years of development we ended up with such horrible formats like jpeg and mp4.
[+] [-] afavour|4 months ago|reply
Makes sense. I have to imagine there is a performance impact to waiting until you've downloaded the entire image _just in case_ there's some metadata telling you to rotate it right at the end of the stream.
[+] [-] donatj|4 months ago|reply
[+] [-] bobmcnamara|4 months ago|reply
JPEG rotation only has to be lossy when the image is not evenly divisible into macro blocks - rather than transcoding just rotate the macro blocks, and where they're placed.
[+] [-] MontagFTB|4 months ago|reply
[+] [-] mavhc|4 months ago|reply
https://www.betterjpeg.com/lossless-rotation.htm
[+] [-] PaoloBarbolini|4 months ago|reply
[+] [-] poizan42|4 months ago|reply
[+] [-] gpvos|4 months ago|reply
[+] [-] t1234s|4 months ago|reply
[+] [-] rkagerer|4 months ago|reply
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.
[+] [-] lxgr|4 months ago|reply
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's worth of compression blocks?
> or schedule a deferred process and don't let the images be exported until that's done.
Good luck doing this on a battery-powered camera writing directly to an SD card that's expected to be mountable after removing it from the camera without an intransparent postprocessing step.
[+] [-] OptionOfT|4 months ago|reply
What if I want to rotate an image by 90 degrees because my camera didn't correctly detect up & down?
To my understanding rotation is lossless, where as moving the data will incur quality loss (except for certain exceptions).
[+] [-] tehjoker|4 months ago|reply
It's true that automatic handling of all input images is difficult, but imo it's important to document.
An example I recently encountered is that in neurological imaging, the axes are patient's right, anterior, superior whereas in radiology they are patient's left, anterior superior. Tricky to get right...
http://www.grahamwideman.com/gw/brain/orientation/orientterm...
[+] [-] alexdbird|4 months ago|reply
[+] [-] Aardwolf|4 months ago|reply
"It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only."
Instead of either saying: "yes you must rotate it" or "no you shall not rotate it" to make everyone do the same thing. And if it were yes, they should also have made this a mandatory chunk since now they made it optional to read.
[+] [-] Linkd|4 months ago|reply
[+] [-] LiamPowell|4 months ago|reply
I'm always surprised to see bugs like this where an extremely easy to test part of the spec just seemingly isn't tested and ends up as a bug that never gets fixed until many years later.
[0]: https://code.videolan.org/videolan/vlc/-/issues/28279
[+] [-] moron4hire|4 months ago|reply
[+] [-] pwdisswordfishy|4 months ago|reply
https://trac.ffmpeg.org/ticket/11279
https://trac.ffmpeg.org/ticket/11284
[+] [-] omoikane|4 months ago|reply
https://issues.chromium.org/issues/40448628
When it got fixed, some sites were still depending on the old behavior of not rotating JPEGs, and had to add "image-orientation:none" to explicitly ignore EXIF:
https://issues.chromium.org/issues/40716313
[+] [-] seam_carver|4 months ago|reply
Thankfully Finder in macOS has a way to remove the flag:
How to remove orientation from portrait photo from iPhone on macOS https://youtu.be/lWOlfjVyes4
I couldn’t find a way to do it in Preview, but Finder could do it.
[+] [-] pupppet|4 months ago|reply
[+] [-] teraflop|4 months ago|reply
If the EXIF data specifies a 180° rotation, then start at 0° and gradually increase the rotation by 1° per day until full spec compliance is reached.
[+] [-] malinens|4 months ago|reply
https://exiftool.org/
And it has it's own forums with tens of thousands of posts!
[+] [-] karel-3d|4 months ago|reply
Probably for WebKit and Chromium too; I have an open (silly) WebKit CSS bug for about 4 years now.
[+] [-] qwertyuiop12|4 months ago|reply
[+] [-] viraptor|4 months ago|reply
[+] [-] Barry-Perkins|4 months ago|reply
[deleted]
[+] [-] mightysashiman|4 months ago|reply
[+] [-] nkrisc|4 months ago|reply
> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
Someone probably thought it was interesting, and based on the fact it's on the front page and receiving comments, at least some other people agree.
[+] [-] tomalbrc|4 months ago|reply
[deleted]
[+] [-] jancsika|4 months ago|reply
That, or even just a small javascript interpreter in PNG would greatly improve things for a lot of my clients.
[+] [-] pimlottc|4 months ago|reply