User talk:Rotatebot

From Wikimedia Commons, the free media repository
Jump to: navigation, search


(Notifications of deletion requests will be ignored here, Rotatebot doesn't upload own pictures.)

Filing cabinet icon.svg

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 10 days .

Dubble rotate[edit]

The File:Sinter-claes-saint-nicolas-dam800.jpg has been rotated twice (first by a user, then the bot). Could it be rotated back?? Thanks, Joost 99 (talk) 11:49, 7 December 2011 (UTC)

Dqfn13 (talk · contribs) used lossy rotation and did not remove the rotate-request-template. When the queue is smaller, please revert to the first version and order the bot again. -- RE rillke questions? 11:57, 7 December 2011 (UTC)
The same problem with File:394 Meeting Street.jpg, lossy rotation but has to be kept until the rotatebot backlog is gone. --Denniss (talk) 00:00, 8 December 2011 (UTC)
I've contacted the user and asked him to stop using lossy rotation. --Stefan4 (talk) 07:44, 8 December 2011 (UTC)
Sorry people, I was acting in good faith and didn't know about the bot. I'll use the bot next time. Dqfn13 (talk) 07:55, 8 December 2011 (UTC)
Two similar cases: File:Sunflower DSC01056.jpg and File:Schwalbenwurz-Enzian.jpg. Since they had other problems (complete loss of all EXIF data in the former case and double rotation in the second case), I reverted both to the original version and requested Rotatebot rotation. --Stefan4 (talk) 08:18, 8 December 2011 (UTC)
I think that there might be some problems here too. For example, File:20080317 swimo02.jpg lost all EXIF data after the rotation. --Stefan4 (talk) 18:23, 10 December 2011 (UTC)

How were File:Fes Bab Bou Jeloud.jpg and File:Abbaye Notre-Dame du Nid-au-Merle absidiole sud.JPG rotated? --Stefan4 (talk) 11:11, 13 December 2011 (UTC)

Lossy. -- RE rillke questions? 11:33, 13 December 2011 (UTC)
More lossy rotation: Special:Contributions/JKT-c --Stefan4 (talk) 00:01, 18 December 2011 (UTC)

Rotatebot couldn't find the template[edit]

Problem with File:PFChili.US.WSBK.Rnd.2009.jpg. See [1]. Rotatebot reported "Warning: Template not found, file probably still in the category!!". Rotatebot didn't remove the template, so the image was rotated a second time during the following run. At that time, the template was located and removed. I've fixed the image, but I'm reporting it here in case there's a bug in Rotatebot. --Stefan4 (talk) 13:51, 13 December 2011 (UTC)

Thanks for the report! :-) But.. wow - that is strange (the fact that he found it the second time). Maybe a network error. I cannot see what the fault was. As long as it doesn't reoccur it is fine (I will check the remaining log entries now) ... Luxo could you please have a look in the log? Cheers --Saibo (Δ) 23:40, 13 December 2011 (UTC)

Did bug 31607 slow down Rotatebot?[edit]

(those were EXIF-only changes, frist four at 2011-12-16 then four one day earlier same times. One file at the end two days earlier for comparision.)

Name Size Up dur. Speed Timestamp
File:MissFestivalMariachiSanJuan03.jpg 2.85 MiB 30 s 0.09 MiB/s 2011-12-16T19:37:30
File:SideAltarEncarnacionDiaz.jpg 4.45 MiB 50 s 0.089 MiB/s 2011-12-16T18:33:06
File:Two male childs.JPG‎ 1.56 MiB 37 s 0.042 MiB/s 2011-12-16T18:09:27
File:DandelionTlalpan.jpg 4.19 MiB 39 s 0.107 MiB/s 2011-12-16T18:05:36
File:Cernuschi Museum 20060812 079.jpg 3.27 MiB 30 s 0.109 MiB/s 2011-12-15T19:37:16
File:Cernuschi Museum 20060812 074.jpg 2.95 MiB 33 s 0.089 MiB/s 2011-12-15T19:36:04
File:Aquileia Basilica - Kirchturm 2.jpg 2.19 MiB 24 s 0.091 MiB/s 2011-12-15T18:04:15
File:WhitePussyLean.jpg 1.24 MiB 21 s 0.059 MiB/s 2011-12-15T18:15:29
File:Stikliu street Vilnius.JPG 1.05 MiB 16 s 0.066 MiB/s 2011-12-15T01:54:17
File:Murouji niomon3.jpg 2.41 MiB 53 s 0.045 MiB/s 2011-12-14T16:13:27

