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