Support EXIF Orientation tag for WebP images
Categories
(Core :: Graphics: ImageLib, enhancement, P3)
Tracking
()
People
(Reporter: 0339af4b49c8342a41f113ee151651fe, Assigned: aosmond)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
I have a number of WebP images with their EXIF Orientation tag set, and displayed each on a page.
Actual results:
Each image is displayed as if their EXIF orientation is ignored
Expected results:
The displayed images should be oriented depending on its value.
JPEG images seem to get their correct orientation, as do the newer AVIF file format. However, WebP doel look broken.
Here's a few tickets in relation to this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=298619
https://bugzilla.mozilla.org/show_bug.cgi?id=1627423
https://bugzilla.mozilla.org/show_bug.cgi?id=976397
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::ImageLib' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 2•3 years ago
|
||
This is true. It shouldn't be hard to add it in though. Let me try.
I knows it only been six months compared to the fifteen years it took to originally implement this, so my expectations are low, but has there been any progress on this? I've been doing a lot of .webp work lately and ran into this issue.
|
||
Comment 4•2 years ago
|
||
With https://github.com/w3c/csswg-drafts/issues/4929 resolved we are not not supposed to respect exif if it comes after the image data in an image file. From here https://developers.google.com/speed/webp/docs/riff_container#extended_file_format it looks like the exif data comes after the image data in webp files, so we are supposed to ignore it. And this is what Chrome does too. That would make this wontfix.
The spec says "should not", that sounds like exceptions can be made for image formats that are /required/ to put the data at the end of the file. It sounds like the spec was specifically created for images that have flexibility in exif placement not ones that are required to be in a specific location.
I didn't include a link, but here it is. It explicitly calls out file formats that have flexible metadata location.
|
|
||
Comment 7•2 years ago
|
||
(In reply to sdaniele3 from comment #6)
I didn't include a link, but here it is. It explicitly calls out file formats that have flexible metadata location.
If the spec was intending to carve out different behaviour for file formats where the metadata can move around vs ones where the metadata can not move around then it is leaving a lot undefined. My reading is that the text applies to all image formats, and the mentions about formats where metadata can move around is explanatory text, not spec text.
You can ask them to clarify the spec text if you think.
Maybe I wasn't clear.
User agents SHOULD ignore any layout-impacting metadata (such as orientation or resolution) that occurs after the image data begins in the file.
This /does not/ restrict Firefox from implementing orientation on webp. Should != Must.
https://datatracker.ietf.org/doc/html/rfc2119
I did create an issue on the CSS spec anyway.
https://github.com/w3c/csswg-drafts/issues/8543
|
|
||
Comment 9•2 years ago
•
|
||
(In reply to sdaniele3 from comment #8)
Maybe I wasn't clear.
User agents SHOULD ignore any layout-impacting metadata (such as orientation or resolution) that occurs after the image data begins in the file.
This /does not/ restrict Firefox from implementing orientation on webp. Should != Must.
I understood. However, it is a very high bar to make a case to go against a spec saying we should do something, especially if (as in this case) other browsers follow the spec recommendation, and Firefox also currently follows the spec recommendation.
|
||
Comment 10•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #9)
I understood. However, it is a very high bar to make a case to go against a spec saying we should do something, especially if (as in this case) other browsers follow the spec recommendation, and Firefox also currently follows the spec recommendation.
Thank you. That's a much clearer picture than arguing semantics of the spec.
Description
•