28 ms·

DO NOT USE WEBP JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome). http

DO NOT USE WEBP JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome). https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss_comparing_jpeg_webp_jxl_and_avif/ https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss...

dragonwriter 1y ago
So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?
- Spivak 1y ago
  I mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses. At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
  - dragonwriter 1y ago
    > I mean if you define superior not in terms of its technical merits “Technical merits” are rarely, for anything, the sole measurement of fitness for purposes. Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality. I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
- Zardoz84 1y ago
  just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.
  - throw_m239339 1y ago
    > just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL. Doesn't a polyfill imply more Javascript running on the device?
    - BugsJustFindMe 1y ago
      Only until the browser gets updated and then the polyfill stops being invoked automatically. It's self-healing.
    - Zardoz84 1y ago
      Tt's a WASM . And really isn't very big. So if you need to store and serve many images files, potentially big images like in an preservation & diffusion software (like the stuff that I'm working), I felt that I could afford to pay the extra few KiBs on that WASM.
  - MrDOS 1y ago
    No need to bring JavaScript into it. In HTML, use `<picture>`: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... In CSS, use `image-set()`: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set https://developer.mozilla.org/en-US/docs/Web/CSS/image/image....
- alwillis 1y ago
  I get it but 2+ billion Apple device users is not nothin’. They can render JPEG-XL; everything else will render the fall back format like JPEG or WebP.
  - throw_m239339 1y ago
    Teams & developers will likely only chose a single format if they can, the one that most browsers support, because doing some content negotiation is more code, more work. It doesn't take away anything from the parent point though, if JPEG-XL is more performant it could reduce bandwidth requirements.
    - alwillis 1y ago
      > because doing some content negotiation is more code, more work It's actually not more work. The user's browser automatically handles the content negotiation and only downloads the image format it understands: <picture> <source srcset="photo.jxl" type="image/jxl"> <source srcset="photo.webp" type="image/webp"> <img src="photo.jpg" alt="Product photo" loading="lazy"> </picture> macOS, iPadOS and iOS get the JPEG-XL image, device that can handle WebP get that and everything else gets JPEG. There are several image delivery services that will provide the best image format depending on the device that's connecting.
palmfacehn 1y ago
I enjoy webp lossless mode
whywhywhywhy 1y ago
Upload a JPEG, gets converted to WEBP next person, downloads WEBP converts it to JPEG to actually edit it in software because even things like Photoshop/MacOS Preview can't edit one natively, saves to JPG and uploads, gets converted to WEBP next person downloads the now JPEG's WEBP'd JPEG'd WEBP'd image fast forward a decade the original quality versions of the images no longer exist just these degraded
- blooalien 1y ago
  Even if you have image editing software that directly supports WEBP format input / output, you still have the exact same problem, because (like JPEG) it's a lossy format which will lose fidelity with each successive generation of load / save over time. If you intend to edit an image, then the original (if possible) and it's edit should both be saved in a lossless format even if the final published output is saved in a lossy format. If no lossless format of the original is available, then the highest quality version of the original should be converted to a lossless format for "archival" before editing, and that copy should always be used for editing purposes, rather than piling loss upon loss editing the lossy format and re-saving. It's kinda like copies of copies of copies of MP3 audio. Eventually it becomes a soupy mess not worth using.
  - vunderba 1y ago
    Well... kinda. WebP is a bit of an unusual format in that it supports both lossy and lossless forms of compression. Most decent image editing software (Photoshop, Pixelmator, etc) will let you choose what you want. https://www.adobe.com/creativecloud/file-types/image/raster/webp-file.html https://www.adobe.com/creativecloud/file-types/image/raster/... But if you're not a professional it would be easy to mix up the two and slowly end up with VHS level degradation.
  - whywhywhywhy 1y ago
    doubles the speed of the degradation because the image is encoded on upload regardless of size and double stacks the encoding of artefacts
- xeonmc 1y ago
cogman10 1y ago
JPEG-XL is supported by exactly 1 browser. WebP and AV1F are supported by just about every browser. I'd love to use JPEG-XL, but I'm guessing the only way to do that is also bringing along a WASM decoder everywhere I want to use it.
- NoMoreNicksLeft 1y ago
  There are only two browsers, Safari and Firefox.
  - Acrobatic_Road 1y ago
    only Nightly
- caycep 1y ago
  due to above said nepotism... standards require some politicking and money I suppose
  - Arnt 1y ago
    Standards do require that. Someone has to show up at the right meetings and conferences, and it's often necessary to contribute code too. "Build it and they will come" doesn't work for products, and it doesn't work for standards either.
    - Arnt 1y ago
      ... and I want to add that there's no need to assume nepotism. If you get code merged into something like Chrome, and it's big and goes unused for a few years, at some point some security-minded person will come along and argue that your code is an unused attack surface and should be removed again.
      - simoncion 1y ago
        > ... and I want to add that there's no need to assume nepotism. Sure, and while this is true: > If you get code merged into something like Chrome, and it's big and goes unused for a few years [it's likely to get removed.] it's also true that Google could have pushed JPEG XL instead of pushing WebP, which would have massively increased the usage stats of the JPEG XL code and saved it from removal. But (for whatever reason) Google decided to set things up to push folks to use WebP at every turn, and here we are.
gjsman-1000 1y ago
JPEG XL is superior... just like how Betamax was visually superior.
- greenavocado 1y ago
  The main problem with your argument is the people want JPEG-XL. The main reason it is not in is purely due to Jim Bankoski's limited judgement, intelligence, and foresight. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
  - gjsman-1000 1y ago
    Just like how some people wanted Betamax. Politics drives adoption; not technical superiority.
    - greenavocado 1y ago
      Thankfully, unlike people and physical hardware, software and algorithms can lie in wait in perpetuity until they are resurrected when the political winds finally change course or favorable conditions for their spread emerge.
      - throw_m239339 1y ago
        > Thankfully, unlike people and physical hardware, software and algorithms can lie in wait in perpetuity until they are resurrected when the political winds finally change course or favorable conditions for their spread emerge. XHTML 2 is waiting on that one... Oh well...
    - izacus 1y ago
      "People" here are a tiny minority of techies that have emotional connection to the library they built and a group of OSSers which will take anything that bashes Google as a gospel. Everyone else... is fine with JPEG. And occasionally shares HEIC pictures from their iPhones.
frollogaston 1y ago
I'm not going to use webp or jpeg-xl.
- RankingMember 1y ago
  Yeah they're both a pain in that there's friction at all to open/use them.

dragonwriter 1y ago

So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?

Spivak 1y ago
I mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses. At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
- dragonwriter 1y ago
  > I mean if you define superior not in terms of its technical merits “Technical merits” are rarely, for anything, the sole measurement of fitness for purposes. Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality. I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
Zardoz84 1y ago
just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.
- throw_m239339 1y ago
  > just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL. Doesn't a polyfill imply more Javascript running on the device?
  - BugsJustFindMe 1y ago
    Only until the browser gets updated and then the polyfill stops being invoked automatically. It's self-healing.
  - Zardoz84 1y ago
    Tt's a WASM . And really isn't very big. So if you need to store and serve many images files, potentially big images like in an preservation & diffusion software (like the stuff that I'm working), I felt that I could afford to pay the extra few KiBs on that WASM.
- MrDOS 1y ago
  No need to bring JavaScript into it. In HTML, use `<picture>`: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... In CSS, use `image-set()`: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set https://developer.mozilla.org/en-US/docs/Web/CSS/image/image....
alwillis 1y ago
I get it but 2+ billion Apple device users is not nothin’. They can render JPEG-XL; everything else will render the fall back format like JPEG or WebP.
- throw_m239339 1y ago
  Teams & developers will likely only chose a single format if they can, the one that most browsers support, because doing some content negotiation is more code, more work. It doesn't take away anything from the parent point though, if JPEG-XL is more performant it could reduce bandwidth requirements.
  - alwillis 1y ago
    > because doing some content negotiation is more code, more work It's actually not more work. The user's browser automatically handles the content negotiation and only downloads the image format it understands: <picture> <source srcset="photo.jxl" type="image/jxl"> <source srcset="photo.webp" type="image/webp"> <img src="photo.jpg" alt="Product photo" loading="lazy"> </picture> macOS, iPadOS and iOS get the JPEG-XL image, device that can handle WebP get that and everything else gets JPEG. There are several image delivery services that will provide the best image format depending on the device that's connecting.

palmfacehn 1y ago

I enjoy webp lossless mode

whywhywhywhy 1y ago

Upload a JPEG, gets converted to WEBP next person, downloads WEBP converts it to JPEG to actually edit it in software because even things like Photoshop/MacOS Preview can't edit one natively, saves to JPG and uploads, gets converted to WEBP next person downloads the now JPEG's WEBP'd JPEG'd WEBP'd image fast forward a decade the original quality versions of the images no longer exist just these degraded

blooalien 1y ago
Even if you have image editing software that directly supports WEBP format input / output, you still have the exact same problem, because (like JPEG) it's a lossy format which will lose fidelity with each successive generation of load / save over time. If you intend to edit an image, then the original (if possible) and it's edit should both be saved in a lossless format even if the final published output is saved in a lossy format. If no lossless format of the original is available, then the highest quality version of the original should be converted to a lossless format for "archival" before editing, and that copy should always be used for editing purposes, rather than piling loss upon loss editing the lossy format and re-saving. It's kinda like copies of copies of copies of MP3 audio. Eventually it becomes a soupy mess not worth using.
- vunderba 1y ago
  Well... kinda. WebP is a bit of an unusual format in that it supports both lossy and lossless forms of compression. Most decent image editing software (Photoshop, Pixelmator, etc) will let you choose what you want. https://www.adobe.com/creativecloud/file-types/image/raster/webp-file.html https://www.adobe.com/creativecloud/file-types/image/raster/... But if you're not a professional it would be easy to mix up the two and slowly end up with VHS level degradation.
- whywhywhywhy 1y ago
  doubles the speed of the degradation because the image is encoded on upload regardless of size and double stacks the encoding of artefacts
xeonmc 1y ago

cogman10 1y ago

JPEG-XL is supported by exactly 1 browser. WebP and AV1F are supported by just about every browser. I'd love to use JPEG-XL, but I'm guessing the only way to do that is also bringing along a WASM decoder everywhere I want to use it.

NoMoreNicksLeft 1y ago
There are only two browsers, Safari and Firefox.
- Acrobatic_Road 1y ago
  only Nightly
caycep 1y ago
due to above said nepotism... standards require some politicking and money I suppose
- Arnt 1y ago
  Standards do require that. Someone has to show up at the right meetings and conferences, and it's often necessary to contribute code too. "Build it and they will come" doesn't work for products, and it doesn't work for standards either.
  - Arnt 1y ago
    ... and I want to add that there's no need to assume nepotism. If you get code merged into something like Chrome, and it's big and goes unused for a few years, at some point some security-minded person will come along and argue that your code is an unused attack surface and should be removed again.
    - simoncion 1y ago
      > ... and I want to add that there's no need to assume nepotism. Sure, and while this is true: > If you get code merged into something like Chrome, and it's big and goes unused for a few years [it's likely to get removed.] it's also true that Google could have pushed JPEG XL instead of pushing WebP, which would have massively increased the usage stats of the JPEG XL code and saved it from removal. But (for whatever reason) Google decided to set things up to push folks to use WebP at every turn, and here we are.

gjsman-1000 1y ago

JPEG XL is superior... just like how Betamax was visually superior.

greenavocado 1y ago
The main problem with your argument is the people want JPEG-XL. The main reason it is not in is purely due to Jim Bankoski's limited judgement, intelligence, and foresight. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
- gjsman-1000 1y ago
  Just like how some people wanted Betamax. Politics drives adoption; not technical superiority.
  - greenavocado 1y ago
    Thankfully, unlike people and physical hardware, software and algorithms can lie in wait in perpetuity until they are resurrected when the political winds finally change course or favorable conditions for their spread emerge.
    - throw_m239339 1y ago
      > Thankfully, unlike people and physical hardware, software and algorithms can lie in wait in perpetuity until they are resurrected when the political winds finally change course or favorable conditions for their spread emerge. XHTML 2 is waiting on that one... Oh well...
  - izacus 1y ago
    "People" here are a tiny minority of techies that have emotional connection to the library they built and a group of OSSers which will take anything that bashes Google as a gospel. Everyone else... is fine with JPEG. And occasionally shares HEIC pictures from their iPhones.

frollogaston 1y ago

I'm not going to use webp or jpeg-xl.

RankingMember 1y ago
Yeah they're both a pain in that there's friction at all to open/use them.