Conclusion: Not really faster - contrary to Reedy's observation. From this sample it seems that there could be a relation between file size and speed - but it is not very strong. If there is it could be due to some fixed amount of time - eg connection (de-/)setup. Cheers --Saibo (Δ) 20:55, 16 December 2011 (UTC)

{{rotate|0}}[edit]

What's the purpose of {{rotate|0}}? It seems that Rotatebot both deletes the EXIF and performs lossy rotation at the same time. Why is lossy rotation ever wanted? --Stefan4 (talk) 01:34, 18 December 2011 (UTC)

Rotatebot never does lossy rotation (meaining re-encoding) and doesn't delete the EXIF information (never). It is supported since some users asked for it. Currenly he uses it in some cases: User_talk:Denniss#0.C2.B0. Feel free to move this section to here and respond to it. Cheers --Saibo (Δ) 04:15, 18 December 2011 (UTC)
The rotation of File:Coltatt-chiuso.JPG looks lossy to me:

$ exiftool -all= 20111218062622\!Coltatt-chiuso.JPG

   1 image files updated

$ exiftool -all= Coltatt-chiuso.JPG

   1 image files updated

$ md5sum 20111218062622\!Coltatt-chiuso.JPG
33d4d5cc5384c085d945715ab28436ba 20111218062622!Coltatt-chiuso.JPG
$ md5sum Coltatt-chiuso.JPG
9fd24434a3d7e44505e343b74b021358 Coltatt-chiuso.JPG

If it wasn't rotated in a lossy way, what exactly was it that happened? exiftool -all= filename removes all EXIF metadata from a file, so if the files only differ by EXIF metadata, the MD5 checksum should be the same after removing the EXIF. Stefan4 (talk) 13:04, 18 December 2011 (UTC)
Jpeg code can be written in many ways without changing a pixel in the resulting image. So to compare jpegs you need to compare the pixel values after decoding.
However, regarding this picture here you do not even need to employ hashes or pixelwise comparision: just have a look at the dimensions. ;-) It lost 8 pixels in height due to the limitation of "lossless" jpeg rotating to full jpeg blocks (which are 8 or 16 pixels wide). Most images from digital cams have full blocks - however this here was cropped manually. As you can see from the nice millimeter paper in background it was cropped from the white above the tape measure. Cheers --Saibo (Δ) 13:35, 18 December 2011 (UTC)
So it isn't really lossless since it crops the image. ;-) I have found the feature useful whenever I carefully need to check images at the full resolution in order to determine the correct orientation: by placing {{rotate|0}} at the file information page, it ensures that no one else will have to repeat the same very careful check, but I guess it should only be used for images with resolution divisible by 8 or 16. --Stefan4 (talk) 16:19, 24 December 2011 (UTC)
Yes, for those images it is really (nearly) completely lossless. However, I do not think we should use it if there is no reason to. A reason would be e.g. a highly detailled image which will often be looked at in 100% in the browser. Not for the usual images. Another not really needed file version, leads to some tools not show the file in the user's uploads anymore, confusing rotation by 0° for noobs and it reders the automatic EXIF-based rotation of mediawiki useless. See for more discussion at User_talk:Denniss#0.C2.B0 but please comment on here - there doesn't seem to happen much at Denniss talk.... What are your thoughts? And do you really always check that a image's dimension is dividable by 16? :-D Have nice christmas days! --Saibo (Δ) 22:59, 24 December 2011 (UTC)
I thought it could be practical not to use EXIF rotation if you need to take a close look at the image in order to determine what's up and down, so I marked four images (and hopefully nothing else): File:Biserica de lemn din Sohodol08.jpg File:Biserica de lemn din Subpiatra07.jpg File:Biserica de lemn din Subpiatra12.jpg File:4548 - Bern - Rosengarten - Hybrid Tea.JPG Revert if you wish – I don't want to cause any problems. The fact that rotation causes images to disappear from Special:ListFiles/Username is a problem, so maybe it is better to avoid {{rotate|0}} even in those cases. --Stefan4 (talk) 00:16, 25 December 2011 (UTC)
Of course the current situation is stupid - you cannot view in current browsers without plugins the image in 100% in correct orientation if it is rotated by EXIF. See the text of the rotate|0 template - I linked a bugzilla bug there - hope it is fixed soon. And, yes, it is practical not to use EXIF rotation if possible (and no downsides) - it maximizes compatibility. That is the reason why Rotatebot does real rotations at all - it could also just set the EXIF to the correct value according to the rotate request (which -no real rotations anymore- is a strong wish by a frequent user in IRC - not sure if I should mention his name here). Did not look at your four files now - good night and thanks for your thoughts! :-) --Saibo (Δ) 03:10, 25 December 2011 (UTC)

