Last modified: 2014-11-19 10:31:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T70320, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 68320 - Media Viewer ignores EXIF rotation
Media Viewer ignores EXIF rotation
Status: ASSIGNED
Product: MediaWiki extensions
Classification: Unclassified
MultimediaViewer (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 31504
  Show dependency treegraph
 
Reported: 2014-07-21 13:07 UTC by Elitre
Modified: 2014-11-19 10:31 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Elitre 2014-07-21 13:07:24 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.
Comment 1 Gilles Dubuc 2014-07-21 13:34:19 UTC
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.).
Comment 2 Brion Vibber 2014-07-21 18:04:56 UTC
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?
Comment 3 Tisza Gergő 2014-07-21 18:21:12 UTC
(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
Comment 4 Brion Vibber 2014-07-21 19:52:03 UTC
(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.
Comment 5 Gilles Dubuc 2014-07-22 12:22:05 UTC
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.
Comment 6 Tisza Gergő 2014-07-22 19:18:41 UTC
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.
Comment 7 Brion Vibber 2014-07-23 22:31:01 UTC
(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...

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links