[RFC] next/image improvements for vector-like images

[mrmckeb]

By default, images are compressed with lossy-compression.

When working with WebP, we know that

Goals

Allow for opt-in lossless image compression.
Allow for dynamic image sizes.

Background

next/image is designed to provide great out-of-the-box defaults for images. For most cases, this works well.

For vector-like images (i.e. application screenshots, logos), the defaults can soften images, and even introduce small artefacts into those images. The defaults can also create larger images than we'd get by manually encoding an image with WebP Lossless.

The softness is mainly the result of scaling. In the below example, the images are 1320px wide, displayed at 660px width. This should be a clean 50% reduction, but instead the image is first scaled server-side to 750px wide (57%), then scaled in the browser to 660px wide (88%). This is most apparent on 1x displays (you can change that in DevTools to try to simulate the effect).

I've created this page as a simple demonstration of this (repo).
https://next-image-example.vercel.app/

Note that in this example, the avatar/shadows affect lossless compression size. This is a better example of where lossless would be effective:
https://next-image-example-g343p2ws1-uncurated-tests.vercel.app/

Proposal

1. Introduce a new prop, lossless, for situations where a user knows that lossless may result in a smaller file-size.
2. Support dynamic scaling, where images are scaled based on their display or source width, not a pre-defined list of device/image sizes.

Alternatives

• We could optimize these types of images by hand.
• We could list all possible widths within deviceSizes or imageSizes.

[mrmckeb]

@styfle suggested that we could do some further assessment with this:
https://github.com/filamentgroup/imaging-heap

[adrianmg]

I'm running into similar limitations with a couple of PNGs featuring circular gradients. The artifacts are pronounced even when quality=100.

I'd love to have a prop when using <Image> to enable near_lossless and/or lossless flags when converting to WebP.

[styfle]

I created #32106 since I forgot about this RFC 😅

Another alternative proposal is to use q={100} to indicate lossless mode. It could be a breaking change but it might be what most users expect. Its also how cloudinary enables lossless mode.

[adrianmg]

Another alternative is to use q={100} to indicate lossless mode

@styfle, I believe that's not working as expected. If I use quality={100}, I will be getting the same result as in scenario number 2 where banding starts becoming apparent.

---

1. Original PNG image (PNG): 795 KB

2. Optimized WebP quality=100: 83 KB

Using cwebp -q 100 image.png -o image.webp

3. Optimized WebP quality=100 -lossless: 441 KB

Using cwebp -q 90 image.png -o image.webp -lossless

4. Optimized WebP quality=90 -near_lossless 50: 421 KB

Using cwebp -q 90 image.png -o image.webp -near_lossless 50

---

I could go lower in quality to gain a bit more, but the correlation between enabling lossless and the banding is very apparent (almost) independently of the quality level.

[styfle]

I believe that's not working as expected

I'm not suggesting q=100 as a solution today. I'm suggesting that as an alternative proposal. Like you mentioned, lossless basically means q=100 so it could be a good indicator the user wants lossless quality too. That being said, the near_lossless feature might provide more flexibility since you could use both lossless compression and set a quality.

[adrianmg]

Thanks for clarifying! That's an interesting way of avoiding new props.

The trade-off will be not being able to adjust quality independently of enabling lossless 🤔

[Mohammed-Mounir]

Any news on providing lossless quality? or at least improving banding?

[predaytor]

Looking forward for this too.