AutoRotation based on EXIF information

Actually, I heard about this being done just recently.
I've been getting deep deep into EXIF and metadata, extracting info that then gets exposed or becomes a parameter on the imagecache process (mostly intextactions - to label them with captions and stuff)

BUT ... I have not yet seen what this rotation tag might be, and what it looks like. Basically my camera doesn't do that, so I'm in the dark about what this is supposed to work like.
Any hints?

My previous work with metadata from images
Code is in my sandbox

... currently tuned towards adding text from metadata fields, but if you paste up one of those images you describe, I'll see if we can find and expose the value.

jonathan_hunt said he had an implementation of this task last month. I didn't take him up on it at the time...

TagName Orientation - OK, THAT is a useful reference.
I know that site - strange that it's the only/best EXIF reference out. Bloody intimidating list of random crap from various manufacturers!

Dammit. My meta_inspector can see the value, but something internal (PHP - exif function?) is already translating it to English.
Scanning the node for meta fields I get:

Orientation (Array, 1 element)
      exif:0 (String, 128 characters ) 
            No Flip, Rotated 90 degrees clockwise (Row 0 is at the visual right-hand side of of the image, and column 0 is the visual top)

... which is correct, but I'd rather trust the constant...

... Ah, It's my code, I've got the choice available to me... Hm, how to expose both? I'll see...

FYI, here's the code I have. It might be a useful starting point. It only works on JPEGs for now. It's sufficient for my purposes; I'm using it to autorotate photographs submitted by iPhone and Android to FixMyStreet.org.nz

Thanks Jonathan, that looks WONDERFULLY simple.
And it's just sweet as a standalone one-action module.
I might just add a paragraph of documentation, but I'd be happy to roll that into the distro if that's OK with you?

Actually, on test, that code turned that sample image upside-down!
So it's TRYING ... but I need to review those constants ;-)

Doh, I haven't seen that happen. Can you share the test image?

That one in this issue: http://moover.co.uk/irvinestown/P1020148.JPG
I don't HAVE any others with that info embedded :0)
edit --- Damn, the sample has gone away.
edit --- damn, I can't edit my local copy of that sample down to a decent size WITHOUT it autocorrecting the orientation in PS, FW, Gimp, Xee .... Maybe I'll try imagemagick

this one went through. Same EXIF tags as the orig

Cool I'm seeing what I should see.
Screenshot shows teasers containing a normal thumbnail, and an embedded, autorotated (scaled) imagecache version of the same.

I've committed that to CVS then, please try it out.
Because I've had to swap the rotate-left, rotate-right behaviour from jonathans original (to get the correct result above), I'm harbouring doubts that some cameras may disagree about rotation - does "rotated clcokwise" mean the camera or the image went clockwise? :-)

It's an action you can turn on.

visit admin - modules.
enable 'imagecache autorotate'
visit or create an imagecache preset
enable 'autorotate' as an action in that preset

imagecache_actions is a collection of smaller modules. "Imagecache Autorotate" needs to be turned on explicitly.
It's possible that imagecache is caching things too hard again. :(
Yeah, could be. OK, for no good reason ...
1. disable canvasactions, or an existing unused actions module.
2. uninstall it! using admin/build/modules/uninstall (don't delete anything)
3. enable it again.

That should have fooled imagecache enough.

I'm rolling in a hard cache-flush to the module install function now. imagecache is annoying that way.

Because it's such a rare case, and because conceptually I don't really know where to put it, and because jonathan_hunt supplied it as a tiny, working, stand-alone optional module ... it's on its own for now.
I don't want to proliferate small modules too much, but OTOH, it's unlikely that any sane site would want more than two or three effects in effect at once, so I don't want to bulk out the extras either. Not sure where to draw the line, but in the meantime, smaller and modular is easier to keep track of changes in :-)

FYI, I was just reading National Information Standards Organization (NISO) Z39.87 ^{Technical Metadata for Digital Still Images} for fun*.
And found a fuller description on page 70:

orientation
Definition a data element that designates the orientation of the image, with respect to the placement of its rows (7.1.1 imageWidth) and columns (7.1.2 imageHeight), as it was saved to disk
Type enumerated type (restricted to list)
Obligation R
Repeatable N

Values
1 = normal*
2 = normal, image flipped
3 = normal, rotated 180°
4 = normal, image flipped, rotated 180°
5 = normal, image flipped, rotated cw 90°
6 = normal, rotated ccw 90°
7 = normal, image flipped, rotated ccw 90°
8 = normal, rotated cw 90°
9 = unknown
NOTE: “cw” = clockwise; “ccw”= counterclockwise

Notes Values for this field are drawn from terminology from common image processing software. Definitions are as follows:
“Normal” is defined as follows: when opened, the top (0th) row of pixels corresponds to the visual top of the image and the first (0th) column of pixels on left corresponds to the visual left-hand side of the image.
“Image Flipped” is defined as the mirror image of “normal.” (Some software tools call this “image flipped horizontal.”
This field is to be used to record only the orientation value of the stored image, not the orientation of the source to the device (e.g., camera) at the time of capture, or the correct orientation for rendering the image to a display device.

I interpret "the orientation value of the stored image" and "6 = normal, rotated ccw 90° " to mean the image is currently 90° ccw and to transform it for accurate display, we must turn it back 90° cw
Which is what the code I modified currently does

    switch($exif['Orientation']) {
      case 3:
        $degrees = 180;
        break;
      case 6:
        $degrees = 90; // Rotate 90 CW
        break;
      case 8:
        $degrees = 270;  // Rotate 270 CW
        break;
      default:
        $degrees = 0;
    }
    if ($degrees) {
      imageapi_image_rotate($image, $degrees);
    }

I think we are right.
I'm a little concerned that that wasn't the case with the version that was working for jonathan, so I won't stake my life on it, but I'll bet 5:1 odds.

* - Actually I was reading up on Library of Congress MARC Data Schemes and that 171-page document on image encodings was comparatively light reading!

subscribe

Hello,
I just tested the module "as is", with four photos I just shot.
My explorer rotates them correctly (although it seems my camera doesn't handle upside down shooting...), so I suppose the EXIF data is OK.
When I upload my photo, here are the debugging messages I can get :
imagecache_autorotate_image: exif[Orientation]=8
imagecache_autorotate_image: rotating degrees=270
for the first and
imagecache_autorotate_image: exif[Orientation]=6
imagecache_autorotate_image: rotating degrees=90
So, by checking there, I conclude that imagecache_autorotate did its job...

BUT !
These two images are upside down, as if they were rotated counter clock wise...
I am using ImageAPI GD, have just one preset, containing Autorotate only.
Does anyone know what could be my problem ?

Thanks,

David

Okay, I just found that imageapi_gd_image_rotate() does this call:
$image->resource = imagerotate($image->resource, 360 - $degrees, $background);

Why does it use 360 - $degrees ? I don't know, but if I but $degrees instead, it works...

Edit : OK, my issue seems related to #373631: gd_rotate() rotate wrong way for 90° and 270°

closing, based on the conclusion found in #373631: gd_rotate() rotate wrong way for 90° and 270°#13
- Status page reported gd does not support rotation.
Odd that this means it does, but brokenly

status

Hello,
Actually, this issue concerns the implementation of autorotation.
Shouldn't you wait a stable release to close this issue ?

Thanks,

David