Code snippets to be patched into Reedy's code[edit]

Note:

[2] --Saibo (Δ) 18:19, 10 January 2012 (UTC)

minor bug at template removal: not all removed if duplicate, different tags[edit]

just a note: if there are several templates which have different parameters. Seldom... and no damage as it probably only occurs with resetexif as no one would place tags with different ° numbers on a image. --Saibo (Δ) 13:20, 31 December 2011 (UTC)

minor bug: the bot leaves the empty line ...[edit]

Another minor bug: The bot leaves the empty line that may be between the rotate and the information template (example). --Leyo 15:06, 4 January 2012 (UTC)

The empty line was there before the rotation stuff started. It cannot remove all empty lines after the rotate template since they may be intentional (e.g. after the information template if the rotate template is inserted there). Have a look at e.g. the moste recent rotate request at the test file. No empty line added by RotateLink and consequently no empty line after rotatebot's template removal. I don't think it it worth to build in some rules where to delete an empty line after the rotate template and where not. ;-) It just isn't of relevance in 99% ("guess") of the cases. Agree? Cheers --Saibo (Δ) 15:45, 4 January 2012 (UTC)
There is no case where the source code is supposed to start with one (or several) empty line(s). Hence, it would be a good opportunity to remove any empty line(s) at the beginning. --Leyo 18:16, 10 January 2012 (UTC)
The bot could also to some other cleanup (e.g licensing → int:license-header), however, let's keep it simple. Or suggest a code bit which removes empty lines only at the beginning of the page. ;-) I do not see why we (Rotatebot) need to fix something which we haven't broken (and which isn't even broken - it is just invisible cleanup). ;-) Viele Grüße --Saibo (Δ) 04:11, 11 January 2012 (UTC)
I think it is a good idea to do some uncontroversial cleanup in the same edit. Let's wait for a statement by Luxo. --Leyo 13:30, 11 January 2012 (UTC)
I prefer to keep the bot simple, just do rotating and no cleanup work. If we start cleanup, everyone is coming with things the bot could do - from rename bad title (yes, that was already mentioned) to sort out categories which don't fit - no, I prefer that the bot makes what he was made for - rotations. Greetings,--Luxo 19:25, 12 January 2012 (UTC)

Slow down Rotatebot?[edit]

The most work is done. For the outstanding images on User:Umherirrender/EXIF rotation it is hard to know, if they need rotation, because you cannot see it direct. Would you leave Rotatebot running all 5 minutes? In my opinion is that to fast, because you cannot remove a wrong set template or so. Maybe increase to 1 hour or so. Der Umherirrende 20:14, 7 January 2012 (UTC)

See #new code bit (not important) proposal for activation controlling via a template. However, I have simply switched it off now. See also this user report - current speed is too fast, as you also mention.
How many files are left? Only the page at User:Umherirrender/EXIF rotation? Cheers --Saibo (Δ) 20:46, 7 January 2012 (UTC)
Yes, only that 495 files are left from the big list of 54637 files. Der Umherirrende 21:16, 7 January 2012 (UTC)
Well, okay - as the need for Rotatebot will constantly decrease now we could also leave my shiny new code where it is (not live) and simply set the cronjob to one hour again...yes. Hey, that's boring! ;-) Cheers --Saibo (Δ) 22:24, 7 January 2012 (UTC)
Yes, let's ask the devs to remove the magical rotation when they introduce VIPS as scaler because Saibo feels boring :P -- RE rillke questions? 22:44, 7 January 2012 (UTC)
You can set now the minimal lag of the bot in User:Rotatebot/config.js - Feel free to change the minutes if you don't like 10 minutes :) Greetings,--Luxo 17:35, 10 January 2012 (UTC)
Code diff for reference. Thanks, will update the time templates. :-) Viele Grüße --Saibo (Δ) 18:17, 10 January 2012 (UTC)
Whyever it seems to lag more than set (45 minutes). At least currently. A TS problem? Or does it sort out by error sometimes? Viele Grüße --Saibo (Δ) 04:08, 11 January 2012 (UTC)
I wondered also but didn't find an answer. The bot picked (at 2:30 UTC) some of the tagged pictures and left others undone for a while that I tagged before the rotated ones. It doesn't make sense. Afterwards at 3:20 UTC it rotated the left ones also. --Geitost diskusjon 13:21, 11 January 2012 (UTC)
But what shall the bot do now if it works correctly? ;-) Start every 5 minutes after the last rotation of pictures but rotate only pictures which were tagged at minimum 45 minutes before? Correct? --Geitost diskusjon 13:26, 11 January 2012 (UTC)
Yes, that's how I understood it should work. Cheers --Saibo (Δ) 15:22, 11 January 2012 (UTC)
That's funny....--Luxo 16:04, 11 January 2012 (UTC)
Yes looks like it's 1000 seconds wrong... fixing that ;)--Luxo 16:44, 11 January 2012 (UTC)
Sometimes math is hard! Now it should work correctly. thanks for being watchful,--Luxo 16:53, 11 January 2012 (UTC)
there is still a bug...--Luxo 17:23, 11 January 2012 (UTC)
nowwww i think i get all :P--Luxo 17:37, 11 January 2012 (UTC)
That improvement sounds good. You have still small batches, but that images are at least some time in the category. Der Umherirrende 19:16, 11 January 2012 (UTC)
Only by the way: Instead of adding the skipping function to the bot, you can use the parameter cmend of the api. Calculate the current time +45 minutes and give that to the api (UTC, format: 2012-01-12T20:15:00Z). Der Umherirrende 19:31, 12 January 2012 (UTC)

