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.
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.
I dont think i would. Exif contains a bunch of metadata that affect the interpretation of image data in jpegs which dont make sense for pngs. I would expect exif in png would only be for metadata meant for humans like who the author is, not things that alter the display of the image.
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.
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.
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 the tiny papercut bugs sprinkled throughout feel like they’ll never be fixed.
I love ExifTool. It’s one of the great utilities. 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 Fujifilm lens.
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.
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 fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
I do however think that there are quite a few bugs that might be triaged as "easy" but if worked on would reveal much more serious problems. Which is why some random selection of "easy" issues should make it to work queues.
> 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.
https://www.betterjpeg.com/lossless-rotation.htm
It gets even worse when ingesting images into Apple Photos, where the tiny papercut bugs sprinkled throughout feel like they’ll never be fixed.
I love ExifTool. It’s one of the great utilities. 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 Fujifilm lens.
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
https://trac.ffmpeg.org/ticket/11279
https://trac.ffmpeg.org/ticket/11284
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 fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
I do however think that there are quite a few bugs that might be triaged as "easy" but if worked on would reveal much more serious problems. Which is why some random selection of "easy" issues should make it to work queues.
> 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.