Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Combine cropping with resizing #176
thanks for the great service!
I'm wondering if I'm doing anything wrong, but it seems to me that cropping and resizing the cropped result is not supported. Is this so by design and do you need to do this in two steps (by sending the cropped result again to a new weserv call for resizing)?
Please look at the following examples:
For me this is weird, because:
Thanks for your feedback!
As stated in the documentation, the manual crop is performed after the resize operation. For example:
I agree that this is not clearly stated. I'll try to improve the documentation in the next API (sneak preview here: https://t0.nl/docs/crop.html#manual-crop).
The reason that the crop is performed after the resize operation is because we can then use the shrink-on-load feature that can give a huge speed boost, up to about 10x. Perhaps we could add a new parameter (for e.g.
Ok, thanks for your feedback!
I can imagine the speedup when performing crop after resize and totally understand your design decision. We have now worked around this by doing two calls on the image server (like this https://images.weserv.nl/?url=%2F%2Fimages.weserv.nl%2F%3Furl%3Dhttps%3A%2F%2Fpoetsbureau-dev-images.s3.eu-central-1.amazonaws.com%2FjjoxtAAS_anna-ogiienko-382635-unsplash.jpg%26crop%3D1235%2C1235%2C1861%2C348&w=200&h=200&t=fit)
But still 2 other issues remain imo:
In both examples the crop is ignored because it's done after resizing in the current API, and it cannot find the region (1861x348 is more than 200x200).
Which is the same result as:
This will (internally) recalculate the 1235,1235,1861,348 to 200,200,301,56 (more or less).
This has been implemented in API version 5 (#189). See:
Please let me know if you run into any issues.