← For log checking it would be quite a bit easier if the bot would wait until a certain amount of files has cumulated (e.g. 10). But that would be rather unfortunate for the users. So: keep it that way. Works fine now! :-) Viele Grüße --Saibo (Δ) 23:00, 11 January 2012 (UTC)

Not only for log checking, also for keeping the history small. But not waiting for new tagged files: Just let the bot 1 or 2 hours wait before starting new as I've explained here. That would be more comfortable. Perhaps 2 hours would be better than 1. And then take all images that were tagged until min. 45 minutes before the new run. --Geitost diskusjon 15:34, 12 January 2012 (UTC)
what's the problem with a long history? If we would do it like that you have to wait max. 2h 44min. too long. --Luxo 21:42, 12 January 2012 (UTC)
I guess Geitost fears server kitties would be killed if the historoy is too long. ;-) I like it! *evil grin* --Saibo (Δ) 23:29, 12 January 2012 (UTC)
Could be. ;-)
But if you want to have a longer history, you can get one. :-P I can do it the other way round, it's easier. One hour could also help a lot. The „Vorschau“-Template is only for users but not for bots??? Or doesn't such a template exist here also? I don't think that maybe 1:44 hours would be too long if you think 2:44 h are. But it would help a lot with a better, shorter history and better overview there also. 30 minutes instead of 1 hour would also help but 5 minutes are just way too short. -Geitost diskusjon 01:22, 13 January 2012 (UTC)

Work[edit]

Hello, your robot is not working. I marked my file Lanov, kostel.JPG as image requiring rotation by bot and your robot had repare it by one hour and image is still wrong turn. Thx --Mejsnar ow (talk) 10:52, 3 March 2012 (UTC)

Indeed. It seems that there are images tagged for rotation yesterday which still haven't been rotated. Latest edit at 2012-03-02T14:16:02. --Stefan4 (talk)
Sorry, there seems to be something broken again. I have written Luxo an email, I cannot fix it by restarting the bot. Please be patient. --Saibo (Δ) 15:14, 6 March 2012 (UTC)
Seems that the bot has started now. Saibo, could you check what Rotatebot did wrong here? By the way, the same problem appears to have occured with other images, so we should probably check the latest few uploads as soon as possible. --Stefan4 (talk) 22:09, 6 March 2012 (UTC)

Improper rotations[edit]

Currently checking all recent transfers. Sometimes, Rotatebot has uploaded completely different images, and on some occasion the bot has removed all line breaks from the file information pages. The files listed below have been checked by me and reverted with a new rotation request where appropriate, but I guess that the improper revisions might have to be deleted since they aren't sourced and don't credit the respective photographers on the file information pages where they have been included improperly. --Stefan4 (talk) 22:56, 6 March 2012 (UTC)

