Uppy: Transform Plugins: crop, rotate, resize

[hedgerh]

I'm thinking a bit about how the processing/transform plugins are going to need to work. The following API (just an example) is not going to suffice:

  .use(DragDrop, { target: 'foo' })
  .use(UppyResize)
  .use(UppyRotate)
  .use(UppyCrop)

Given that transforms need to run in a very specific order, I think the best approach is to turn processing plugins into functions, rather than classes, unless there is some reason we actually need classes in the instance, which I don't think we do. We can then provide the developer with the following API:

Uppy.apply(resize(800,600))

Where .apply(), or whatever we want to call it, chains together all of the transform functions in the order in which they are provided.

If our file uploader has a photo editor that allows the user to make changes to an image before uploading, the transforms need to be ran in a very specific order to get the desired processed image.

Consider the following image:

If I run:

Uppy.apply(resize(800, 600))
.apply(rotate(90))

I get:

If I run:

Uppy.apply(rotate(90))
.apply(resize(800,600))

I get:

This is also the best approach to the API because some transforms will need to be applied more than once, like if you resize, crop, rotate, then resize an image.

[hedgerh]

So whenever an event on a button/slider/whatever fires, Uppy.apply(foo) is called

[kvz]

The way I look at it,

  .use(UppyResize, {target: Modal})
  .use(UppyRotate, {target: Modal})
  .use(UppyCrop, {target: Modal})

causes the install method to be run immediately. This causes the Plugins for modification to install either buttons or event listeners.

When the selecter stage completes, the run method is ran on all of these. This activates them (before this they would ignore any event for instance).

I can imagine the user clicking a rotate right button , which causes some code inside UppyRotate to handle the actual rotation.

Another thing I can imagine is the user adding labels/names to the files, or perhaps changing their mind and removing a file from the selection on screen.

Once all these permutations are to the user's satisfaction, he clicks the Proceed button. Resolving each modify Plugin's promise, hence resolving the modify stage, and progressing onto the upload stage.

[ameft]

I was going to suggest this transformation features and then I found this discussion.
In imaging this feature I was thinking the behaviour and functionalities of FileStack or Uploadcare.


To me the three main functionalities (rotate, resize and crop) should be in a single plugin component (transform) and could be accessed inside the edit (pencil) button.
Anyway.. +1 for me to this general idea! ;)

[pauln]

I was sure I'd seen this discussion somewhere, but couldn't find it when I came back to look for it today (until I Googled it and found that the issue has been closed). @arturi, was this issue perhaps closed accidentally? I see that you added a note about it to the todo list in the changelog, but that refers to this issue...

Side note: if/when such a plugin is implemented, might it be worth offloading the work of actually processing the image onto Uppy Server - sending it the image and a list of operations to perform? Although modern browsers make it possible to do it on the client, resource-constrained devices (such as mobile phones) may struggle to do the actual image manipulation in a reasonable timeframe / without crashing, especially if the source image is particularly large.

[arturi]

It wasn’t closed accidentally, I added this to backlog, as you noticed, and didn’t want too keep to many issues around, if they don’t have an active ongoing discussion and/or are not going to be resolved in the very near future. However, Uppy is always open to PRs and community-made plugins :-)

might it be worth offloading the work of actually processing the image onto Uppy Server

That’s a good idea, yes.

[ameft]

might it be worth offloading the work of actually processing the image onto Uppy Server

Considering that it's also a good idea to offload the server as much as possible, it could be an interesting idea to use something like the Performance API to decide which clients are able to process images and which aren't.

[bonesoul]

So will uppy ever support resize plugin?

[ameft]

So will uppy ever support resize plugin?

It's actutally expected for the next release: https://github.com/transloadit/uppy/blob/master/CHANGELOG.md#0240
We'll see.

[sm1thana]

It's actutally expected for the next release

You planed to release it 2018-03-29.
Is it still in progress?)

[EmilianoBarbozaOjeda]

Hi guys! Do you know when will be this released?
Thanks!

[goto-bus-stop]

