Mozilla Comes Out Neutral On JPEG-XL Image Format Support

[quikee]

If you tell the browser to download an image, it will download the whole image. There is no functionality within HTML to just tell the browser to download a partial image file. You don't understand how web works.

HTTP has chunked transfer, so there is no limit in the protocol to do that. Other than that it's just a matter of implementation in the browser how it fetches the images.

How "web works" is being changed numerous times and is changed all the time when existing ways to do things are improved and new features are added. This is just one of those instances where we can again improve the web.

Progressive decoding is not about optimizing the amount of downloaded data, it is about providing meaningful content for users in as little time as possible.

Well this just shows that you can't think outside of the box.

[quikee]

WebP can use either VP8 or VP9.

WebP doesn't use and never has used VP9. If this were true then the format would actually be decent.
Might be a good idea to get your facts straight first before you accuse other people of showing a lack of knowledge.

[Artim]

WebP doesn't use and never has used VP9. If this were true then the format would actually be decent.
Might be a good idea to get your facts straight first before you accuse other people of showing a lack of knowledge.

Still, transcoding to WebP seems to be still easier than to anything else. Or why do you think the thumbnails are done as WebP.

Anyways, in the long run, WebP and VP9 will be replaced by AV1 and AVIF.

[Quackdoc]

WebP doesn't use and never has used VP9. If this were true then the format would actually be decent.
Might be a good idea to get your facts straight first before you accuse other people of showing a lack of knowledge.

well somewhat decent

[billyswong]

If you tell the browser to download an image, it will download the whole image. There is no functionality within HTML to just tell the browser to download a partial image file. You don't understand how web works. Progressive decoding is not about optimizing the amount of downloaded data, it is about providing meaningful content for users in as little time as possible.

It could be done on server side by intelligently feeding different amount of the same file by different file request. A baseline for "100%/96dpi", extra data chunk for "150%/144dpi", another for "200%/192dpi", and so on. The infrastructure to fetch different "file" for different monitor dpi in browser client side is already there.

[Anux]

It could be done on server side by intelligently feeding different amount of the same file by different file request. A baseline for "100%/96dpi", extra data chunk for "150%/144dpi", another for "200%/192dpi", and so on. The infrastructure to fetch different "file" for different monitor dpi in browser client side is already there.

It would be much more useful, if the browser itself decides how much to fetch. The server doesn't need to know my resolution and DPI, we already have to many details aviable for fingerprinting.

[quikee]

Still, transcoding to WebP seems to be still easier than to anything else. Or why do you think the thumbnails are done as WebP.

Because WebP doesn't fall apart at very high compression rations (which is what video codecs are good at because at 24+ FPS you won't notice the details anyway) and for thumbnails quality isn't important. There are uses for WebP and AVIF, but they are not good general purpose image codecs, but they are still shoveled down our throats on the web, while at the same time the only candidate of an image codec that is flexible and covers wide variety of use cases is being intentionally pushed out of web usage.

[hotaru]

Because WebP doesn't fall apart at very high compression rations (which is what video codecs are good at because at 24+ FPS you won't notice the details anyway) and for thumbnails quality isn't important. There are uses for WebP and AVIF, but they are not good general purpose image codecs, but they are still shoveled down our throats on the web, while at the same time the only candidate of an image codec that is flexible and covers wide variety of use cases is being intentionally pushed out of web usage.

WebP is great at one thing: it's lossless mode is better than PNG and JPEG XL's lossless mode. meanwhile AVIF usually ends up 2-5 times as big as PNG.

for photos, WebP just doesn't look good, and AVIF is usually 1.5-2 times the size of JPEG XL.

it seems like the only thing AVIF is good at is video thumbnails, but even there WebP is usually a better choice.

[Quackdoc]

WebP is great at one thing: it's lossless mode is better than PNG and JPEG XL's lossless mode.

for specific images, webp only supports RGBA8 yuv(a)420p. this means for 10bit images and greater webp isn't actually lossless. also I find JXL lossless to be better for colored comics. but not B&W

it seems like the only thing AVIF is good at is video thumbnails, but even there WebP is usually a better choice.

AVIF wins at extremely low BPP, so if for some reason you need to really kill the quality of an image it will beat out JXL, but I find its qualities I would never be comfortable serving. so AVIF is good for that and animated photos

[Artim]

Because WebP doesn't fall apart at very high compression rations (which is what video codecs are good at because at 24+ FPS you won't notice the details anyway) and for thumbnails quality isn't important. There are uses for WebP and AVIF, but they are not good general purpose image codecs, but they are still shoveled down our throats on the web, while at the same time the only candidate of an image codec that is flexible and covers wide variety of use cases is being intentionally pushed out of web usage.

And this is utter bullshit.