Checking together with Rillke. If you notice a malfunction please just ask the next admin to block the bot (with autoblock off) and or write me on my talk page. Usually I check my watchlist only once a day, currently not even this. :) Cheers --Saibo (Δ) 23:50, 6 March 2012 (UTC)
Rillke did all the cleanup work, I had a look at the current uploads and restricted to 2 uploads per 15 minutes. You said "removed all line breaks from the file information pages" - you did revert that, too? Great, thanks! Do you have an example where it happened? Cheers --Saibo (Δ) 00:05, 7 March 2012 (UTC)
I fixed line breaks whenever I spotted the error. I hope I didn't miss it somewhere, but it was easy to spot since it broke the headers. It happened with many of the files in the list above, for example File:Syakkyo,Yoko-cho,Sakura-city,Japan.jpg. --Stefan4 (talk) 00:15, 7 March 2012 (UTC)
Maybe you know(so I do not have to go through the contribs): which image was the first wrong one? Trying to find the cause... --Saibo (Δ) 00:32, 7 March 2012 (UTC)
Sorry, I don't know. Many images had the line break problem and I didn't check where it first occurred and it didn't occur with every file. Try searching backwards from Special:PermanentLink/67987455 (2012-03-06T21:22:38). --Stefan4 (talk) 00:42, 7 March 2012 (UTC)
Okay, thanks. Rillke checked all files again for the line break problem and found 4 more. --Saibo (Δ) 01:28, 7 March 2012 (UTC)

20:39 was the first one with removed line breaks I found. Strange is: File:Arbre_du_parc_du_Thabor_%28mars_2012%29.JPG was rotated twice after that time but only the second one removed all line breaks. Last occurrence of the line break problem: 21:35:02. I did not found out anything sepcial. Maybe Luxo finds something in the logs. I will leave it to 2 files per 15 minutes - that should be safe. --Saibo (Δ) 01:28, 7 March 2012 (UTC)

It works fine currently - and the limit to 2 is not really a problem since there are apparently nearly never more than 2 images tagged in 15 minutes. No hurry to find out what happened and the root cause. --Saibo (Δ) 12:55, 8 March 2012 (UTC)

Analysis of 2012-03-06: The file which had the first removed line breaks was the first one after 20:30. At 20:01:55 Luxo removed the protection against two concurrently running rotatebot instances (I do not know why - Rotatebot was running also before Luxo's edit (since 2012-03-06 19:21:57)). That caused the bot run at 20:30 not to cancel itself although the run from 20:15 was still uploading its batch of images (was just at image 17 of 40 at T20:30). That strange stuff happens in that case can be expected with the bot's internal structures. At 23:54:58 Uhr I reduced the number of files per batch to two (preventing that it can take longer than 15 minutes for one batch). At 2012-03-07, 13:58:43 Uhr Luxo switched the protection back to normal.
So I suspect that was all the background and I blame Luxo ;-) ... I should have had looked earlier into the history of the config file. I will leave the batch at max 2 files until Luxo confirms as we have no hurry.
I noticed also a mistake by me: My restart attempt at 2012-03-06T15:00 was wrong as I thought the bot would start every 5 minutes - but that is not the case anymore - it is 15 mins since the last downtime. Cheers --Saibo (Δ) 00:49, 9 March 2012 (UTC)

Images invisible[edit]

After rotating these two images I can't see File:Fotothek df tg 0005712 Astronomie ^ Gnomonik ^ Sonnenuhr.jpg and File:Fotothek df tg 0005711 Astronomie ^ Gnomonik ^ Sonnenuhr.jpg, please help me ... something wrong? --Tamorlan (talk) 20:20, 27 March 2012 (UTC)

Rotatebot got something wrong. I'm not sure what Rotatebot did or why it didn't work, but I've rotated the images manually using Exiftool. What remains is to find out why Rotatebot failed so that the bug can be prevented in the future. --Stefan4 (talk) 20:54, 27 March 2012 (UTC)
Image dimensions and size indicate that rotatebot did everything right. Seems to be some database corruption. -- RE rillke questions? 09:17, 28 March 2012 (UTC)
I forgot to mention it, but it happened again yesterday with File:Seaweed and rock, Marloes Sands - geograph.org.uk - 537401.jpg. --Stefan4 (talk) 14:23, 17 April 2012 (UTC)
This seems to happen when the filename contains non-alphanumeric characters. I don't think it is a specific problem with Rotatebot. Finavon (talk) 06:14, 2 June 2012 (UTC)

