CSS Image Orientation Lands in Firefox 26 | Hacker News Reader

CSS Image Orientation Lands in Firefox 26

sethfowler.org

51 pointsswift29 comments

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.

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.

That's true, but how many cameras produce photos with dimensions that are non-multiples of 8?

There are no cropped images on the internet?

Once an image is cropped it's not going to be losslessly saved. You can crop images in some cameras, but I suspect they maintain multiples of 8.

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...

> Why can't whatever software writing those tags just rotate the JPEG blocks instead?

Because that would make the camera cpu subsystem $0.50 more expensive.

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.

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.

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

    *{ image-orientation: from-image }

to your CSS file to apply it everywhere.

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?

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?

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.

In the case where you view a direct link to the image, Safari, Chrome, and now Firefox will all display them with the EXIF orientation respected.

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.

Uhmm, all the images are oriented right in Safari on my iPad.

You mean correctly?

Yes, sorry about the ambiguity.

But not Safari on the desktop.

So, what's your issue?

from what i can see, both chrome and safari respect the rotation data.

Only on the iPad, where they're both using Apple's iPad version of WebKit.

This isn't standards-compliant behavior. I had no idea that there were any browsers that actually did this!

And iPhone.

Will this be misused. Will sites have tons of rotating images. The new blink?

Rotating images were already possible before with transform:rotate().

Reply on news.ycombinator.com