Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combine cropping with resizing #176

Sewdn opened this issue Mar 25, 2019 · 5 comments


Copy link

commented Mar 25, 2019


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:

  1. Cropped area from a hires image:,1235,1861,348

  2. trying to resize the same cropped area into a 200x200 square,1235,1861,348&w=200&h=200&t=fit

  3. this gives the same result as when leaving out the crop parameter:

  4. doing it with another queryParam sequence (crop after resize params), results in cropping after resizing:,2783,348,348

For me this is weird, because:

  • queryparam order shouldn't influence the result
  • transformations should always be relative to original image
  • crop parameter is skipped in (2), not respecting the specification/documentation

Thanks for your feedback!

@kleisauke kleisauke self-assigned this Mar 27, 2019

@kleisauke kleisauke added the question label Mar 27, 2019


This comment has been minimized.

Copy link

commented Mar 27, 2019

As stated in the documentation, the manual crop is performed after the resize operation. For example:,200,301,56

I agree that this is not clearly stated. I'll try to improve the documentation in the next API (sneak preview here:

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. &precrop) that recalculates the crop coordinates and target width/height so that it exhibits the same behavior as you expect. This requires some adjustments in the image processing pipeline.


This comment has been minimized.

Copy link

commented Apr 3, 2019

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

But still 2 other issues remain imo:

  • the order of the queryparams shouldnt influence the result
  • crop queryparam is skipped when it is not listed before the resize params

This comment has been minimized.

Copy link

commented Sep 16, 2019

This has been implemented in API version 5 (#189). See:

Please let me know if you run into any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.