Behvaior when there are errors?[edit]

I noticed that when the bot can't rotate an image as requested for some reason, like the case here, it rotates by 180 degrees. Is that really useful/necessary? Seems to me like this behavior wastes server resources and creates unnecessary clutter. —Ynhockey (talk) 15:34, 16 September 2012 (UTC)

I guess MediaWiki's behaviour is a kind of unpredictable in these cases (corrupt EXIF). But this would need more careful investigation. -- Rillke(q?) 18:33, 16 September 2012 (UTC)

rotation by ...°[edit]

Here Rotatebot said the image was rotated by 270°, but it only was rotated by 180°. --Aa1bb2cc3dd4ee5 (talk) 22:40, 24 September 2012 (UTC)

$ exiftool 20120924223045\!Vojenský_h�%99bitov_-_z_války_r._1866_\(Nový_Bydžov\)\,_za_nemocnicí.JPG | grep Orientation
Orientation                     : Horizontal (normal)

However, Mediawiki displays the image as if it has some other EXIF value. Strange. --Stefan4 (talk) 22:49, 24 September 2012 (UTC)

Image is strange indeed, first revision is broken and second version shown as 4.35 MiB with rotated thumb. Upon reverting to this second version it shows up as 6.82 MiB with correct thumb and image. Rotatebot was obviously using the same image version for rotation. --Denniss (talk) 05:50, 25 September 2012 (UTC)
The same problem again. --Aa1bb2cc3dd4ee5 (talk) 12:54, 25 September 2012 (UTC)

Waiting for rotation[edit]

Could you please inform me when will my images be rotated?

It is an other interesting question why were they uploaded (with UploadWizard) with wrong direction, because in my computer they are correct. Thank you --Rlevente (talk) 13:39, 22 October 2012 (UTC)

Wiki Software uses the Rotate Bit from Exif data for Rotation. Apple and M$ Software may ignore this. All images show "Rotated 90° CW" in Exif. The Bot may have stopped working, no action since late October 20. --Denniss (talk) 15:42, 22 October 2012 (UTC)
I uploaded the images once more and now the orientation is correct. --Rlevente (talk) 20:24, 23 October 2012 (UTC)
You used lossy rotation, not lossless rotation. This will have to be reverted. --Stefan4 (talk) 20:32, 23 October 2012 (UTC)

A barnstar for you![edit]

Special Barnstar Hires.png
Congratulations with your brilliant work! Wolf Lambert (talk) 11:24, 14 February 2013 (UTC)
Yes! It's really a Bot who would be missed if not invented yet! Face-smile.svg
Jaybear...disc. • 13:29, 18 February 2013 (UTC)

Rotating Notes[edit]

Dear Bot Operator, please check the notes of File:Schnittstellenkarte-parallel.jpg who do not work animore. I added the notes again and left the older notes in the file article. Can you review you bot's operation? Thank you. --Hans Haase (talk) 21:07, 3 June 2013 (UTC)

This would be something worth considering: Exchanging the dimx and dimy-parameters of the image note template after rotation. -- Rillke(q?) 21:57, 3 June 2013 (UTC)

Please help[edit]

Good morning! when I shot the Legislative session hall, it was closed and there was glare[3] Then, I had it rotated, 90 degrees. So, I hope I can fix it, but I failed; hence I uploaded a new version[4]. This is the panoroma of the Town hall, including the landmark Malvar Shrine and monument. But then, the panorama was rotated, hence it looked standing up. Hence, may I respectfully request the removal of the rotating[5](for the rotating did refer to the old one uploaded, and not to the new version), since the new version photo needs not be uploaded. Thanks.--Ramon FVelasquez (talk) 02:01, 30 July 2013 (UTC)

Protocols in place re. rotating an image used in multiple articles?[edit]

While editing Name of Ukraine, I noticed that this map had been turned upside-down via a request to Rotatebot actioned on 16 July 2013. Having taken a look at the Russian wikipedia page (where this file was recently noted as being an upside-down view), I can only surmise that the request emanated from there for whatever reasons they have to want it in that view, or that it was requested by someone for no particular reason.

