I never understood why the EXIF rotation tag was invented. It's caused so much pain and wrongly rotated images. Why can't whatever software writing those tags just rotate the JPEG blocks instead? "jpegtran" can losslessly rotate and flip JPEG images fine.
EXIF rotation tags exists because it was way more simple for camera manufacturer than actually move the pixels around depending on orientation sensor on camera.
That said, what I don't understand myself is software devs that thinks it's ok to rotate the pixels and saving the image with EXIF tags without updating the rotation one.
> what I don't understand myself is software devs that thinks it's ok to ...
Most people, including software developers, think of JPEG as just a bunch of pixels.
I think if you were to do a random survey of software developers, most wouldn't know that the rotation field exists, and an appalling percentage wouldn't even know that EXIF exists.
Now that I think about it, I wonder what percentage would know that JPEG is a compressed format, let alone the fact that it's lossy...
The theory is that the rotation info is metadata, taken from a separate sensor on the camera, so it should go in the metadata format which is EXIF, just like the timestamp/ISO/focal length.
My understanding is that you can't perform lossless rotation on a jpeg unless it's dimensions are a multiple of 8. I'm not 100% sure about this so I'm happy to be corrected.
What's the technical reason that Firefox (and presumably other browsers) can't just read the JPEG EXIF data to obtain the proper orientation?
This CSS tag could still be marginally useful: you could store only one corner and one side of a custom border, and flip the image for the other three. Once the tag is ubiquitous, of course.
> What's the technical reason that Firefox (and presumably other browsers) can't just read the JPEG EXIF data to obtain the proper orientation?
It's what `image-orientation: from-image` does.
But it can't be done automatically (you have to explicitly use this property), that would break the web: until now, images were not rotated automatically, so developers might have rotated their images in CSS (`transform:rotate(90deg)`). If Firefox were to rotate automatically the images according to the exif data, you'd get a double rotation, or unexpected image rotations.
It's also not uncommon to have images which were rotated by software which did not follow the EXIF orientation tag but did pass the EXIF data through unmodified, which means that the image looked correct when someone saved it, uploaded it and previewed the page and until, possibly years later, when Firefox “broke” it.
Ah, thank you. So it was a mistake to not initially honor the EXIF data, but it's so ingrained now that fixing it might 'break' existing images on the web.
It's a shame backward compatibility has to be so rigid. It's hard to imagine there being that many sites out there using manually rotated (or transform: rotated) images with EXIF data that would cause a double rotation. But at least I understand the rationale behind the tag now. Of course, the unfortunate irony is that with so little browser support, this CSS rule is likely to end up causing incompatibility between browsers anyway, at least for the next few years.
but what happens when you view a direct link to an image? imo, the rotation data like that should be associated with the file, and respected all the time. it might break a few things, but i'm fairly certain people could figure out the fix required :)
The point is that if you fix it in new browsers, you'll break it in old browsers, and vice-versa. Adding an "opt-in" for the new (correct) way of doing things lets you serve the old client-side rotation logic to the old browsers, and the CSS pragma to the new browsers.
If people took the time to build a custom solution using CSS/js to display the images, why not just pre-process them instead? IMO respecting the orientation tag by default wouldn't be unexpected at all.
Btw, images are oriented correctly on Mobile Safari.
Much like the CSS border-box box sizing property makes a lot more sense, it would still cause issues if the browser changed behaviour. However, if it's your site, it's as simple as adding
I don't think that's a fair parallel. Box models are different standards, whereas displaying an image in the wrong orientation is just wrong. A better comparison would be the <audio> tag playing everything at 22khz, then requiring { sampling-rate: from-audio } to work correctly.
I haven't seen any examples of a website implementing custom rotation using css or canvas, it wasn't even possible to read EXIF data on the client until a year or so. Is it a real concern?
I know having a wildcard the end of a rule is non-performant ("ul > " for example has to check the parent of every* element to see if is a UL element; or even worse, "ul *" would have to check the entire ancestor tree of every element). Is there a performance impact of applying that rule to every element?
