One of the long-awaited minor features that has finally come in during the
1.18 development cycle is resolving old bug 6672, natively supporting photos
where EXIF metadata specifies a non-default orientation.
This is very common in photos taken with digital cameras; a portrait-mode
image may be saved at the low-level as a 4x3 framebuffer with an orientation
tag stating it must be rotated 90 or 270 degrees (or occasionally an
upside-down photo needing to be rotated 180 :) While most photo-editing
applications understand this metadata natively and will simply show the
image at its natural size, web browsers don't -- and neither did the
server-side processing that MediaWiki was doing.
Bryan Tong-Minh did most of the earlier work on this a few months ago, which
is much to be commended!
In response to a couple issues noticed on
test2.wikipedia.org (bug 31024,
bug 31048) I've made some tweaks to make it work more consistently. From now
on the image's width & height properties will be set to the logical size,
taking the orientation into account. This makes thumbnail resizing more
consistent (sometimes we got wrong sizes because the requested bounding box
would end up applied to the original physical size) and also makes the
orientation change transparent to API clients, such as other wikis using
ForeignAPIRepo (aka 'InstantCommons'). Clients won't need to know or care if
an image uses EXIF rotation; it'll simply always be presented and reported
as at its natural logical size.
I've applied these fixes to trunk, REL1_18, and 1.18wmf1 -- phpunit test
cases have been updated, but it's still conceivable something could be wrong
so please do test. :)
Note that any exif-rotated photos you've uploaded under the old code will
need to be purged to update their file metadata & clear out any old thumbs,
or they'll continue to possibly render wrong.
https://bugzilla.wikimedia.org/show_bug.cgi?id=6672
https://bugzilla.wikimedia.org/show_bug.cgi?id=31024
https://bugzilla.wikimedia.org/show_bug.cgi?id=31048
-- brion