11 ms·

Chrome Jpegxl Issue Reopened

293 points by markdog12 10mo ago

markdog12 10mo ago
"Yes, re-opening.". > Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NmOyvMCCBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
- bigbuppo 10mo ago
  LOL. Google, the "yeah that thing we bought six months ago, we're killing it off 30 days for 4 weeks ago" company demanding "long-term" anything.
  - lonjil 10mo ago
    long term support is actually being provided by google... just a different team in a different country :D most jxl devs are at google research in zurich, and already pledged to handle long tetm support
    - malfist 10mo ago
      Just like google pledges long term support for everything until the next new and shiny comes along.
      - deleted 10mo ago
        [deleted]
      - tyre 10mo ago
        I think Chrome can safely be said to have a track record of long term investment.
        bigiain 10mo ago
        It is, after all, their primary ad delivery vector.
        josefx 10mo ago
        Very good track record there, native clients, floc, manifest v2, ...
  - rjh29 10mo ago
    That conversation doesn't apply to their core products: Search, Mail, Maps, Chrome, Android. Their commitment to maintaining these services over decades has been amazing. It's everything else that sucks.
    - professor_v 10mo ago
      Mail is dropping features left and right, like gmailify. I'm pretty sure they're trying to limit the maintenance costs as much as possible.
    - PaulHoule 10mo ago
      I could almost imagine the normal search going away to be replaced by a chatbot.
- concinds 10mo ago
  Context: Mozilla has had the same stance and many devs (including Googlers) are already working on a Rust decoder which has made good progress.
claudiojulio 10mo ago
[flagged]
- deleted 10mo ago
  [deleted]
- fsflover 10mo ago
  This comment is of course breaking the HN Guidelines as a shallow dismissal, but the parent is right: After Google killed Ublock Origin and turned Android into a nanny OS, I have no idea why anyone would stick to anything from them. Also Firefox is better in almost every way.
wizee 10mo ago
JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support JPEG-XL in favour of AVIF which they were pushing. I’m glad to hear they’re finally reconsidering. Let’s hope this leads to resources being dedicated to help build and maintain a performant and memory safe decoder (in Rust?).
- kps 10mo ago
  > (in Rust?) Looks like that's the idea: https://issues.chromium.org/issues/462919304 https://issues.chromium.org/issues/462919304
- homebrewer 10mo ago
  It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just an av1 key frame. Every browser needs an av1 decoder already unless it's willing to forego users who would like to be able to watch Netflix and YouTube.
  - jnd-cz 10mo ago
    Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
    - arccy 10mo ago
      if you actually read your parent comment: "typical web image quality"
FerritMans 10mo ago
Love this, been waiting for Google to integrate this, from my experience with AVIF and JPEGXL, JPEGXL is much more promising for the next 20years.
masswerk 10mo ago
Nice example for how a standard, like PDF, can even persuade/force one of the mighty to adopt a crucial bit of technology, so that this may become a common standard in its own right (i.e. "cascading standards").
ChrisArchitect 10mo ago
[dupe] https://news.ycombinator.com/item?id=46021179 https://news.ycombinator.com/item?id=46021179
crazygringo 10mo ago
Dupe. From yesterday (183 points, 82 comments): https://news.ycombinator.com/item?id=46021179 https://news.ycombinator.com/item?id=46021179
- markdog12 10mo ago
  Ah, I think I searched for "jpegxl", that's why there was no match.
Pxtl 10mo ago
> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.
- F3nd0 10mo ago
  If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that. The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.
  - Dwedit 10mo ago
    Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression. Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.
    - lonjil 10mo ago
      Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.
albert_e 10mo ago
> Chrome Jpegxl Issue Reopened > (this is the tracking bug for this feature) Is it just me -- or it's confusing to use the terms issue / bug / feature interchangeably?
- mort96 10mo ago
  It's not really used interchangeably: "bug" is used to mean "entry in the bug tracker database", while "feature" is used to mean what we colloquially think of as a feature of a computer program. It's arguably a slight abuse of a bug tracking system to also track progress and discussion on features, but it's not exactly uncommon; it's just that many systems would call it an "issue" rather than a "bug".
