Last modified: 2014-11-19 10:31:02 UTC
See https://commons.wikimedia.org/wiki/File:%22The_Car_Wash%22_Fountain,_Portland,_Oregon_%282013%29_-_1.jpg : if you click on Expand View, the image will appear rotated left - 90° degrees.
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...
