Automatic photo orientation in MediaWiki 1.18

We’re in the process of upgrading Wikimedia sites to the about-to-be-released MediaWiki 1.18. So what’s actually new in it?

One of my favorite little improvements is automatic EXIF orientation support for images. Lots of digital cameras and mobile phones handle portrait-mode photographs by saving them as if they were in landscape mode, and marking the file with an orientation tag based on accelerometer data in the device (“oh you were holding the camera sideways? I knew that!”)

Bryan Tong-Minh did most of the work on this a few months ago, and I made a few tweaks recently to make it work a little more consistently. But what does it mean in practice?

Let’s try an example — I took a portrait photo of my coffee mug (mmmm) using my Canon PowerShot and uploaded it to test2.wikipedia.org.

If you load up the raw original image in your browser you’ll find that it looks sideways like this:

Poop! Nobody wants sideways coffee, it’ll just spill all over that shiny laptop.

It used to be that your image would end up looking like this when you uploaded it directly into MediaWiki, but no more!

Now whenever MediaWiki deals with it, it’s automatically rotated to its proper orientation, just like if you loaded it into Gimp or Shotwell (or Photoshop or iPhoto, if you swing that way!)

When this support goes live on Wikimedia Commons, it’ll be a nice help for people uploading camera-original images, as it will no longer be necessary to manually fix the rotation of your photos. (If you’ve edited the photo, _usually_ the rotation gets fixed then.)

Particularly when we look into the near-to-medium future with things like direct photo upload support from mobile devices, and more on-web editing, we can expect to see a lot more camera-original photos going into the system.

 

10 thoughts on “Automatic photo orientation in MediaWiki 1.18”

  1. Nice! Will the ability for users to manually re-orient photos be there as well (without downloading, editing and reuploading)? I can imagine there will be a fair few times when the automatic tag leads to the wrong orientation, and of course it’d just be handy to be able to do that basic kind of image manipulation on-wiki.

  2. You sir, win the QOTD award for: “Poop! Nobody wants sideways coffee, it’ll just spill all over that shiny laptop.”

  3. Can an editor re-orient an already-uploaded image without having to re-upload? That alone would have saved me much annoyance from different computers being “helpful” to different degrees.

  4. It’s not in there yet, but it should be possible. One trick is that we’d basically have to change the width/height to match the updated orientation (though it’s conceivable we can find a nice way to kick that comparison up a level).

    Right now when making thumbnails with ImageMagick we use the ‘-auto-orient’ option to do the rotation on output (when scaling with GD or client-side during upload we manually apply the rotation from the exif data)… probably switching that to a manual rotation amount would let us override that with a custom rotation offset.

    Doing rotation (and cropping, and other manipulations) by actually saving new versions of the file is also a possibility that handily sidesteps the need to complicate the rendering. :) And since that’s basically what’s needed to make editable diagrams, I want to make that happen somewhere in the next couple versions anyway. (For SVG graphics, the SVGEdit extension/gadget provides a similar editing environment that saves a whole file back.)

  5. (and yes for things like rotation or cropping that could be done without having to download and upload the file — the server-side code can do it and just save the new version right in)

  6. David: basic image editing functions like rotation and cropping have been on my wishlist for aaaages. It’s unlikely though that I will have time to write such a feature… I even need other people to fix my fixmes, so unless somebody else has interest in it, it is not going to happen soon.

  7. David Gerard: on Commons, you can add {{rotate|90}}, {{rotate|180}} or {{rotate|270}} and a bot (Rotatebot) rotates all the images with the templates on every few hours.

  8. Is the rotation performed by generic image-processing functions (e.g. ImageMagick or PHP GD), or by lossless JPEG editors (e.g. exiftran, jpegtran)?

    Rotating JPEGs without using a lossless editor is subject to potential quality losses. While most editors might not mind, there are cases where the quality differences could matter (digital watermark, images demonstrating steganography, images with very high frequency components, etc.). Thus, I’m wondering if the rotation is performed losslessly.

  9. Generic — but in the vast majority of cases you’re already scaling down, so by rotating before recompression you haven’t lost anything — you only would on a full-size image, which will very rarely be viewed for digital camera-sized images.

Comments are closed.