search

h2non / imaginary

Fast, simple, scalable, Docker-ready HTTP microservice for high-level image processing
https://fly.io/docs/app-guides/run-a-global-image-service/
MIT License
5.58k stars 458 forks source link

Resize and crop, or extract? #28

Closed Dynom closed 9 years ago

Dynom commented 9 years ago

Hi,

I'd like to do the following, in one single request:

So that I can basically create a smaller version of the file, maintaining aspect ratio and crop to a certain region within the scaled-down version. As I see it now, this could work by adjusting how /extract works.

If it's possible for a client to specify a width, and if Imaginary calculates the appropriate height. Is this already possible and/or would it be possible to implement?

Dynom commented 9 years ago

I've been tinkering with it some more. But you've "hidden" this feature in the crop method! I was thrown off by the naming (since it does much more than just cropping) and I was already a bit puzzled why I couldn't specify an area, as with extract, but it works for my use-case

h2non commented 9 years ago

Some time ago I thought about supporting a sort of multiplexing feature. At the end, all the endpoints are just configuration aliases which converges in the same code, calling bimg.Resize(options). Most of the endpoints shares the same config params, so you can pass them to /crop and /rotate as well.

To get a better idea, can you please share an example about what you're looking for? If there's some missing or unclear info in the docs, please let me know or send a PR.

Dynom commented 9 years ago

I basically want to resize an image to certain dimensions, while maintaining the original aspect-ratio. Then I want to make it fit my design, I do that by cropping the image to adjust it to an aspect-ratio that I need.

I find the /crop parameters unintuitive, because cropping usually has either: top/left & area width and height, or top/left/right/bottom parameters.

Having that said, crop does exactly what I need, so I'm happy with Imaginary's feature-set, I just thought it wasn't intuitive when I was looking for the thing I needed.

Btw, I've reviewed your code and I must say that I'm impressed. Well designed, nice and clean. Well done!

h2non commented 9 years ago

Thanks for the clarification. Crop operation is implicitly similar to an extract operation, the unique restriction is that the focus of the image is always centric based. I see the requirement, and it could be useful for pass some extract params in certain use cases to avoid multiple requests.

I took the feedback regarding to the documentation and usage, and I'll try to improve or make it more explicit in some way.

Regarding to the original proposed feature, like almost everything, it depends on your specific scenario, for instance, if you're exposing imaginary as public service and clients can access directly, let's say, from a browser, it will be very handy (or even mandatory) to perform all the image processing in one request, however I've to say that imaginary was mainly designed to be used as part of a private solution for image processing instead of a public HTTP service.

To deal with multiple image transformations in a convenient way, in the past I've created an imaginary client (at the moment just for node.js) which provides an elegant DSL interface to talk with imaginary with more fluency. Probably implementing or using some like that might be helpful when adding more responsibility in the client side is not inconvenient.

Will close this issue for now. Feel free to re-open it, if needed.