I disagree. Making things slower for everyone due to this edge case is a bad tradeoff. Web APIs exist to let you know when zooming in happens. You can swap to a higher resolution, or even tiled image in these cases if you really care about this use-case.
Plethora means an excessive amount, so I disagree.
Adding formats to the browser gives us more code to maintain, increases the binary size, and increases the attack surface area. That's why, at Firefox, we insisted on a Rust decoder.
> gives us more code to maintain, increases the binary size
In that case, don't nanny everything as a monolith. Let formats/codecs can be installed as extension/plugin.
For example I really want to webrtc to f' off, I can't. I can't even disable it for a particular site like microphone permissions. It sucks!
And to my knowledge, webrtc stack is so much more complicated than an image format, so many sites trying to grab my private IP using webrtc. yet every browser vendor are happy to support it!
Browser vendors want their browser to be safe to use. If we encourage users to essentially bake their own browser from a hodge podge of unverified third party code running at high privilege, we don't meet that goal.
An image codec can be run in a sandboxed way, with a preset cpu/ram boundary, the output is rastered pixels, how could this not be "safe"?
There are dozens of .wasm based image encoder/decoders outthere, no?
It's not like it could access network or IO, unlike extensions do, which could steal your data after authors sell their popular extension and buys profits from stealing data from installed users.
> coded image items compliant to the AVIF Baseline profile may not have a number of pixels greater than 8912896, a width greater than 8192 or a height greater than 4352.
I'm assuming if both the encoder and decoder support more than the baseline profile, then higher resolutions up to 64k x 64k are possible, although I would worry the file would be incompatible with some software.
It's been a few years since I last tried, so hopefully no longer an issue, but trying to encode 8192 × 5464 images from a Canon R5 a few years ago with libavif, and avifEncoderAddImage() would return a generic error.
If I reduced the res a bit, then it worked, so there did seem to be a limit there somewhere. height and width are stored as u32s internally though, so yes, the format itself technically supports it...
I never looked into it more, so might have been a libavif issue, or maybe the way I was using it (maybe it has defaults or profiles?)
reply