Confirmed in latest Firefox.

Basically the browser respects the EXIF rotation when opening the image directly, but when loading it through Media Viewer (by assigning it to an <img> element's src), the rotation isn't applied. The solution is probably to read the EXIF data in JS and apply the rotation/flip accordingly. This is quite a big undertaking as many things can go wrong (fullscreen mode, resizing/bucket logic, etc.).

It shouldn't be necessary to handle this manually, as MediaWiki's thumbnailing and image display infrastructure already knows that images requiring rotation have to be thumbnailed for all on-wiki display... If we're asking for a thumbnail of a given size via API imageinfo we *should* receive a rotated one, even if we asked for the original size.

Is something in MMV trying to do an optimization by preemptively loading the raw original source image instead of asking for a thumbnail maybe?

(In reply to Brion Vibber from comment #2)

Is something in MMV trying to do an optimization by preemptively loading the
raw original source image instead of asking for a thumbnail maybe?

Yes, that is the case. Possible fixes:

• just disable thumbnail guessing and rely on the API instead (costs around 250ms for the median user - http://multimedia-metrics.wmflabs.org/dashboards/mmv#overall_network_performance-graphs-tab )
• thumbnail all files all the time (slightly more thumbnail misses, plus needs a core patch - right now if try to request a thumbnail with the same size as the original, you get a HTTP 500)
• flag images needing rotation in HTML, the same way we pass the full size

(In reply to Tisza Gergő from comment #3)

• flag images needing rotation in HTML, the same way we pass the full size

This might be easiest without introducing more API round-trips -- from PHP side I think you can check the $file->mustRender() (or $file->getHandler()->mustRender()? ehhh something) method which should tell you to use a thumbnail even for the original size, and set a flag in the output.

I'm more in favor of the ability to request thumbnails that are the same size as the original. Clearly thumbnail != original even at the same size because of the rotation alone,thus this defensive existing limitation has no reason to exist.

I suppose tho goal was to save storage space when the thumbnail and the original would be exactly the same. It makes the URL-as-API behavior of the 404 thumbnail handler very unpredictable, though.

I think the nice behavior would be to return a 301 to the original image in such cases; that is cached in varnish and on the client so the performance hit would be minimal.

(In reply to Tisza Gergő from comment #6)

I suppose tho goal was to save storage space when the thumbnail and the
original would be exactly the same. It makes the URL-as-API behavior of the
404 thumbnail handler very unpredictable, though.

I think the nice behavior would be to return a 301 to the original image in
such cases; that is cached in varnish and on the client so the performance
hit would be minimal.

I like it... but maybe use a 302 (moved temporary) as the image may change from one that's not EXIF-rotated to one that is or vice-versa. Eeek...

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Are there any temporary workarounds? Willing to monkeypatch as heavy as needed....

You could change override TransformationalImageHandler::mustRender to always return true (that will enable generation of thumbnails with the exact same size as the image; normally you would get an error unless rendering is actually needed to hardcode the rotation), and change mmv.provider.GuessedThumbnailInfo.needsOriginal to use > instead of >=. No guarantees :)

That said, you should not have this problem at all if you don't use thumbnail URL guessing. See Extension:MultimediaViewer#Configuration.

Is that the behavior seen here?

https://en.wikipedia.org/wiki/Deep_Roy#/media/File:Deep_Roy_2014.jpg

If not I"ll file another bug report, but I can't quite discern whether this is the same issue, or a discrete one.

Yes, it is the same issue.

Issue in Chrome as well (but not when browser is resized)

This is still an issue, showing up again with this image.

And still, now here.

In T70320#5249102, @Tacsipacsi wrote:

And still, now here.

This seems to be something else, like T38380, specific to 800px thumbnail that MediaViewer uses at certain browser size. For me this thumbnail is incorrectly rotated also when opened directly and when displayed on wiki page.

But for other examples the issue is still there.