UIImageOrientation incorrect for left/right from loaded UIImage?
Asked Answered
G

3

6

I am loading JPGs that are flagged with arbitrary EXIF orientation data (one of 8 orientations). I downloaded the eight sample image files from here (linked from this blog post).

Image 8 represents EXIF tag 8, which is a 90 degree clockwise rotation. This can be confirmed by looking at this image in a dumb viewer, like Paintbrush.

However, when I load it in a UIImage in my iOS project, and call -imageOrientation on it, I get UIImageOrientationLeft. According to the docs here,

UIImageOrientationLeft

The image is rotated 90 degrees counterclockwise, as shown here.

...which is not what the underlying image looks like.

The opposite is true of EXIF orientation 6, which I expect to show up as Left, but which appears as Right.

Are the docs wrong here? Am I missing something obvious? Thanks.

Garges answered 26/8, 2011 at 19:34 Comment(0)
B
8

I had the same problem for a while. It seems that the UIImageOrientation documentation describes what happens to an upright image if you apply the specified orientation. For example, if you take an upright image and apply UIImageOrientationLeft, it will come out rotated counterclockwise by 90°.

The exif documentation, on the other hand, describes what the orientation of the image data is to generate an upright image. So for EXIF code 8, the image data must be rotated 90° clockwise to result in an upright image display.

It turns out that only UIImageOrientationLeft and UIImageOrientationRight have this problem, as all the rest come out the same either way you look at it.

Braunite answered 29/8, 2011 at 23:3 Comment(3)
Good thinking, but I'm still fuzzy on this detail. I guess if I read the docs for UIImageOrientationLeft as "The image needs to be drawn 90 degrees counterclockwise", then it does make sense. This really seems to be the counterintuitive way to read it though-- the wording implies that this property reflects its current state, not an implied action. Am I getting you though? (Your first note about applying an orientation doesn't parse for me-- I don't know how you can "apply" an explicit orientation with UIKit-- it's a readonly property on the image)Garges
@quixoto: By "apply an orientation" I mean taking a CGImage and doing [UIImage imageWithCGImage:cgimageref scale:0 orientation:applyOrientation]. If you take an upright CGImage, that would give the results as shown in Apple's documentation. The other way of thinking about it is to ask what the state of the CGImage needs to be in order to give an upright image as the result.Braunite
I didn't know about that method, and you're right about how it behaves-- this is the only sensible explanation I've heard for this behavior (awarding you the bounty), although if this is the only explanation, I think the docs aren't very clear-- the distinction is quite subtle, and prior to iOS 4.0, this method didn't even exist for comparison's sake. Thanks for the responses.Garges
R
1

I think the issue lies in the origin point (where the rotation is applied). When using an UIImage, the origin is located at top left corner, and when using a CGImage, the origin is at bottom left corner.

Retardment answered 4/9, 2011 at 6:27 Comment(2)
This could be related to it; CoreGraphics essentially still treats the origin as the lower left, as evidenced when you try to draw with, say, CoreText and end up with upside down text. So the standard UIKit to CoreGraphics translation is to invert, which would turn a clockwise rotation into an anticlockwise rotationConservation
This is a true fact, but seems to sidestep the evidence here. CoreGraphics doesn't need to be involved at all to demonstrate this, and the docs are very clear on what UIImageOrientationLeft should look like, and linked above is a counterexample. I think @Anomie's answer (a subtle reparsing of the docs) is more likely to be the explanation.Garges
J
0

I found an interesting answer to this: http://blog.logichigh.com/2008/06/05/uiimage-fix/

Junta answered 5/9, 2011 at 8:23 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.