There are currently no "official" image manipulation plugins in the works and no planned date for any to be released. There are some tricky things to work out, like how the cropping/resizing/etc UI could be integrated with the Dashboard or how it could be used _without_ the Dashboard plugin. We'll likely get back to it after 1.0 is out.

[simzen85]

+1 for support Cropping with

• flexible and fixed ratio
• multiple fixed ratio (Uploadcare has this while Filestack doesn't)
• supports crop for multiple files (Filestack has this while Uploadcare doesn't)

[getup8]

Just wanted to +1 this as well since it's been over a year :)

Initially, it might make sense to prioritize just cropping (at diff aspect ratios) and maybe even just provide the UI with a response of what the coordinates and dimensions are, without actually doing any image manipulation client-side (if that'd be easier). That way you could send those coordinates to your image server along with the image and crop accordingly there. But a client-side solution would also be nice to some I'm sure.

I saw this, but looks like that's pretty ancient:
https://transloadit.com/example_apps/image-cropper/index.php

Any of these look pretty great (esp the first I think):

• https://fengyuanchen.github.io/cropperjs/
• https://jamesooi.design/Croppr.js/
• https://foliotek.github.io/Croppie/

Happy to help but my JS skills are pretty poor so would need significant hand-holding.

[kvz]

Our engineers are swamped (with the issue tracker as our witness) to the point where it’s not possible to crank this out right now, even though we also really want to move forward on this. And as a bootstrapped company our pockets have finite depths. Is there anyone in this thread confident in their js-fu and interested enough to try and take a stab at this? We are very happy to offer guidance and anything else that’s needed.

Sent from mobile, pardon the brevity.

On 30 Nov 2019, at 00:00, Alex Scott [e-mail] wrote:


Just wanted to +1 this as well since it's been over a year :)

Initially, it might make sense to prioritize just cropping (at diff aspect ratios) and maybe even just provide the UI with a response of what the coordinates and dimensions are, without actually doing any image manipulation client-side (if that'd be easier). That way you could send those coordinates to your image server along with the image and crop accordingly there. But a client-side solution would also be nice to some I'm sure.

I saw this, but looks like that's pretty ancient:
https://transloadit.com/example_apps/image-cropper/index.php

Any of these look pretty great (esp the first I think):

https://fengyuanchen.github.io/cropperjs/
https://jamesooi.design/Croppr.js/
https://foliotek.github.io/Croppie/
Happy to help but my JS skills are pretty poor so would need significant hand-holding.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[getup8]

Completely understand. I will definitely take a look and see if I can implement anything that half-works via a custom plugin but due to my aforementioned poor js-fu, don't think I'll be much help in implementing a full solution. If I'm able to get anything working, will certainly share.

[GregWoods]

I'm disappointed at the lack of interest in this, but I understand. Uppy is focused on generic uploads rather than the more specific use case of image uploads. Plus there is a desire to promote the server side, hosted encoding service. However, it is real problem, particularly for mobile users generating multi-megabyte hi-res images, where the website they are using does not need all those pixels... it makes no sense to waste time and bandwidth uploading it to a server to resize when canvas based resizing is already a possibility on the client.

[ameft]

@GregWoods you're so disappointed to miss that a plugin specific for image manipulation has been added to Uppy a month ago?

[GregWoods]

No, I'm thrilled that #2370 allows CROPPING, but my use-case is RESIZING before upload i.e. changing the height, width, image compression, and hence overall file size? So some clarification would be useful.

[kvz]

Generally speaking we're open to adding image manipulation features that don't require a server (e.g. severely drain mobile batteries) and serve a large user base.

I'm not sure if resizing / compression qualifies, will take it up with the team. So long as nothing is merged to master, there is of course always the option to use your own or other plugins, such as this one for image compression https://github.com/arturi/uppy-plugin-image-compressor.

[warrenkc]

No, I'm thrilled that #2370 allows CROPPING, but my use-case is RESIZING before upload i.e. changing the height, width, image compression, and hence overall file size? So some clarification would be useful.

I am very interested in client side image resizing. So many people try to upload large images and they take a long time to upload because of the high resolution.