Had a good talk with Saibo on IRC; summary of top priorities:

[14:49] <Saibo> A: we need to override EXIF-specified rotation, also for old files
[14:49] <Saibo> B: we need to override rotation if no EXIF-specified rotation is present, also for old files

^ this we don't yet have in the works, but will help A LOT to fix any incorrectly-marked files.

[14:49] <Saibo> C: need to provide a consistent UI in Commons. IE: full size, lossless on click on the thumb. As it is with pngs.
[14:49] <Saibo> D: we need a download or even view option of the original file (if the rotation is not done by having a new file version in the file history)

^ bug 31366 starts to cover this; needs to be fleshed out to an actual implementation

Note the download option was closed as WONTFIX bugzilla 25695

bug 25695

saibotrash wrote:

(In reply to comment #1)
to be added:

• A 2: maybe a user setting to override EXIF on all new uploads (useful if a user uses a non-EXIF-aware tool to pre-rotate his photos before uploading.
• E: if an image was rotated using EXIF info there should be a visual indication somewhere

Added and then removed 29876. 29876 should be used for regressions.

I see many "we need to override" problems listed above, but I think it's really simple.
Assuming the original implementation has been reverted (bug 6672 comment 26+),
we have all the images correctly rotated (although EXIF may be wrong).
Add a new step on upload asking to rotate if the EXIF suggests it should be. Show a couple of thumbnails there, so it's braindead which way the uploader wants the image to be presented.
The invariant is preserved.

We don't have any guarantee that the EXIF data will be right (as we don't now), but we don't rely on it either, so it's no problem.

If you want to be fancy, and completely optional, add an option to rotate from the wiki UI, that makes the rotations as a reupload, even though everything is done server side (what about big images?).

saibotrash wrote:

(In reply to comment #6)
That was option onepointfive in https://bugzilla.wikimedia.org/show_bug.cgi?id=6672#c36

In general:

https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=60803004&oldid=60798859 Luxo and I made changes to our Rotatebot and the {{rotate}} template: they are able to take the EXIF rotation into account. So A and B are kind of fixed from our side. At least we have a good way to fix wrong EXIF tags now.
Just a minor but quite important question to complete the bot: which EXIF tag is used by MediaWiki to determine EXIF Orientation now? Is it only IFD0:Orientation or also other tags? Per fixing of bug 31487 it is not anymore the wrong IFD1:Orientation tag.

Only the IFD0:Orientation will be used now, so that should simplify things!

Not sure the best place to comment is here, but I can easily open a new bug later. We are testing newest 1.18 (svn 1.18.0beta1 Version 102635), and we still have plenty of wrongly rotated images. All thumbs were deleted after the update, so this is truly due to this revision.

Some cases are strange:

http://offene-naturfuehrer.de/web/Agrostemma_githago_%E2%80%93_Kornrade_(JKI-Pflanzenportraits)

in gallery at the bottom, look at the 2nd image: in thumb it is straight, when clicked (zoomed) it goes turned, when clicking at the license link at the bottom (going to mediawiki File-page) it is still wrongly turned, when clicking on image for original it is straight again.

Another nice case is this: http://offene-naturfuehrer.de/web/Datei:Cynodon_dactylon_7_Narben_IMG_6596_Wohlers.jpg where the width and height is switched consistently for all thumbs, while the original shown in browser (click on image on page above) is correct.

I had the impression the bug was fixed for normal jpg images in 1.18. Is it still open, or are these new cases?

(In reply to comment #9)

http://offene-naturfuehrer.de/web/Agrostemma_githago_%E2%80%93_Kornrade_(JKI-Pflanzenportraits)

in gallery at the bottom, look at the 2nd image: in thumb it is straight, when
clicked (zoomed) it goes turned, when clicking at the license link at the
bottom (going to mediawiki File-page) it is still wrongly turned, when clicking
on image for original it is straight again.

This looks like same orientation in the "zoom" view as in the gallery to me. It looks like the image has incorrect exif info, so MediaWiki is working as expected (It's a feature not a bug!! [sorry, but how often does one get to legitimately say that ;) ]).

Another nice case is this:
http://offene-naturfuehrer.de/web/Datei:Cynodon_dactylon_7_Narben_IMG_6596_Wohlers.jpg
where the width and height is switched consistently for all thumbs, while the
original shown in browser (click on image on page above) is correct.

The dimension flipping isn't working properly on this image (nor on the previous image, but that one is a square so barely noticeable) [for reference, image width and height does get flipped correctly on my local install]

[for reference,
image width and height does get flipped correctly on my local install]

by which I mean it works on trunk, which says nothing about if its broken on 1.18beta1

This looks like same orientation in the "zoom" view as in the gallery to me.

I confirm, I was fooled by my browser cache here. So it is consistently turned wrong, except for viewing the original image in Chrome, Firefox, IrfanView, Windows. It may be that the EXIF is incorrect, but maybe it is a frequently incorrect one, which browsers and image viewers recognize and handle?

The point I want to make is that from a user perspective consistency is the goal: if the image "is" (seems to be...) correct before uploading, it should work on the wiki as well.

thanks for testing quickly!

(In reply to comment #12)

This looks like same orientation in the "zoom" view as in the gallery to me.

I confirm, I was fooled by my browser cache here. So it is consistently turned
wrong, except for viewing the original image in Chrome, Firefox, IrfanView,
Windows. It may be that the EXIF is incorrect, but maybe it is a frequently
incorrect one, which browsers and image viewers recognize and handle?

The point I want to make is that from a user perspective consistency is the
goal: if the image "is" (seems to be...) correct before uploading, it should
work on the wiki as well.

thanks for testing quickly!

I personally don't necessarily disagree, but as it stands, this is the "intended" behaviour. (There's some discussion about it on bug 6672).

It may be that the EXIF is incorrect, but maybe it is a frequently
incorrect one, which browsers and image viewers recognize and handle?

Web browsers do not look at the EXIF data whatsoever. What image viewers do varies. The gimp for example prompts you if you want to rotate the image or not.

Web browsers do not look at the EXIF data whatsoever. What image viewers do
varies. The gimp for example prompts you if you want to rotate the image or
not.

Just an idea, you are boss here: Maybe what Mediawiki really should do with rotation is ask the uploading user - if there is any rotation EXIF - whether to turn the image or not? That could easily be standard conformant and work with user expectations in the case "frequently misformatted EXIF" should exist.

Does the second example also have malformed EXIF data?

saibotrash wrote:

(In reply to comment #14)

Just an idea, you are boss here: Maybe what Mediawiki really should do with
rotation is ask the uploading user - if there is any rotation EXIF - whether to
turn the image or not? That could easily be standard conformant and work with
user expectations in the case "frequently misformatted EXIF" should exist.

Please really read [[bug 6672]] - this is the predecessor of this bug's discussion. ;)

Yes, all what we now have with [[:commons:Help:RotateLink]] and the good old (but updated to the current MW behavior) [[:commons:user:Rotatebot]] should be built into MW. For some reason MW people like to do half things and confuse people and create additional work out of MW development. ;)

(In reply to comment #9)

Not sure the best place to comment is here, but I can easily open a new bug
later. We are testing newest 1.18 (svn 1.18.0beta1 Version 102635), and we
still have plenty of wrongly rotated images. All thumbs were deleted after the
update, so this is truly due to this revision.

Some cases are strange:

http://offene-naturfuehrer.de/web/Agrostemma_githago_%E2%80%93_Kornrade_(JKI-Pflanzenportraits)

in gallery at the bottom, look at the 2nd image: in thumb it is straight, when
clicked (zoomed) it goes turned, when clicking at the license link at the
bottom (going to mediawiki File-page) it is still wrongly turned, when clicking
on image for original it is straight again.

Another nice case is this:
http://offene-naturfuehrer.de/web/Datei:Cynodon_dactylon_7_Narben_IMG_6596_Wohlers.jpg
where the width and height is switched consistently for all thumbs, while the
original shown in browser (click on image on page above) is correct.

I had the impression the bug was fixed for normal jpg images in 1.18. Is it
still open, or are these new cases?

I just did ?action=purge on http://species-id.net/openmedia/File:Cynodon_dactylon_7_Narben_IMG_6596_Wohlers.jpg and it fixed the issue.

I just did ?action=purge on
http://species-id.net/openmedia/File:Cynodon_dactylon_7_Narben_IMG_6596_Wohlers.jpg
and it fixed the issue.

Thanks a lot! I thought that purging all thumbs would be sufficient; I start to understand that the dimension problem needs purging the cached pages itself. Will ./maintenance/rebuildFileCache.php work instead of purge?

(In reply to comment #17)

I just did ?action=purge on
http://species-id.net/openmedia/File:Cynodon_dactylon_7_Narben_IMG_6596_Wohlers.jpg
and it fixed the issue.

Thanks a lot! I thought that purging all thumbs would be sufficient; I start to
understand that the dimension problem needs purging the cached pages itself.
Will ./maintenance/rebuildFileCache.php work instead of purge?

I don't think it was the parser cache/file cache that was the issue. My theory is that the img_width and img_height field needed refreshing (which happens on a file metadata purge, which a ?action=purge also triggers) (This would make sense since these values should now store the post-rotation width/height where before they didn't, and your symptoms were that the width/height were mixed up).

This could probably be done by maintinance script with

php refreshImageMetadata.php --force

Should we disable autorotation by default in 1.18.1? It seems like there are a lot of pending issues here.

We did on biowikifarm. We tested 1.18beta and submitted several bug reports, but in the end we found that too many users are using image editing tools that don't respect EXIF rotation marker. Thus they manually rotate images, but keep the marker anyways. Since this is intransparent to the user, on biowikifarm we turned it off. My own analysis is that it would be an exiting feature to show the user two images: the unrotated one and the rotated one (if different) during the upload process, and ask which to use. This would add the missing transparency.

Reading about the huge frustration on Commons, it might be a good idea to turn it off. I think before turning it on, a bot should actually reset the rotation marker for all images on commons prior to the next experiment of turning it on. Or at least for all images before October 2011.

saibotrash wrote:

(In reply to comment #19)

Should we disable autorotation by default in 1.18.1? It seems like there are a
lot of pending issues here.

Ehm... very interesting.. why not before the deployment?! No, now(!) keep it on and push to fix the remaining bugs. And learn for the next deploy, please. I wrote some days before the deploy in Commons village pump that this will be messy - if you had just asked I would have told you before if you yourself did not know that images in the wild sometime have wrong EXIF Orientation data.

It encourages people not to use crappy tools (which often do lossy rotation. See what the user did: [[:commons:File:Tarnów,_budynek_przy_Rynek_14.jpg#filehistory]]. He noticed the image is wrong (since MediaWiki didn't respect EXIF orientation that time although the image had correct EXIF orientation), uploaded a lossy rotation over it and from that expierience on (clever user) he directly uploaded the lossy rotation: [[:commons:File:Tarnów,_budynek_przy_Rynek_15.jpg#filehistory]] , [[:commons:File:Tarnów,_budynek_przy_Rynek_16.jpg#filehistory]].

1.18.1 won't be deployed to Commons. I'm only talking about non-Wikimedia users. For Commons (and other wikis with a very high upload rate) it may be more complicated to get rid of autorotation than to keep it.

Bryan.TongMinh wrote:

(In reply to comment #19)

Should we disable autorotation by default in 1.18.1? It seems like there are a
lot of pending issues here.

Yes, probably.

Agree, if Commons can't even handle it, then too many downstream users probably can't handle it either. We need an update-dateline or an auto rotate algorithm or in interface to assist in rotation I guess.

Here is another example where an image is shown rotated and stretched in Mediaviewer:
https://de.wikipedia.org/wiki/Benutzer:MichaelSchoenitzer/test

The image is used in articles and people will view the picture in distorted state.