Page MenuHomePhabricator

Media Viewer ignores EXIF rotation
Open, LowestPublic

Description

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.


Version: unspecified
Severity: normal

Details

Reference
bz68320

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 3:34 AM
bzimport added a project: MediaViewer.
bzimport set Reference to bz68320.
bzimport added a subscriber: Unknown Object (MLST).
Elitre created this task.Jul 21 2014, 1:07 PM

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

brion added a comment.Jul 21 2014, 6:04 PM

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?

Tgr added a comment.Jul 21 2014, 6:21 PM

(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
brion added a comment.Jul 21 2014, 7:52 PM

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

Tgr added a comment.Jul 22 2014, 7:18 PM

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

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 18 2015, 8:45 PM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:35 PM

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

Tgr added a comment.Jan 6 2016, 7:14 PM

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.

Tgr added a comment.May 31 2016, 8:13 AM

Yes, it is the same issue.

ovasileva lowered the priority of this task from Normal to Lowest.Nov 24 2016, 7:07 PM

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

jrbs added a subscriber: jrbs.Mar 19 2018, 5:53 PM

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

Gilles removed a subscriber: Gilles.Jun 11 2019, 10:47 AM
Tgr removed a subscriber: Tgr.Jul 9 2019, 6:05 PM