Cloudinary offers multiple crop and resize options in both our Programmable Media and Media Optimizer products.
There's a full overview of the possible options available in our Transformations Documentation for Programmable Media and in the Transformations Reference for Media Optimizer
Three of the most commonly-used methods are the 'fill', 'fit', and 'limit' modes, each of which allow you to resize assets according to your requirements. The main difference between these methods is what happens when the requested output dimensions are a different size and aspect ratio to the original asset.
The fill crop mode creates an image with the exact width and height you specify, while retaining the original asset's aspect ratio. It may require cropping some of the input image to meet the requested output size, if the original asset is not the same aspect ratio. The output image can be bigger or smaller than the original asset.
When using the 'fill' mode, you can tell Cloudinary which part of the original image to focus on when cropping is required to produce the requested output size, and this is by passing the gravity parameter (or 'g' in URLs), which defines which part of the image to prioritize.
For example, the following 425x282 image was uploaded to Cloudinary.
The following URL applies the fill crop mode with the 600x200 dimensions, generating a 600x200 image with only part of the original image visible:
Applying the gravity option to this also, we can specify that any detected faces in the original input should be prioritized: https://res.cloudinary.com/demo/image/upload/c_fill,h_200,g_faces,w_600/face_left.jpg
The Fit mode changes the image's size to fit within a bounding box that's the specified width and height, while retaining the original asset's aspect ratio. All original parts of the original image will be visible, but as a result, the transformed image may be smaller than the specified width and height.
The following URL applies the fit crop mode with 600x200 dimensions, creating a derived version of the images that's 301x200, fitting within the requested dimensions and keeping all parts of the original input:
The following URL applies the fit crop mode with 600x400 dimensions, which generates a 600x398 image (scaling up the original image also):
The Limit mode is similar to the Fit mode, except that the the resulting image will never larger than the original input (in both height and width)
The following URL applies the limit crop mode with the same 600x400 dimensions as the 'fit' example above, this generates an image that keeps the original asset's 425x282 dimensions:
Thank you! That exactly what I was looking for some time (there is a mistake in "fit" text before the second URL: is "...the fill crop mode..." should be "...the fit crop mode..." ).
And the difference between "fill" and "thumb" ?
The `fill` crop mode will resize the original image and may crop either the width or the height in case the requested aspect ratio is different than the original:
When it comes together with the `face` or the `faces` gravity modes, the `thumb` crop mode will create a thumbnail cropped version, of the face(s) coordinates:
I want to prevent users to upload an image smaller than a given height and/or width so i don't have to upscale so much using one of the options explained above. Is this possible?
Thanks for reaching out to us and I would like to apologize for not responding sooner.
Yes, it is possible and the two options you are looking for are "min_image_height" and "min_image_width" in the upload widget options (http://cloudinary.com/documentation/upload_widget#upload_widget_options).
Thank you Daniel! That wil do the trick!
We are looking for a crop mode similar to "lfill" (limit fill) but that returns an image that respects the ratio of the size we requested. For example, if the original is 400x200 and we request a filled/cropped version of size 800x100, we would expect an image with a 8:1 ratio, without upscaling, with a size 400x50. Currently, "lfill" returns an image with size 400x100. It prevents upscaling correctly, but does not respect the requested ratio (4:1 instead of 8:1).
That is a very common case for us. Let's say we have a 800x100 container where we want to display the image. Because the original 400x200 image has the wrong ratio, when we display the image and scale it (dynamically at render time) to fill its container, the top and bottom will not be visible, so those hidden pixels are wasted. We are OK with the fact that the image will be blurry because of dynamic/render-time upscaling, but we don't want upscaling to happen on the server side, because it wastes bandwidth, disk-space and/or memory.
Do you have anything to handle that or something in your roadmap?
Thanks in advance for any info! :)
Its possible to use the `aspect_ratio` transformation in conjuncture with `lfill` to enforce an aspect ratio you want to retain.
Note If you specify both width and height either for `fill` or `lfill` crop modes then these would be the derived image's dimensions (assuming that the original image is larger then requested dimensions).
So in order to enforce an aspect ratio and also prevent upscaling if the original image is smaller then the requested dimensions, only one parameter of the dimensions should be specifically specified, in order for the aspect ratio to fit.
So something like the below might answer your use case.
Note that the original image's width is 283, but the enforced aspect ratio of 8:1 enforces a height of 50px since the requested height is 400px
Let us know if that helps?
Please sign in to leave a comment.