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
Description
Description
Details
Details
- Reference
- bz31391
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Amire80 | T23778 BiDi issue in RTL wikis at site notice with LTR text ending with Unicode characters with neutral directional | |||
| Resolved | None | T31876 1.18 post-deployment actions (tracking) | |||
| Open | None | T33504 Image rotation issues (tracking) | |||
| Resolved | Reedy | T33391 Aspect ratio incorrect for rotated images uploaded prior to 1.18 deployment |
Event Timeline
Comment Actions
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)
Comment Actions
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?
Comment Actions
saibotrash wrote:
Yes, I did purge it. Apparently the dimensions didn't get updated. Therefore the wrong aspect ratio.
Comment Actions
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...
Comment Actions
Bryan.TongMinh wrote:
Somebody can generate the list offline using the sql dumps if that takes too long.
Comment Actions
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.
Comment Actions
(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.
Comment Actions
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?
Comment Actions
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.