3 ms·

Chrome advised and inspired this work in their position about JPEG XL. Here: https://www.mail-archive.com/blink-dev@chromium.org/msg04351.html https://www.mail

Chrome advised and inspired this work in their position about JPEG XL. Here: https://www.mail-archive.com/blink-dev@chromium.org/msg04351.html https://www.mail-archive.com/blink-dev@chromium.org/msg04351... "can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format" It's a yes! Of course full JPEG XL is quite a bit better still, but this helps old compatible JPEG to support HDR without 8-bit banding artefacts or gainmaps, gives a higher bit depth for other uses where more precision is valuable, and quite a bit better compression, too.

IshKebab 3y ago
Despite the answer being yes, IMO it's pretty clear that the question is disingenuous, otherwise why did they add support for WebP and AVIF? The question applies equally to them.
lxgr 3y ago
> "can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format" Only within pretty narrow limits. Classic JPEG will never be as efficient given its age, in the same way that LAME is doing incredible things for MP3 quality, but any mediocre AAC encoder still blows it out of the water. This is in addition to the things you've already mentioned (HDR) and other new features (support for lossless coding). And I'd find their sentiment much easier to believe if Google/Chrome weren't hell-bent on making WebP (or more recently AVIF) a thing themselves! That's two formats essentially nobody outside of Google has ever asked for, yet they're part of Chrome and Android.
simon_o 3y ago
> It's a yes! Reminds me of "You Scientists Were So Preoccupied With Whether Or Not You Could, You Didn't Stop To Think If You Should." The arithmetic coding feature was already painful enough. I'm simply not in need of yet another thing that makes jpeg files more complicated to deal with. > After weighing the data, we’ve decided to stop Chrome’s > JPEG XL experiment and remove the code associated with > the experiment. > We'll work to publish data in the next couple of weeks. Did that ever happen?
- JyrkiAlakuijala 3y ago
  I don't see any downsides with Jpegli. Your Linux distro admin exchanges the lib for you, you never need to think about it, only get smaller and more beautiful files. If you use commercial software (Apple, Adobe, mobile phone cameras, Microsoft, ...) hopefully they migrate by themselves. If they don't, literally nothing happens. I fail to see a major downside. Perhaps open up your thinking on this? Yes, Chrome published data.
  - simon_o 3y ago
    > you never need to think about it, only get smaller and more beautiful files People said the same thing last time and it took more than 10 years until decoding worked reliably. I'm simply not interested in dealing with another JPEG++. > Perhaps open up your thinking on this? Nah, I'm fine. I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.
    - JyrkiAlakuijala 3y ago
      It's not a new JPEG++. It creates old JPEGs, fully 100% compatible. (Of course JXL is better still.)
    - lxgr 3y ago
      > I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it. This makes your website only viewable on Safari (and by extension Apple devices) only, right?

IshKebab 3y ago

Despite the answer being yes, IMO it's pretty clear that the question is disingenuous, otherwise why did they add support for WebP and AVIF? The question applies equally to them.

lxgr 3y ago

> "can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format" Only within pretty narrow limits. Classic JPEG will never be as efficient given its age, in the same way that LAME is doing incredible things for MP3 quality, but any mediocre AAC encoder still blows it out of the water. This is in addition to the things you've already mentioned (HDR) and other new features (support for lossless coding). And I'd find their sentiment much easier to believe if Google/Chrome weren't hell-bent on making WebP (or more recently AVIF) a thing themselves! That's two formats essentially nobody outside of Google has ever asked for, yet they're part of Chrome and Android.

simon_o 3y ago

> It's a yes! Reminds me of "You Scientists Were So Preoccupied With Whether Or Not You Could, You Didn't Stop To Think If You Should." The arithmetic coding feature was already painful enough. I'm simply not in need of yet another thing that makes jpeg files more complicated to deal with. > After weighing the data, we’ve decided to stop Chrome’s > JPEG XL experiment and remove the code associated with > the experiment. > We'll work to publish data in the next couple of weeks. Did that ever happen?

JyrkiAlakuijala 3y ago
I don't see any downsides with Jpegli. Your Linux distro admin exchanges the lib for you, you never need to think about it, only get smaller and more beautiful files. If you use commercial software (Apple, Adobe, mobile phone cameras, Microsoft, ...) hopefully they migrate by themselves. If they don't, literally nothing happens. I fail to see a major downside. Perhaps open up your thinking on this? Yes, Chrome published data.
- simon_o 3y ago
  > you never need to think about it, only get smaller and more beautiful files People said the same thing last time and it took more than 10 years until decoding worked reliably. I'm simply not interested in dealing with another JPEG++. > Perhaps open up your thinking on this? Nah, I'm fine. I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.
  - JyrkiAlakuijala 3y ago
    It's not a new JPEG++. It creates old JPEGs, fully 100% compatible. (Of course JXL is better still.)
  - lxgr 3y ago
    > I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it. This makes your website only viewable on Safari (and by extension Apple devices) only, right?