4 ms·

JPEG: No active patents, universal support, good enough. HEIC: Have fun licensing this. WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma re

JPEG: No active patents, universal support, good enough. HEIC: Have fun licensing this. WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma resolution in lossy mode so some JPEGs will always look better than the equivalent WebP. AVIF: Better than JPEG probably, but encoders for AV1 are currently heavily biased towards blurring, even at very high bitrates. Non-Chrome browser support took a while.

_kidlike 1y ago
what about PNG?
- kccqzy 1y ago
  Apples and oranges. PNGs aren't used for photographic images. It's good for line art, certain cartoons, pixel art and the like.
- zargon 1y ago
  Entirely different category.
llm_nerd 1y ago
JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open. You can even "losslessly" compress existing JPEGs to JPEGXL. JPEG XL is the natural replacement for JPEG and it is perverse that Google backtracked on supporting it.
- deleted 1y ago
  [deleted]
- addaon 1y ago
  > JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open. And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.
  - llm_nerd 1y ago
    If we were talking about some abstract hypothetical format, this is entirely reasonable. Only there are a number of extremely high quality JPEG XL decoders. There is zero need for hardware assistance for decoding JPEG or JPEG XL, so that difference is a non-difference. Every device in the world with iOS 17 or macOS 14 or better has JPEG XL support across the system. This is a complete and utter non-issue. Google had even added JPEG XL support to Chromium, and then bizarrely removed it (not long before Apple fully supported JXL across all their platforms which invariably would have pushed it over the top), presumably to try to anoint WebP as the successor. Only WebP has so many disadvantages that all they did was entrench classic JPEG. JPEG XL is unquestionably the best current next gen format for images.
    - addaon 1y ago
      > There is zero need for hardware assistance for decoding JPEG or JPEG XL, so that difference is a non-difference. This depends on the system requirements, doesn't it? Suppose you're compositing a low-safety-impact video stream with (well, under) safety-impacting information in an avionics application, and you're currently using a direct GMSL link. There's an obvious opportunity to cost-down and weight-down the system by shifting to a lightly compressed stream over an existing shared Ethernet bus, and MJPEG is a reasonable option for this application (as is H.264, and other options -- trade study needed). When considering replacing JPEG with JPEG XL in this implementation, what's your plan for providing partitioning between the "extremely high quality" but QM software implementation and the DAL components? Are you going to dedicate a core to avoid timing interference? At that point you're spending more silicon than a dedicated JPEG decoder would take. You likely already have an FPGA in the system for doing the compositing itself, but what's the area trade-off between an existing "extremely high quality" JPEG XL hardware decoder and the JPEG one that you've been using for decades? I don't doubt that in a world where everything is an iPhone (with a token nod to Android), "someone already wrote the code once and it's good enough" is sufficient. But there's a huge field of software engineering where complexity and quality drive decision making, and JPEG XL really is much more complex than JPEG Classic Flavor.
  - eviks 1y ago
dylan604 1y ago
Sometimes a format is simply just good enough. The gains that WebP may or may not have definitely do not get it over the hump of being so tied to a browser. AVIF is still very new, but other than the anim stuff, is it enough of an improvement to get people to switch. And that brings me to the entire corpus of existing files. A JPEG decoder will always be necessary based on the amount of preexisting files requiring it. If you have to support JPEG for some, might as well continue making new in the same format as well.
- frollogaston 1y ago
  "Do I look like ah know what a web-P is? I just want a jaypeg of a gosh darn hotdog!" is my attitude on this

_kidlike 1y ago

what about PNG?

kccqzy 1y ago
Apples and oranges. PNGs aren't used for photographic images. It's good for line art, certain cartoons, pixel art and the like.
zargon 1y ago
Entirely different category.

llm_nerd 1y ago

JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open. You can even "losslessly" compress existing JPEGs to JPEGXL. JPEG XL is the natural replacement for JPEG and it is perverse that Google backtracked on supporting it.

deleted 1y ago
[deleted]
addaon 1y ago
> JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open. And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.
- llm_nerd 1y ago
  If we were talking about some abstract hypothetical format, this is entirely reasonable. Only there are a number of extremely high quality JPEG XL decoders. There is zero need for hardware assistance for decoding JPEG or JPEG XL, so that difference is a non-difference. Every device in the world with iOS 17 or macOS 14 or better has JPEG XL support across the system. This is a complete and utter non-issue. Google had even added JPEG XL support to Chromium, and then bizarrely removed it (not long before Apple fully supported JXL across all their platforms which invariably would have pushed it over the top), presumably to try to anoint WebP as the successor. Only WebP has so many disadvantages that all they did was entrench classic JPEG. JPEG XL is unquestionably the best current next gen format for images.
  - addaon 1y ago
    > There is zero need for hardware assistance for decoding JPEG or JPEG XL, so that difference is a non-difference. This depends on the system requirements, doesn't it? Suppose you're compositing a low-safety-impact video stream with (well, under) safety-impacting information in an avionics application, and you're currently using a direct GMSL link. There's an obvious opportunity to cost-down and weight-down the system by shifting to a lightly compressed stream over an existing shared Ethernet bus, and MJPEG is a reasonable option for this application (as is H.264, and other options -- trade study needed). When considering replacing JPEG with JPEG XL in this implementation, what's your plan for providing partitioning between the "extremely high quality" but QM software implementation and the DAL components? Are you going to dedicate a core to avoid timing interference? At that point you're spending more silicon than a dedicated JPEG decoder would take. You likely already have an FPGA in the system for doing the compositing itself, but what's the area trade-off between an existing "extremely high quality" JPEG XL hardware decoder and the JPEG one that you've been using for decades? I don't doubt that in a world where everything is an iPhone (with a token nod to Android), "someone already wrote the code once and it's good enough" is sufficient. But there's a huge field of software engineering where complexity and quality drive decision making, and JPEG XL really is much more complex than JPEG Classic Flavor.
- eviks 1y ago

dylan604 1y ago

Sometimes a format is simply just good enough. The gains that WebP may or may not have definitely do not get it over the hump of being so tied to a browser. AVIF is still very new, but other than the anim stuff, is it enough of an improvement to get people to switch. And that brings me to the entire corpus of existing files. A JPEG decoder will always be necessary based on the amount of preexisting files requiring it. If you have to support JPEG for some, might as well continue making new in the same format as well.

frollogaston 1y ago
"Do I look like ah know what a web-P is? I just want a jaypeg of a gosh darn hotdog!" is my attitude on this