There were a lot of primitives we built to ship image resizing - Storage events exposed via webhooks, rate limiting, a queue on top of Postgres, a smart CDN cache, object metadata endpoints, etc. These are already available if you are self hosting Supabase Storage, so that you can integrate your own CDN, listen to storage events, etc. Over the next few months, we will be working on exposing these on the Supabase platform too.
In nearly two decades developing for the web, I've never found a good reason to enlarge an image server-side, so thank you for anticipating that footgun. So many of your competitors get it wrong.
However, it's unclear from the docs [0] if one of the most common use cases is supported: requesting an image at a specific aspect ratio while not exceeding a maximum size.
For instance, I want a 1600×900px hero image at the top of my blog posts, but my source image is only 1200px wide. I request:
Will the returned image be 675px tall, maintaining the 16×9 aspect ratio I want?
A few more notes:
The blog post states "default mode maintains aspect ratio and the resize mode is fill", but the docs say that cover is the default mode.
The docs say, "If only one [width or height] parameter is specified, the image will be resized and cropped, maintaining the aspect ratio." I believe that with only one parameter, you could either resize or crop, but not both. I hope it's resize.
For cropping modes, is it always from the center? Are there plans to support other "gravity" modes?
Thank you for following up. IMHO, object-fit is not the right model for server-side image manipulation, since its behavior is only specified when both width and height are supplied. I've also never seen a real world use case for stretching, squeezing, padding, or enlarging images on the server. That should be done on the client. I mentioned some of the same issues on the Cloudflare forum when they announced an image resizing product based on object-fit.
I believe all resizing operations a user might realistically want can be achieved with three parameters: width, height, and crop. Additional x and y parameters (floats between 0.0 and 1.0) could be used for setting the focal point of the crop box.
Examples:
source.jpg?width=400
Iff source width is greater than 400px, scale down to 400px wide.
source.jpg?height=300
Iff source height is greater than 300px, scale down to 300px high.
source.jpg?width=400&height=300
Iff source width is greater than 400px or source height is greater than 300px, scale down to fit within a 400px by 300px box.
source.jpg?width=400&height=300&crop=true
Crop source to a 4x3 aspect ratio. Iff result is larger than 400px by 300px, scale down.
actually, image upsizing is pretty much required for all of the AI Art generators. was even a big feature in SD 2.0. i'd love to have it as part of this API but itd probably cost too much
We assessed a few resizing tools - imgproxy, Imaginary, Sharp, etc. We went with imgproxy mostly because of it's feature-completeness (for example, it supports AVIF and it looks like nginx does not)
Yes! If you resize your images correctly, your users use lesser data to load assets from Storage. A side benefit is you will be paying us lesser in egress fees.
There were a lot of primitives we built to ship image resizing - Storage events exposed via webhooks, rate limiting, a queue on top of Postgres, a smart CDN cache, object metadata endpoints, etc. These are already available if you are self hosting Supabase Storage, so that you can integrate your own CDN, listen to storage events, etc. Over the next few months, we will be working on exposing these on the Supabase platform too.