Aspect ratio incorrect for rotated images uploaded prior to 1.18 deployment
Closed, ResolvedPublic

Description

See for example http://commons.wikimedia.org/wiki/File:Vestergrave_48_%282%29.jpg . The image is rotated but it looks like the image still has the same length and width (length and with should be switched).


Version: 1.18.x
Severity: major

bzimport set Reference to bz31391.
brion added a comment.Oct 5 2011, 7:08 PM

Looks a-ok to me...

Full resolution‎ (3,456 × 5,184 pixels, file size: 5.28 MB, MIME type: image/jpeg)

3,456×5,184 (5.28 MB)

Someone just purged the page so that fixed this one.

Bryan.TongMinh wrote:

Works for me as well.

Could be that somebody purged the image. Perhaps we should find all pre-1.18 images that have exif rotation set, and purge them?

saibotrash wrote:

Yes, I did purge it. Apparently the dimensions didn't get updated. Therefore the wrong aspect ratio.

brion added a comment.Oct 5 2011, 7:27 PM

Yes, if they were uploaded prior to the 1.18 upgrade they'll need to be purged.

Could be that somebody purged the image. Perhaps we should find all pre-1.18
images that have exif rotation set, and purge them?

It's probably not all that easy to find all such images as it stands. We could do the query

select img_name from image where img_minor_mime = 'jpeg' and img_major_mime = 'image' and (img_metadata like '%s:11:"Orientation";i:8%' or img_metadata like '%s:11:"Orientation";i:3%' or img_metadata like '%s:11:"Orientation";i:6%');

But that query would take a fairly long time...

Bryan.TongMinh wrote:

Somebody can generate the list offline using the sql dumps if that takes too long.

Maybe running refreshImageMetadata.php will fix this (see bug 30961). I have no idea if that's going to be practical with the size of commons, though.

(In reply to comment #8)

Maybe running refreshImageMetadata.php will fix this (see bug 30961). I have
no idea if that's going to be practical with the size of commons, though.

That won't affect this. The issue has to do with having cached thumbnails with different dimensions then what a new thumbnail would be, where refreshImageMetadata will just update the img_metadata blob (which would already have orientation in it for this issue to be present).

(In reply to comment #2)

Someone just purged the page so that fixed this one.

I just viewed it, and it was broken again (by broken again, i mean MediaWiki tried to show me the 800px wide version instead of the 400px wide version like it should have for a rotated image), purging re-fixed, but the fact it reverted to thinking the orientation was normal might be some sort of other bug.

Bryan.TongMinh wrote:

(In reply to comment #9)

(In reply to comment #2)
> Someone just purged the page so that fixed this one.

I just viewed it, and it was broken again (by broken again, i mean MediaWiki
tried to show me the 800px wide version instead of the 400px wide version like
it should have for a rotated image), purging re-fixed, but the fact it reverted
to thinking the orientation was normal might be some sort of other bug.

Perhaps if somebody purges it on a 1.17 wiki?

If you see this bug and ?action=purge doesn't fix it and re-uploading doesn't fix it, then open a bug for that image.

Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles raised the priority of this task from "Normal" to "Unbreak Now!".
Gilles lowered the priority of this task from "Unbreak Now!" to "Normal".Dec 4 2014, 11:23 AM

Add Comment