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

[css-images] Specific algorithms for image-rendering #6252

Open
progers opened this issue Apr 29, 2021 · 3 comments
Open

[css-images] Specific algorithms for image-rendering #6252

progers opened this issue Apr 29, 2021 · 3 comments
Labels
css-images-3 Current Work

Comments

@progers
Copy link
Contributor

progers commented Apr 29, 2021

The image-rendering property supports values such as smooth and high-quality but these are not specific enough. Bilinear is preferable in some cases (example), but not others, and we get bugs about this in chrome (crbug.com/562162). To change our defaults to be cubic in more cases, we need a way for users to request other algorithms.

Could we support the following new values for image-rendering?

  • nearest-neighbor
  • bilinear
  • trilinear (using mipmaps)
  • cubic-catmull-rom

The first three of these are ubiquitous and are typically available in hardware. An alternative to cubic-catmull-rom is to just specify cubic and leave the details up to implementations (see this page).

@svgeesus
Copy link
Contributor

I agree that more user control is desirable. sinc aka Lanczos resampling should also be considered.

I also agree that bicubic catmull-rom is the more generally applicable of the various cubic options.

Lastly, an opt-in to specify resampling in linear-light rather than gamma-encoded space is desirable. The demo page you linked for bicubic casually mentions this was done but does not show the result of not doing it.

@Lorp
Copy link

Lorp commented Apr 30, 2021

Would it make sense to allow a comma-separated list of methods, where the first available is used, e.g.

image-rendering: funky-resampling, cubic-catmull-rom, trilinear, high-quality;

@tabatkins
Copy link
Member

Currently the values are intentionally vague because implementations didn't want to require specific algorithms, both because it would potentially require more implementation work they didn't think was very necessary, and because they wanted the freedom to upgrade and downgrade their scaling algorithms as needed to accommodate the page and device load.

I'm happy to add more specific algorithm requirements (possibly behind specifically-named keywords), but I'd want some impl support beyond Chrome. ^_^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-images-3 Current Work
Projects
None yet
Development

No branches or pull requests

4 participants