Change 250291 had a related patch set uploaded (by Ori.livneh):
include mediawiki::multimedia on all application servers

https://gerrit.wikimedia.org/r/250291

Since the migration to HHVM, several things have changed:

• Request resource limits are now identical across all application servers.
• CPU utilization on the API cluster is a third of what it was a year ago.

If we simply install multimedia packages on all application servers (as I'm proposing we do in Ib5dee0fce), the end result would be a world in which every application server is in principle capable of serving every kind of request. I think that this would make our software stack substantially simpler to manage and would pave the way for elastic load-balancing and SLAs.

Once Ib5dee0fce is merged, I think the next logical step is to simply enable the imagerotate API (in its current, synchronous form) while monitoring load.

There is a risk that the load generated by image rotation requests will be too high and that we will need to disable image rotation once again, which would no doubt be frustrating to users. But I think there is a very good chance that we will handle the load just fine, and that it is worth a shot.

@ori, just for me getting things right, it is okay now to do multimedia operations synchronously on the application servers? No queue required because the resource limits are now identical across all application servers and there is less load on them and not desired because it would complicate managing the software stack substantially?

That aside, I like Brion V.'s suggested interface "filetransform". It's not so narrow in scope.

From 105877, the imagerotate API module is disabled on beta just like production:

In T105877#1466397, @hashar wrote:

CommonSettings.php has:

// T35186: turn off incomplete feature action=imagerotate
$wgAPIModules['imagerotate'] = 'ApiDisabled';

Disabled because of T35186: Provide a well-performing API to rotate an image.

If one want to enable it for testing purpose, I guess it is all about adding the setting in a -labs.php file.

Because of the recent changes in session handling/tokens the bot is broken. I am unable, even after multiple hours of work (i don't have time to spend moor hours for this), to detect the problem. Which mean rotatebot is no longer rotating files and the backlog will become bigger every day: https://commons.wikimedia.org/wiki/Category:Images_requiring_rotation_by_bot

If the bot is getting logged out, it's probably not handling cookies right. (Use a standard library, don't try to do it by hand.) If it's not getting logged out but getting token errors, it's probably not urlencoding request parameters properly.

Unfortunately, i don't have time to re-write it / porting to a standard library. And i think it is time now to include this function in mw, especially because it is highly used.

I attempted to fix up how the rotation bot does logins. https://bitbucket.org/Steinsplitter/rotatebot/pull-requests/2

Thanks but unfortunately it does not work. The whole code needs a re-write. The best would be to port it to MW (the function in MW api exist yet, but not compatible with WMF cluster yet).

Hmm, I see your bot uploaded rotated versions of a few files today – have you gotten it to work after all?

In T35186#2033230, @matmarex wrote:

Hmm, I see your bot uploaded rotated versions of a few files today – have you gotten it to work after all?

I am current merging the bot to a stable library (https://en.wikipedia.org/wiki/Wikipedia:Peachy).

Update: Bot is back again. Now rotation of bigger files and .tif(f) is supported.

Update2: But of course this bug should be fixed contemporary.

Change 250291 abandoned by Ori.livneh:
include mediawiki::multimedia on all application servers

https://gerrit.wikimedia.org/r/250291

FYI: https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Commons#Allow_file_rotation_on_commons

The biggest problem with this patch is that it came out of a request to
allow rotations in multiples of 90°. Commons does not need or want anything
besides that, because you don't want eyeballed rotations, and 90° multiples
are about the only ones you can do eyeballing that are worth doing.
Anything else you want people taking the image to proper image editing
software, with guidelines and care.

PLEASE DON'T give us something that you think would be better, when,
practically, all it does is encourage slow degredation of image as people
go "is 1°' enough... no... try another degree..."

Image curation and a free rotation tool are not compatible.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Any updates on this?

Sometimes, the rotation sought is not around the center point, but around the central vertical or horizontal axis (sometimes called mirroring, flipping, or flopping). This should be doable losslessly. See also c:MediaWiki talk:Gadget-RotateLink.js#Mirroring as Rotation.

This seems something that is much more doable now that we have Shellbox. I reviewed the current code in ApiImageRotate and would suggest the following modifications:

• Only allow a single file to be operated on at once (can skip using ApiPageSet)
• Initially, set some max size limit of files that can be rotated. This can be raised over time as the API module proves stable.
• Given this has really never been enabled widely, we should rename it to ApiFileRotate.
• Add a change tag like mw-file-rotate to all uploads that use this.
• Make all the various $handler->rotate() calls be Shellbox-compatible by using BoxedCommand.

Happy to review/mentor/guide someone in working on this.

It seems CropTool already supports rotation (maybe this should be advertised better?), I'm slightly hesitant to add more to mediawiki and bloat it. MediaWiki is not really an image editing tool.

@Legoktm @Ladsgroup it seems crop and rotate (by 90/180) are such a common use case they should be "on" by default, whether by closer integration of CropTool into the upload wizard or otherwise.

The existence of CropTool, and its rotation feature (I didn't see it when I first used it!) could both be made more visible.
Agreed with AdamC's old point above that arbitrary-value rotation can be confusing, if the common rotations aren't [more] prominent.

I think simple rotating (let's leave cropping out of it for now) is a must for Commons and something that should be supported at production quality, especially given the recent emphasis on better multimedia and technical support for Commons. Anyways it seems like low hanging fruit.

Whether or not it is implemented as part of MediaWiki or a separate service is up for debate, but I would say that based on our current architecture, getting it deployed via a Shellbox implementation will be the most secure and also simplest to implement.

I also think this is one of those cases where if we just provide 90/180/270 rotation for files under say 10MB, we'll address like 75% of the use case (the remaining being larger files or custom rotation angles). Anyways, no one took me up on my offer to mentor, so I might go ahead and do this (but explicitly not cookie licking yet!), I'll just have to find a +2'er...

Agreed re: just offering 90/180/-90 for under-X-MB files. Raise that to 20MB and you'll cover most good/featured images.

Change 973279 had a related patch set uploaded (by Legoktm; author: Legoktm):

[mediawiki/core@master] WIP: Implement file rotation via Shellbox

https://gerrit.wikimedia.org/r/973279

So I've posted a patch that is basically what I outlined in T35186#7487506. Rough next steps:

• Find a reviewer, who ideally knows the correct file abstraction APIs to use on the Wikimedia cluster
• Send notification to wikitech-l on the plan and notification for MW breaking change (removal of ApiImageRotate)
  • Also get SRE buy-in
• Send notification to API lists on planned API breaking change, removal of API action=imagerotate (maybe people actually use it and we need a deprecation process??)

This makes my week. Thank you :) (:

Still the most-tokenized open issue :)

@Legoktm Recent thoughts? Looks like there are open comments from @TheDJ on the patch.