Considering that the file was originally uploaded for the English Wikipedia page I'm working on, I'm wondering whether I'm heading for an edit war with someone on another wiki! Having now made a request that it be corrected by being rotated 180 degrees via Rotatebot, I was surprised that there were no fields querying why, nor does it appear that any checks are made as to how many entries/articles are using it.

Does this mean that anyone can simply click on the request, even if it may be imposing on a file's usage & appearance on a multitude of pages, without due notification and consensus from all parties concerned? --Iryna Harpy (talk) 03:30, 28 August 2013 (UTC)

For rotations, our policy on overwriting existing media, COM:OVERWRITE applies as well (= it is not permitted if the rotation makes a major, potentially controversial change). It is true that there is room for abuse. That's why we could, in theory limit that service to certain users (either by telling Rotatebot to do so or by setting up an AbuseFilter), which was not yet subject to discussion because
  1. usually we have users watching the log, Rotatebot produces, and revert vandalism.
  2. we do not have a lot of this kind of abuse.
Wikis with Extension:FlaggedRevs installed can't be "vandalized" that way. FlaggedRevs will make sure the visitor sees the last approved image version. If this is not possible/wanted on your homewiki and you still see an issue, we can
  1. add further edit restrictions (easy but unfriendly)
  2. add clutter to the rotate-user-interface citing our policy, which then also has to be translated (ugly)
  3. add an option to make it uploading to another file (nice but time consuming)
  4. somehow get more editors checking the log
  5. add more delay until the rotations are done by the bot and hoping that users will review this category and remove invalid requests.
Personally, I do not think that this issue is specifically to Rotatebot; files can be overwritten by any autoconfirmed user with nearly anything, including rotated versions. -- Rillke(q?) 12:37, 28 August 2013 (UTC)
Understood. I did, of course, realise that undesirable complexity via tighter protocols would be implicit. The problem is that, as I spend most of my time on English Wikipedia, the notification system doesn't carry across various wikis/wikas (in fact, I've only just traced down your response by going over my watchlist: now inter-wiki notifications is something that could do with being addressed!).
Due to a substantial portion of my contributions surrounding Eastern European/Slavic issues (did I just hear you scurry away from the monitor gibbering?), more time is spent in trying to protect or semi-protect pages, revert vandalism & act as an arbitrator between warring factions than goes into developing articles. It appears that blocked 'interested parties' have found a new way of making political statements which are more difficult & take longer to detect than their previous 'contributions'. I've traced down the culprit (who happened to be the one who added the upside-down comment in the Russian Wikipedia) & deleted the image comment he'd snuck into their article. Images in articles end up becoming part of the furniture & one doesn't pay too much attention to any edits involving them as they're typically aesthetic moves.
Sigh. As a matter of wiki-principle, I just have to accept that I have to accept it as another issue on top of my watchlist, although I'll look into the flagged reverts as an option. I certainly don't like the idea of uploading another version of the file as one file means I can intervene quickly if other pages linked to it have been vandalised.
Cheers for taking time out to clarify! --Iryna Harpy (talk) 04:37, 29 August 2013 (UTC)
Flagged revs stands for flagged revisions, meaning that each revision gets a "flag" such as "good enough for showing to visitors". The separate file option was directed to users who want to alter the image, not for those who clean up that "vandalism" :-) -- Rillke(q?) 09:38, 29 August 2013 (UTC)

Rotation 90 or 180[edit]

I requested rotation 90 in File:Casa Jaume Estrada (Barcelona) 2013-09-27 18-46-27.jpg but it got rotated by 180º. Is there a problem? Should I request rotate again?--Pere prlpz (talk) 14:40, 8 January 2014 (UTC)

See edit summary of the bot: EXIF had major errors. Great parts of EXIF could be lost. These erroneous Exif information likely caused the bot not properly detecting the current orientation or an orientation different from that that MediaWiki detected. -- Rillke(q?) 16:03, 8 January 2014 (UTC)

A barnstar for you![edit]

Kindness Barnstar Hires.png The Random Acts of Kindness Barnstar
Hola, te agradezco Rotatebot, Lakalk921 (talk) 12:19, 20 April 2014 (UTC)

Videos[edit]

Hi,

I think it would be usefull to write a bot, which would rotate videos.--Juandev (talk) 16:13, 2 May 2014 (UTC)