https://bugzilla.wikimedia.org/show_bug.cgi?id=6672
--- Comment #36 from Saibo <[email protected]> 2011-10-07 04:33:39 UTC --- Corrections / comments: * "Some desktop tools" - no - (AFAIK) all(!) current desktop browsers do ignore EXIF rotation. * The chaos is minor currently. The chaos will get worse (I guess) when thumbs needs to be regenerated of all the x thousands of files with incorrect EXIF rotation which we already have from uploads in the past. * I do not know what the "the *right* thing" is: I would say that rotating an image by a meta tag while you know that there are older but even current tools which do not respect this is a stupid idea. This can be done if a file format specifies this right from the beginning... but the old, pure jpeg doesn't. * It would have been nice if the Commons users would have been asked before such a deployment - why isn't this possible? Why do we need chaos first? * I do not understand how you will realize your idea. I.e.: how to get the real orig image if the user wants do download it? Options: * option one is: revert this change and do it like the years before: Ignore EXIF-specified rotation. We have Rotatebot in Commons. Images get tagged and physically bot-rotated. This worked fine for all cases. After physical rotation each and every tool did display correctly - no more hassle. * option onepointfive is: No real server-side rotation but a javascript assisted placement of bot tempates {{rotate|xxx}} or {{reset rotation in EXIF}} (not existent currently) directly on upload. Did I understand it correctly that you can read the EXIF tags by using Javascript? You can show the (exif-rotated) thumb (as it is done now) in the upload form and add rotation arrows and ask the user to bring the image in the right orientation. If the orientation chosen by the user differs from the physical orientation the JS could set one of the templates mentioned above. Those templates could be bot-processed then. Or maybe directly processed by a serverside re-upload of a physically rotated version. Benefit: no problems with full-size view in older tools (browsers). No chaos with old uploads. No manual tagging for rotation needed. * option two is: We keep EXIF-based rotation but it needs improvements. ** The most urgent thing would be that we need to have a possibility to fix files which specify rotation but do not need rotation. Currently, we can only fix this manually. Bot would be a option: https://commons.wikimedia.org/wiki/User_talk:Dcoetzee#EXIF_orientation_reset_bot But even if we have one: it is hard for all users except tech-aware to understand what is going on. A average user will think: huh, my image is rotated, lets order rotatebot to correct rotate it back. The problem is: the first rotatebot attempt will fail since rotatebot doesn't take the current Exif rotation into account. Maybe it should - in some cases... ** The full-size usability: user expects no rotated image when he clicks on a image (with correct exif-based rotation) to see the full view. Serverside rotation of the full resolution image (lossless, via exiftran for example) would be an option. But we also need to provide a option to download the real original image (maybe an additional link below). Of course this will still cause confusion and maybe will break some scripts/tools. I suggest: revert and think. And then maybe try a exif-based rotation again. btw: * just found: [[bugzilla:31366]] describes the full-size view problem, too. Feel free to merge or whatever. Not my world here. * opened [[Bugzilla:31487]] for another problem: "EXIF orientation tag display on bottom of each file page". This leads to more user problems because they have no chance to understand why MW rotates a image. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
