Created an attachment (id=1727) [details]
Landscape image

Created an attachment (id=1728) [details]
Portrait image

Comment 3 Andre Klapper 2009-12-11 11:54:46 UTC

That's a feature and not a bug. If there are very good reason for different
behaviour, please actually elaborate.

I can't see how this could be seen as "feature". Have you actually tried to see
these pictures?
Anyway, it would seem that the image viewer supports portrait images, but the
detection method is wrong. Adjusting summary. I made a portrait photo (see
attachment) and it's displayed correctly (another attachment). It would seem
that whether image is landscape or portrait is determined by image metadata and
not its actual dimensions. What I would expect is to determine correct
orientation based on both image dimensions and metadata (if exists).

Created an attachment (id=1730) [details]
Photo made in portrait orientation

Created an attachment (id=1731) [details]
How the photo is displayed in image viewer

Notice that the slideshow icon is on the right side, so the phone is in
portrait orientation.

Created an attachment (id=1732) [details]
How the 480x800 image is displayed in image viewer

Notice that the slideshow icon is on the right side, so the phone is in
portrait orientation.

It is obvious to me, that the image should fill the entire screen and not have
this black border.

The image in attachment 1730 [details] is actually in landscape mode, but contains an
exif tag spefifying right-top orientation.  Interesting that this works OK.

Attachment 1732 [details] shows the attachment 1728 [details] image (which *is* in portrait
orientation but contains no meta-data) has been scaled to 480x288.  After a few
more tests with images of different aspect ratios it seems the image is always
scaled to height 480 whereas it should be scaled to *width* 480.  I'm guessing
the code just uses the wrong macro somewhere, probably easyfix.

Also, when viewing such an image in portrait mode the first press of the + zoom
button flashes briefly and returns to the same scale as before (subsequent
presses work fine).  I think this is just a side-effect of this bug and doesn't
merit its own report. Zooming works fine in all other cases.

The file format is also unimportant, as the same issue occurs with exif-less
JPEGs.

Comment 9 Andre Klapper 2009-12-31 17:09:26 UTC

(In reply to comment #8)
> After a few more tests with images of different aspect ratios it seems the
> image is always scaled to height 480 whereas it should be scaled to 
> *width* 480.

This is still valid in PR1.1 I assume?

Comment 10 Andre Klapper 2009-12-31 17:11:18 UTC

There was a bug about "Transition to an image from a zoomed-in image in Full
screen mode disregards device orientation" (int-132605) that was fixed in
week43.

So far I can see only another existing bug about orientation problems when
using Sharing services.

(In reply to comment #9)
> This is still valid in PR1.1 I assume?

No, it now works as expected :-)

Fixed in 2.2009.51-1.

Comment 13 Andre Klapper 2010-01-14 21:11:49 UTC

Thanks!