Extension talk:ImageTweaks/UI

Thanks for this work, it's quite interesting to see such developments and I agree with @MarkTraceur (WMF) that the current upload pipeline is very 2003 :-)

My only concern is where in the pipeline this fits and what happens to the original file (compare from @Pginer-WMF's comment on ability to go back to the original). My reason for wanting to make sure of this is that when you process an image through Canvas in this way, you lose any metadata that was embedded in the original: EXIF information and similar. Retaining this information is non-trivial and would require too much work to work in the general case, and so fitting this editor in the pipeline in such a way that the original file is still retained on the wiki would probably be the most sensible thing.

It's entirely possible that this was the intention all along and I just didn't pay enough attention :-)

This tool has the potential to save users time, so I'm really happy to see the initial designs and prototype.

I really like the idea of surfacing tools not supported yet for users to provide feedback about their need for them. Another useful source of inspiration could be by exploring some of the adjustments that people already make when uploading multiple revisions of a file to Commons. Collecting some of these examples can be useful to illustrate how these different tools can save users time.

Related to this, it would be great to know more about what the different tools mean in our context, also in a broader context than modifying an image. For example some comments about the specific case of the crop tool:

• Level of destructiveness. I was wondering how destructive crop should be in our context. Is it expected to create a new image or can a crop be additional data on to of it (that can later be adjusted again). Even if the cropping action results in a new image, it would be good during the manipulation to be able to be able to make the crop bigger or even go back to the full image. Also, beyond the adjustment stage, if a user finds a cropped image to use in an article, will there be a way to know it is a crop from a bigger image and use it (or a different crop of it) instead?
• Information provided. In the prototype, the crop tool shows some technical parameters such as the origin coordinates and size. I think the origin is not very relevant but the size information could be editable (and avoid fractions of a pixel). I'm thinking i scenarios where users want to extract an image of a given size or aspect ratio (e.g., making sure it s square). That also makes me think that if there are some common aspect rations, the crop tool could provide quick selections for them.
• Precision required. In the prototype, when manipulating the crop it requires to select the crop line. While it makes sense to use a thin kine for showing exactly what you are cropping, it may facilitate the manipulation to have a bigger target area (even if it is just an invisible safety area around the line). Another aspect to observe from user behaviour is whether zooming tools may be needed for helping users to cropping some large images.

I found a ticket at https://phabricator.wikimedia.org/T39732 which requires a general raster image editor. I agree with this idea.

A few more features I love to be added are rotating by any degree, automatic contrast adjustment and automatic bright adjustment.

For the deployment, I feel we don't need to add this feature to VisualEditor, and it seems being deployed as an independent tool on any wikis would be fine.