Mozilla Comes Out Neutral On JPEG-XL Image Format Support

[Quackdoc]

And this is utter bullshit.

says the man who said webp supported vp9 lol

[Artim]

says the man who said webp supported vp9 lol

Just say you don't have any real world proof for the nonsense you tell, only some benchmarks that have nothing to do with the real world🤷♂️

[Quackdoc]

Just say you don't have any real world proof for the nonsense you tell, only some benchmarks that have nothing to do with the real world🤷♂️

considering your terminology of real world use doesn't align with the real world, im not sure what you even want.

[Artim]

considering your terminology of real world use doesn't align with the real world, im not sure what you even want.

My terminology does perfectly align with the real world. It's a very simple fact that can be tested by anybody that the quality of WebP isn't nearly as bad as you want to have people think. Especially in real world use cases where you don't pixel peep.

[Quackdoc]

My terminology does perfectly align with the real world. It's a very simple fact that can be tested by anybody that the quality of WebP isn't nearly as bad as you want to have people think. Especially in real world use cases where you don't pixel peep.

I've already told you that in ssimulacra2 webp and mozjpeg preformed similar across the varying bpp except for the very low end which apparently is not "real world use:, it's also noted in siipo.la's comparison that webp only beat mozjpeg consistently in small files (500px) when using the dssim tool (though it only tested a target quality of 85, so I don't consider this a good study, but it has been quoted on occasion).

Mozilla had done a test comparing webp to libjpeg, (an inferior encoder to mozjpeg) and found that even with libjpeg, webp was indeed better, but not extraordinarily so. this is now a dead page, but IIRC it's probably on the archive. but when you extrapolate that to mpozjpeg vs libjpeg tests, they would probably be fairly similar there too.

but all these test's use varying metrics, which apparently are not "real world", so I don't have any "real world" testing by whatever definition you want to give it

[Artim]

I've already told you that in ssimulacra2 webp and mozjpeg preformed similar across the varying bpp except for the very low end which apparently is not "real world use:, it's also noted in siipo.la's comparison that webp only beat mozjpeg consistently in small files (500px) when using the dssim tool (though it only tested a target quality of 85, so I don't consider this a good study, but it has been quoted on occasion).

Mozilla had done a test comparing webp to libjpeg, (an inferior encoder to mozjpeg) and found that even with libjpeg, webp was indeed better, but not extraordinarily so. this is now a dead page, but IIRC it's probably on the archive. but when you extrapolate that to mpozjpeg vs libjpeg tests, they would probably be fairly similar there too.

but all these test's use varying metrics, which apparently are not "real world", so I don't have any "real world" testing by whatever definition you want to give it

Indeed they are not real world. Real world tests are tests with a representative group of real world people comparing them in real world scenarios like browsing the web on a desktop/laptop or a phone, because that's how it will be used on the end.

[billyswong]

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.

There won't be any data quota saving or bandwidth saving if the browser doesn't tell servers how much data it want. Servers can't send less data for lower dpi devices without knowing beforehand. Even if you only cut off in the middle of transmission, it is still either you save no data quota, or you leak your resolution / dpi.

However, JXL is indeed capable of making fingerprinting harder. For devices without bandwidth or data cap concern, browsers will be free to fake itself as running in higher dpi, then chop off the ending portion of the image file without degrading the visual quality. Currently, multiple images for each dpi ask for completely different image files. The cost of faking a higher dpi devices is higher than what JXL will be able to offer.

[Draget]

I am sorry for the language I am about to use and do have a deeper insight into the whole topic and - I believe - a somewhat well evaluated opinion. But that all kind of boils down to one sentence right now:

Fuck you Google.

They threw in their weight, Mozilla does not have the balls, the story is kind of over. Argh!

[Artim]

I am sorry for the language I am about to use and do have a deeper insight into the whole topic and - I believe - a somewhat well evaluated opinion. But that all kind of boils down to one sentence right now:

Fuck you Google.

They threw in their weight, Mozilla does not have the balls, the story is kind of over. Argh!

Wow. 10 pages of discussion and you still tell those lies. Do you at least have any proof for those wild accusations?

[Quackdoc]

They threw in their weight, Mozilla does not have the balls, the story is kind of over. Argh!

I wouldn't say that mozilla doesn't have the balls, its more like they couldn't be asked to waste any more resources that they couldn't pocket for themselves. I wouldn't really blame google either, just blame mozilla for not being the same mozilla it once was. google can take blame for google crap. but not moz's