- nandomrumber 10mo ago
  Maybe more like a heading bug: https://aviation.stackexchange.com/questions/23166/what-is-the-use-of-heading-bug https://aviation.stackexchange.com/questions/23166/what-is-t...
- crazygringo 10mo ago
  Not really -- they're all "potential todos" that need to be tracked and prioritized in the same place. And the difference between a bug and a feature is often in the eye of the beholder. I'll very often title a GitHub issue with "Bug/Feature Request:" since it's often debatable whether the existing behavior was by design or not, and I don't want to presume one way or the other. So I do consider them all pretty interchangeable at the end of the day, and therefore not really confusing.
- _jzlw 10mo ago
  Google's internal issue tracker, Buganizer (which the Chromium Issue Tracker is based on), refers to everything as a "bug". It's confusing, yeah. You get used to it.
gen2brain 10mo ago
I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.
gethly 10mo ago
jpg -> png -> webp -> avif Why are we going backward?
- hxtk 10mo ago
  JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains unusable until fully downloaded.
  - gethly 10mo ago
    Seems like a very small advantage to warrant all the necessary work needed to make it mainstream. Who would use it as advanced image format when a person that would be interested in such a thing would likely already be handling webp or avif?
h1fra 10mo ago
Webp was a nice new format now widely adopted in browsers, yet it's barely supported in websites (upload) and softwares. It's hard to see this being different.
- spaceducks 10mo ago
  WebP is much more limiting than JPEG XL. in lossy mode WebP has forced 4:2:0 chroma subsampling, supports only 8 bit per channel colors (really only about 7.8 bits, because thanks to WebP being tv-range the values aren't in a 0-255 range but in a 16-235 range, causing even more color banding than 8 bit per channel already has), no HDR, a maximum resolution of 16385 x 16385 making it unsuitable for larger images... JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc. WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.
  - networked 10mo ago
    I didn't realize WebP was limited-RGB in addition to 4:2:0. According to RFC 9649, this is accurate. While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB: > The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.
jlouis 10mo ago
This is welcome. AVIF is trying to be a distribution format for the Web. JPEG XL is trying to be a complete package for working with image data. JPEG XL can replace OpenEXR in many workflows. AVIF simply cannot. There's a lot of power in not having to convert for distribution.
Andrew-Tate 10mo ago
[dead]

293 points by markdog12 10mo ago

"Yes, re-opening.". > Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NmOyvMCCBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

bigbuppo 10mo ago
LOL. Google, the "yeah that thing we bought six months ago, we're killing it off 30 days for 4 weeks ago" company demanding "long-term" anything.
- lonjil 10mo ago
  long term support is actually being provided by google... just a different team in a different country :D most jxl devs are at google research in zurich, and already pledged to handle long tetm support
  - malfist 10mo ago
    Just like google pledges long term support for everything until the next new and shiny comes along.
    - deleted 10mo ago
      [deleted]
    - tyre 10mo ago
      I think Chrome can safely be said to have a track record of long term investment.
      - bigiain 10mo ago
        It is, after all, their primary ad delivery vector.
      - josefx 10mo ago
        Very good track record there, native clients, floc, manifest v2, ...
- rjh29 10mo ago
  That conversation doesn't apply to their core products: Search, Mail, Maps, Chrome, Android. Their commitment to maintaining these services over decades has been amazing. It's everything else that sucks.
  - professor_v 10mo ago
    Mail is dropping features left and right, like gmailify. I'm pretty sure they're trying to limit the maintenance costs as much as possible.
  - PaulHoule 10mo ago
    I could almost imagine the normal search going away to be replaced by a chatbot.
concinds 10mo ago
Context: Mozilla has had the same stance and many devs (including Googlers) are already working on a Rust decoder which has made good progress.

claudiojulio 10mo ago

[flagged]

deleted 10mo ago
[deleted]
fsflover 10mo ago
This comment is of course breaking the HN Guidelines as a shallow dismissal, but the parent is right: After Google killed Ublock Origin and turned Android into a nanny OS, I have no idea why anyone would stick to anything from them. Also Firefox is better in almost every way.

wizee 10mo ago

JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support JPEG-XL in favour of AVIF which they were pushing. I’m glad to hear they’re finally reconsidering. Let’s hope this leads to resources being dedicated to help build and maintain a performant and memory safe decoder (in Rust?).

kps 10mo ago
> (in Rust?) Looks like that's the idea: https://issues.chromium.org/issues/462919304 https://issues.chromium.org/issues/462919304
homebrewer 10mo ago
It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just an av1 key frame. Every browser needs an av1 decoder already unless it's willing to forego users who would like to be able to watch Netflix and YouTube.
- jnd-cz 10mo ago
  Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
  - arccy 10mo ago
    if you actually read your parent comment: "typical web image quality"

FerritMans 10mo ago

Love this, been waiting for Google to integrate this, from my experience with AVIF and JPEGXL, JPEGXL is much more promising for the next 20years.

masswerk 10mo ago

Nice example for how a standard, like PDF, can even persuade/force one of the mighty to adopt a crucial bit of technology, so that this may become a common standard in its own right (i.e. "cascading standards").

ChrisArchitect 10mo ago

[dupe] https://news.ycombinator.com/item?id=46021179 https://news.ycombinator.com/item?id=46021179

crazygringo 10mo ago

Dupe. From yesterday (183 points, 82 comments): https://news.ycombinator.com/item?id=46021179 https://news.ycombinator.com/item?id=46021179

markdog12 10mo ago
Ah, I think I searched for "jpegxl", that's why there was no match.

Pxtl 10mo ago

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.

F3nd0 10mo ago
If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that. The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.
- Dwedit 10mo ago
  Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression. Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.
  - lonjil 10mo ago
    Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.

albert_e 10mo ago

> Chrome Jpegxl Issue Reopened > (this is the tracking bug for this feature) Is it just me -- or it's confusing to use the terms issue / bug / feature interchangeably?

mort96 10mo ago
It's not really used interchangeably: "bug" is used to mean "entry in the bug tracker database", while "feature" is used to mean what we colloquially think of as a feature of a computer program. It's arguably a slight abuse of a bug tracking system to also track progress and discussion on features, but it's not exactly uncommon; it's just that many systems would call it an "issue" rather than a "bug".
nandomrumber 10mo ago
Maybe more like a heading bug: https://aviation.stackexchange.com/questions/23166/what-is-the-use-of-heading-bug https://aviation.stackexchange.com/questions/23166/what-is-t...
crazygringo 10mo ago
Not really -- they're all "potential todos" that need to be tracked and prioritized in the same place. And the difference between a bug and a feature is often in the eye of the beholder. I'll very often title a GitHub issue with "Bug/Feature Request:" since it's often debatable whether the existing behavior was by design or not, and I don't want to presume one way or the other. So I do consider them all pretty interchangeable at the end of the day, and therefore not really confusing.
_jzlw 10mo ago
Google's internal issue tracker, Buganizer (which the Chromium Issue Tracker is based on), refers to everything as a "bug". It's confusing, yeah. You get used to it.

gen2brain 10mo ago

I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.

gethly 10mo ago

jpg -> png -> webp -> avif Why are we going backward?

hxtk 10mo ago
JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains unusable until fully downloaded.
- gethly 10mo ago
  Seems like a very small advantage to warrant all the necessary work needed to make it mainstream. Who would use it as advanced image format when a person that would be interested in such a thing would likely already be handling webp or avif?

h1fra 10mo ago

Webp was a nice new format now widely adopted in browsers, yet it's barely supported in websites (upload) and softwares. It's hard to see this being different.

spaceducks 10mo ago
WebP is much more limiting than JPEG XL. in lossy mode WebP has forced 4:2:0 chroma subsampling, supports only 8 bit per channel colors (really only about 7.8 bits, because thanks to WebP being tv-range the values aren't in a 0-255 range but in a 16-235 range, causing even more color banding than 8 bit per channel already has), no HDR, a maximum resolution of 16385 x 16385 making it unsuitable for larger images... JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc. WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.
- networked 10mo ago
  I didn't realize WebP was limited-RGB in addition to 4:2:0. According to RFC 9649, this is accurate. While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB: > The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.

jlouis 10mo ago

This is welcome. AVIF is trying to be a distribution format for the Web. JPEG XL is trying to be a complete package for working with image data. JPEG XL can replace OpenEXR in many workflows. AVIF simply cannot. There's a lot of power in not having to convert for distribution.

Andrew-Tate 10mo ago

[dead]