33 ms·

Request: Re-open JPEG XL issue

302 points by blurred 3y ago

edandersen 3y ago
If Google supported JPEG XL in Google Photos, they wouldn't be able to sell as many storage upgrades.
account42 3y ago
Please can we have browsers not advertise support via Accept heders or <picture> tag support this time until they actually support all features so that those don't become useless for progressive enhancement of anything that isnt a static lossy image.
brucethemoose2 3y ago
So, all it takes to consider a small community requested change in Chromium is a massive protest from thousands of users, small businesses, and Fortune 500 companies for almost a year... Or maybe they are just trying to keep feature parity with Safari.
- nathan_phoenix 3y ago
  Can't lose the edge to Tim Apple...
  - petecooper 3y ago
    >[E]dge There's a browser joke here somewhere, I'm sure.
  - rizky05 3y ago
    [dead]
- jsnell 3y ago
  Of course Apple adding support in Safari is far more important than Internet outrage! At this point adding new {image, audio, video, compression} codecs to browsers is probably a net negative, unless there's a good chance they get deployed across the entire browser ecosystem. Safari is generally the browser that's most conservative about implementing anything new, so their support makes a huge difference in the viability of getting the format universally supported.
  - brucethemoose2 3y ago
    None of this stopped Google's push for WebP or AVIF.
    - mschuster91 3y ago
      Google has enough moat via the Chrome, Chrome-derivative browser and Youtube client marketshare to push through a new format virtually everywhere outside the Apple ecosystem.
      - doublepg23 3y ago
        Yet WebP support is still pretty dreadful.
        chungy 3y ago
        Dreadful where? In this day and age, WebP is supported by every browser, I can browse them comfortably in my file manager and basically every image-related program can open and edit them (I'm running GNOME on Arch). Where is it lacking? I'm not a fan of WebP, mind, but the idea that support for it is dreadful is strange to me.
        wpm 3y ago
        I think was less than a year ago that OBS got support for webp. Just about the same for Photoshop. Plenty of software still doesn’t support it or support it well. Glad your experience has been good. Personally, the fact that it was Googles idea means I’m going to hold it at arms length, if not avoid it entirely. The web should be built on open standards.
        chungy 3y ago
        I was using WebP-lossless for quite a few years, for the subset of images I had that fit within WebP's limitations (being the 16383×16383 dimensions and 32 bpp color depth). I've recently converted everything to JPEG XL. Old JPEGs got losslessly transformed, and both PNGs and WebP-lossless into lossless JPEG XL. Seems to be a similar level of "works everywhere" for me, with the exception of web browsers this time.
- wpietri 3y ago
  Yeah, Google's top three revenue sources are ads, ads, and ads. (Respectively search, network, and YouTube.) Their customers are advertisers. Chrome's job (and Android's) is to make sure they retain control of sufficient surface area to place ads. Chrome user opinion to them is important to their business in about the same way meatpackers care about what cattle think of the design of the feeding stations. As long as they keep coming to eat, it's just mooing.
  - stephenr 3y ago
    > As long as they keep coming to eat, it's just mooing. I love this phrase thank you.
- coldpie 3y ago
  Adding new image format support to a web browser is not a small change.
  - MaxBarraclough 3y ago
    It's not a 5 minute job, sure, but compared to something like WebGPU it's tiny.
  - JyrkiAlakuijala 3y ago
    it adds 185 kB of compressed binary size -- probably by compressing the graphics that come along Chromium will 10x counter the added weight and it will actually save size
  - gorlilla 3y ago
    And surely doesnt come with any security baggage.
  - brucethemoose2 3y ago
    It was already implemented, and gated behind a flag.
- DannyBee 3y ago
  Uh? This is just a random request on a bug tracker that someone is triaging the same way they triage all other things?
  - brucethemoose2 3y ago
    Yeah, it's barely a response at all. But it still more of a response than Google has given in ages.
- ksec 3y ago
  I dont think anything has changed. JPEG XL being supported by Apple would only be 20% of user world wide. Assuming every one uses it. According to the initial Google thread this is likely not considered as high enough interest. With Google's study [1], by Google's Engineer, JPEG XL is no where near good enough compared to AVIF. None of the above facts have changed since Google Chrome's decision on JPEG XL. /S [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html
  - aarmot 3y ago
    That study is far from being conclusive. Please read also https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
    - ksec 3y ago
      >That study is far from being conclusive. Please read also Yes that is why I had "/S" at the end.
tssva 3y ago
This isn't the issue regarding JPEG XL support. That issue is still closed as "won't fix". This is a new issue asking for that issue to be re-opened.
- teraflop 3y ago
  Although I can sympathize, I don't really understand the point of opening a new issue when all the same information has already been left in comments on the old closed issue. If the new issue gets closed, then it just reaffirms that the Chromium team doesn't care about this feature request. If the new issue somehow convinces the team to do something about it, then it shows that the team is utterly dysfunctional because their decision-making is more influenced by whether you say "pretty pretty please" in the right way than by the content of the discussion.
  - rocqua 3y ago
    Further discussion on that closed issue is no longer possible right? So any new information that might cause a re-evaluation needs to be presented in a new issue. The new information here seems to be 'most people thought the previous decision was bad', rather than 'please I really want this'. Changing an old decision because most people think it was bad is not a sign of utter dysfunction.
    - JyrkiAlakuijala 3y ago
      Further discussion is possible there. It just does not get triaged like a new bug.
    - izacus 3y ago
      "most people" of which group thought that?
bricss 3y ago
JXL to de moon!
MikeCapone 3y ago
JPEG XL looks like a great format, I hope it takes over. I get that most bandwidth goes to video, but it would still be nice to have a great modern standard for images.
- FoxBJK 3y ago
  I think Google's answer to that is WebP.
  - account42 3y ago
    Good joke.
  - pornel 3y ago
    If anything, it'd be AVIF. WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.
    - JyrkiAlakuijala 3y ago
      AVIF was a quick hack originally by Netflix by placing an AV1 frame into a HEIC container. I believe it was done in a few weeks of work. AV1 was largely based on VP9/VP10 and was developed by a team working in Chrome organization. JPEG XL main mode (VarDCT) and the JPEG recompression is largely developed by Google Research. WebP as a format was based on VP8, a video codec built by On2 Technologies. On2 was bought by Google in 2010 -- a year before Google published WebP. The transparency and lossless encoding as well as non-video keyframe-by-keyframe animation were designed at Google. The On2 VP8 codec used initially in WebP lossy was not that suitable (too many artefacts) for photography transmission. Jeff Muizelaar wrote a great blog post about this. The codec for WebP were redesigned (without format) changes at Google, and kept improving significantly until around 2015 when it reached pretty good maturity. (Personally, I don't like what it does to highly saturated dark colors, such as dark forests or dark red textures, but it is much much better than it was.)
    - 3y ago
baggy_trough 3y ago
Also exciting that AVIF is finally coming to Edge, the last holdout.
thyrox 3y ago
For those who are unaware, this looks like a good article for the backstory. https://www.techspot.com/news/98355-google-deprecating-jpeg-xl-own-predatory-interests-fsf.html https://www.techspot.com/news/98355-google-deprecating-jpeg-...
- charcircuit 3y ago
  This isn't a good article because of how biased it is against Google. It ignores that there is added cost to Google and their partners in supporting it and ignores the recommendation to use a WASM decoder.
  - worrycue 3y ago
    Oh please, Google’s parent company is worth 1.64 trillion USD. They can afford a few programmers to maintain a codec. Lack of popularity hasn’t stop them from supporting webp and AVIF.
    - charcircuit 3y ago
      >They can afford a few programmers to maintain a codec. This is a bad argument because with that money they can also afford to do almost anything. They could also add any random file format to the browser, but that increases costs to support the web for more than just Google. Meanwhile adding a polyfill to support the format is performant without adding complexity to the web.
      - jl6 3y ago
        It’s also a bad argument because it confuses market cap with “money available to invest in developing products” (not that Google isn’t swimming in dumb money for other reasons).
PaulHoule 3y ago
As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s use Rec 2020 which has a huge color gamut, because it is covering a bigger space, 8-bit color is not enough, you need to go to 10-bit, 12-bit or more (I process in 16 bits) and neither JPEG or WEBP can handle that. AVIF can, but so can JPEG XL. I know people doing synthetic tests (instead of looking at the image they run a program that estimates how bad compression artifacts are) are impressed with AVIF but I’ve done some shootouts with JPEG/WEBP/AVIF/JPEG XL where I look at images with my own eyes. For pictures that are moderate-low quality (say images for a blog) I think AVIF does very well, but I want to publish pictures I took with my mirrorless where I work really hard to get them “tack sharp” (e.g. sometimes a 4000x6000 image w/ my Sony looks almost like pixel art when you blow it up) and I want people to see something consistent with that on the web. And my experience is that AVIF falls down at that, it does not really save bits compared to JPEG and WEBP at high quality. JPEG XL gives superior compression at high quality and it supports high color depths and it’s an option I’d really like to have.
- ComodoHacker 3y ago
  >a 4000x6000 image w/ my Sony looks almost like pixel art Can you share some examples of such images/fragments?
- mike_d 3y ago
  > I want people to see something consistent with that on the web. Don't get too hung up on picking a file format then. All sorts of middleboxes, CDNs, and edge network acceleration systems can potentially "right-size" your image for what the requesting device can handle optimally.
- gsich 3y ago
  JPEG has 12-bit somewhere in the standard, not sure on where it's implemented.
purpleblue 3y ago
Can someone summarize the issue with JPEG XL? Is this something that really matters? I've seen this mentioned a couple of times in the last few days but I don't see what the big deal is, is it really that necessary?
- gulikoza 3y ago
  JPEG is 30 years old so we need something more modern (better compression, less visual artifacts, web optimized, etc...). There already was a plan to change it with JPEG 2000, but it failed, obviously, as we still use jpegs. Now several formats are competing, most notably AVIF (which is basically just single AV1 video compressed frame) and JPEG XL. JPEG XL might be slightly better in some cases (as AVIF is based on a video codec) and most importantly it's backwards compatible with JPEG. So this means we can re-encode 30 years of JPEGs to JPEG XL without image degradation. Having a wide support would help immensely to make the format standard as otherwise everybody will just continue to use JPEGs. Google is somewhat against this as they already have support for AV1 and thus don't need to maintain a separate codec for JPEG XL.
  - JyrkiAlakuijala 3y ago
    Google Research is developing and maintaining JPEG XL, including a Chromium patch, without having expressed future maintenance cost worries.
  - purpleblue 3y ago
    Thank you! A lot of the context was lost for me!
untitaker_ 3y ago
this is a rando spamming the chromium issue tracker. what is newsworthy about this?
- andybak 3y ago
  Because lots of people are hoping Google will change is mind and this is a small concrete step towards that.
  - insanitybit 3y ago
    Is there a good writeup about why people want this over other, existing formats?
    - FireInsight 3y ago
      I'm not aware, but the gist is that it's in some circumstances better than AVIF in size and/or quality. Both of the new formats are wayy better than good old JPEG and PNG, but AVIF is the one Google is pushing.
      - izacus 3y ago
        > but AVIF is the one Google ... but AVIF is the one Google, Apple, Edge, Firefox are pushing... Let's not be misleading here :)
        FireInsight 3y ago
        Sure, everyone else is pushing AVIF too. And I don't mind, it's a great format.
    - TacticalCoder 3y ago
      > Is there a good writeup about why people want this over other, existing formats? All the existing JPEG files can be converted to JPEG XL while gaining 20% size and still having all the exact same data. There are, what, tens or hundreds of billions of JPEG files out there for which the "original" (RAW or anything) is long gone (or never existed) and people don't want a "photocopy of a photocopy". You can even decompress the JPEG XL back to the original JPEG file, bit for bit. For that alone there shouldn't be any question: it's a wonderful feature. In addition to that Apple / Safari are going to support JPEG XL and there are huge number of applications supporting that format. People don't want this "over" existing formats. They want this in addition to other formats. And I think they'll get it.
snickerbockers 3y ago
I'm just reading through the wikipedia page on this for the first time. Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis? If it's the former then I can see this offering a lot of utility over other image formats because you'd be able to disable the DCT on high-contrast macroblocks and finally be done with all those god-awful "checkerboard" artifacts around the edges of objects. But if it's merely on a per-channel basis then I'm not sure I see what the point of this is since I can already use a different format when I need lossless encoding; If anything JXL would become an annoyance because I can't tell if a JXL image is lossless or not based on the file's extension.
- lifthrasiir 3y ago
  > Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis? Tricky but it can be indeed done on a per-macroblock basis. The encoding itself is fixed per frame, but JPEG XL mandates zero-duration frames to be merged with the prior frame, so multiple frames with different encodings can be used for that. In fact I believe patches already work like this.
- JyrkiAlakuijala 3y ago
  JPEG XL has 10 8x8 transforms and 9 larger transforms (IIRC). Two of the 8x8 transforms are extremely local. One is called IDENTITY and the other DCT2x2. It is very difficult to produce ringing artefacts when using these transforms. When going to higher quality settings in libjxl, it tends to favor the DCT2x2 quite a bit. This is in VarDCT -- not modular coding.
- wpietri 3y ago
  This is a good look at the benefits of JPEG XL: https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-going https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-g... It was discussed here a few weeks ago: https://news.ycombinator.com/item?id=36801448 https://news.ycombinator.com/item?id=36801448
anotherhue 3y ago
Ignore the codec information (fascinating though that branch of comp.sci. is), what's interesting here is exactly how much Google is in control of Chromium, and by extension the web. The fact that we have to get on our knees and plead for their consideration versus just fork and ship should make you ill. No compression without representation or some such.
boesboes 3y ago
It seems even the triage is done by bots, or they just don't read the issue, or it's just a tactic to prevent anything from being done, but seriously: > @Reporter Could you please confirm the OS details.
- pavel_lishin 3y ago
  My favorite bit: > As the issue seems similar to crbug.com/1178058 adding firsching to cc list for more inputs.
- alex_suzuki 3y ago
  Yeah, same thought. This actually does not feel like a bot (see random punctuation), just a typical bad 3rd-level support employee.
izacus 3y ago
At this point this just seems like one of those internet religious wars instead of anything actually tecnically usable. I bet after (re)introduction, most of people yelling for it won't actually convert their JPEGs to XL. Just like almost noone whining about Reader actually uses or pays for any of the alternatives.
- dragonwriter 3y ago
  > I bet after (re)introduction, most of people yelling for it won't actually convert their JPEGs to XL. The idea is converting workflows to JPEG XL (and particularly to enable uses for which JPEG isn’t suitable and even AVIF is supposedly less optimal), not converting existing JPEGs, mainly.
danShumway 3y ago
I still need to sit down and convert my personal Linux computer over to using JPEG XL for picture archival and figure out what tools need to change or be updated. Using it on the web is one thing, but getting better compression for my family photos would also probably be a win, and I suspect it would be possible to build a pipeline for viewing/editing that would be fairly transparent.
- chungy 3y ago
  I've been pretty happy with it, myself. All the base OS libraries support JPEG XL so it's nearly pain-free, excepting lack of web browser support. Combined with GNU parallel, I did this: find -type f -iname \*.jpg -print0 | parallel -0 cjxl --lossless_jpeg=1 {} {.}.jxl find -type f -iname \*.png -print0 | parallel -0 cjxl -d 0 {} {.}.jxl find -type f -iname \*.webp -print0 | parallel -0 dwebp -o {.}.png {} \&\& cjxl -d 0 {.}.png {.}.jxl JPEGs get losslessly recompressed with JPEG XL. PNGs and (lossless) WebPs get converted to lossless JPEG XL.
  - danShumway 3y ago
    Nice, I should give this a try and see what it does to my photo library size. There are a few holdout programs that I think are missing support (Blender3D springs to mind), but I also think in the rare instances where that's a problem I could probably set up a quick shortcut or some hooks to on-the-fly run cjxl and convert back to jpeg/png temporarily for whatever operation I need to do.
michaelt 3y ago
Personally, I've got no great love for these new image formats. It's always a pain in the ass when you discover your phone has actually been saving your photos as heic or webp or avif or whatever and hardly anything will open them. I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 30 photos every day at 4k resolution, it'd take 20 years to fill up a $50 1TB disk. The other benefits of the format might be great for some specialist applications, but options like billion-pixel-wide images, 32 bits per channel and 4099 channels ready for medical imaging only get a shrug from me. I doubt my browser is going to start displaying 4099 channel images. I just wish we could get rid of heic, webp and avif at the same time.
- Exuma 3y ago
  You very clearly don't care about 90% of the rest of the world who doesn't have fast internet you also very clearly don't care about the entire internet experience, at all, whatsoever. Edit: 60% space savings only available in the age of the floppy.... what? 60% cost savings when serving multiple terabytes of image data is useless? You seem to view everything through the extremely tiny lens of a photographer or something... pun intended
  - shivz45 3y ago
    2g mobile still running in my country
  - refulgentis 3y ago
    This is extremely aggressive and personal, I suggest editing out the edit.
- sznio 3y ago
  > I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 30 photos every day at 4k resolution, it'd take 20 years to fill up a $50 1TB disk. 60% smaller images are great for hosting providers. We have ample storage and bandwidth compared to the 90s, but it still ain't that cheap.
padjo 3y ago
How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?
- kbrosnan 3y ago
  Integration of a new decoder is not all that complicated code wise. What is complicated is the effects of the change and ongoing support. 1. Binary size cost, in my experience working on Firefox this is in the 100s of KiB range when adding a new decoder. 2. Ongoing costs increased compile times, new integration tests, functional tests and so forth. Keeping those tests passing and non-flaky. 3. Once something is accepted into the web ecosystem the intention is to support it for 10s of years if not forever. Web feature deprecation is quite slow, ex <keygen> & <blink>. The web has not deprecated a primary image format. 4. Security, a 'new' binary format is a place for security vulnerabilities, crashes and hangs. The web is actively hostile place for web browsers.
- izacus 3y ago
  For a browser, it means permanent, forever, support for the format and continued maintenance and security patching for the library. Any CVE, any issue that might cause the browser to be insecure will be blamed on the browser and the developers will have to make sure any codec they use is safe forever. That's the cost for the maintainers. Codecs are historically one of the most problematic sources of security issues (they're complex code that handles malicious downloaded files) and supporting a new one is a rather big maintenance burden for everyone involved. And if Chrome gets backdoored by a JXL library security hole, everyone will blame Google for it. If, by any chance, supporting JXL becomes too much of a burden, everyone will again blame Google for being evil if they ever remove it from Chrome.
  - JyrkiAlakuijala 3y ago
    These sound like good reasons to quickly disable AVIF and move fully to JPEG XL. AVIF is about 3-5x more code than JPEG XL.
trunnell 3y ago
Scanning the comments here and I don't see anyone addressing the elephant in the room: PATENTS. After a bit of searching, it's unclear what degree of "patent risk" comes with JPEG XL. JPEG historically was subject to patent troll lawsuits until the patent expired in 2006. Please note that it's not enough for there to be a "royalty-free reference implementation" of JPEG XL, even if it's licensed with Apache 2.0, because you can't be sure from a glance that the Apache license patent grant includes all relevant patents. If you care about open source and free formats, you should look for two things: a comprehensive patent pool transferred to the standards body AND a royalty-free patent license to anyone with no strings attached. The game here is that companies with potential claims over some techniques used within codecs have an incentive to withhold their patents from the official pool until years after adoption. Then they sue the biggest users of the codec (like Google) for obscene sums of money. That's why ALL of the patents used in a codec must be assigned to the standards body for open licensing, and you have to be SURE that none are withheld. This is difficult. AVIF (and it's standards body, the AOM) was created in part (I believe) to solve this very problem. All the major tech companies are members and they've effectively agreed to a patent truce with regards to codecs. This is arguably the most important commercial concern in distributing a browser for free that includes codecs. If you ship unlicensed codecs, some random company can crawl out of the woodwork 5 year later and sue you for a billion dollars. In my view, AVIF only needs to be competitive with compression and quality. It patent risk is so low that it is the obvious choice. AVIF is truly open, there are multiple implementations, and its reason for existing is to solve the codec patent problem. Source: I was near the activities within Netflix that helped found the AOM. Disclaimer: I'm not a lawyer and this isn't legal advice; also I'm several years out of date w.r.t. JPEG XL specifically, so I'd be happy to be corrected about the relevant patent risk. Maybe someone has better info?
- neandrake 3y ago
  Did google cite patents as one of the reasons they removed support initially? I thought it was all around lack of benefits and difficulty of maintenance.
- Sakos 3y ago
  Apparently Microsoft was granted this patent on rANS in early 2022 (https://patents.google.com/patent/US11234023B2/en https://patents.google.com/patent/US11234023B2/en) and Google deprecated JPEG XL support late 2022. JPEG XL uses rANS, so I think there's some likelihood that this motivated Google to change their focus. Google didn't mention anything about this in their reasoning, but would they have mentioned patent issues publicly if that were the real reason? Google isn't obligated to tell us everything and the reasons they gave always felt weak and weirdly dismissive.

302 points by blurred 3y ago

If Google supported JPEG XL in Google Photos, they wouldn't be able to sell as many storage upgrades.

Please can we have browsers not advertise support via Accept heders or <picture> tag support this time until they actually support all features so that those don't become useless for progressive enhancement of anything that isnt a static lossy image.

brucethemoose2 3y ago

So, all it takes to consider a small community requested change in Chromium is a massive protest from thousands of users, small businesses, and Fortune 500 companies for almost a year... Or maybe they are just trying to keep feature parity with Safari.

nathan_phoenix 3y ago
Can't lose the edge to Tim Apple...
- petecooper 3y ago
  >[E]dge There's a browser joke here somewhere, I'm sure.
- rizky05 3y ago
  [dead]
jsnell 3y ago
Of course Apple adding support in Safari is far more important than Internet outrage! At this point adding new {image, audio, video, compression} codecs to browsers is probably a net negative, unless there's a good chance they get deployed across the entire browser ecosystem. Safari is generally the browser that's most conservative about implementing anything new, so their support makes a huge difference in the viability of getting the format universally supported.
- brucethemoose2 3y ago
  None of this stopped Google's push for WebP or AVIF.
  - mschuster91 3y ago
    Google has enough moat via the Chrome, Chrome-derivative browser and Youtube client marketshare to push through a new format virtually everywhere outside the Apple ecosystem.
    - doublepg23 3y ago
      Yet WebP support is still pretty dreadful.
      - chungy 3y ago
        Dreadful where? In this day and age, WebP is supported by every browser, I can browse them comfortably in my file manager and basically every image-related program can open and edit them (I'm running GNOME on Arch). Where is it lacking? I'm not a fan of WebP, mind, but the idea that support for it is dreadful is strange to me.
        wpm 3y ago
        I think was less than a year ago that OBS got support for webp. Just about the same for Photoshop. Plenty of software still doesn’t support it or support it well. Glad your experience has been good. Personally, the fact that it was Googles idea means I’m going to hold it at arms length, if not avoid it entirely. The web should be built on open standards.
        chungy 3y ago
        I was using WebP-lossless for quite a few years, for the subset of images I had that fit within WebP's limitations (being the 16383×16383 dimensions and 32 bpp color depth). I've recently converted everything to JPEG XL. Old JPEGs got losslessly transformed, and both PNGs and WebP-lossless into lossless JPEG XL. Seems to be a similar level of "works everywhere" for me, with the exception of web browsers this time.
wpietri 3y ago
Yeah, Google's top three revenue sources are ads, ads, and ads. (Respectively search, network, and YouTube.) Their customers are advertisers. Chrome's job (and Android's) is to make sure they retain control of sufficient surface area to place ads. Chrome user opinion to them is important to their business in about the same way meatpackers care about what cattle think of the design of the feeding stations. As long as they keep coming to eat, it's just mooing.
- stephenr 3y ago
  > As long as they keep coming to eat, it's just mooing. I love this phrase thank you.
coldpie 3y ago
Adding new image format support to a web browser is not a small change.
- MaxBarraclough 3y ago
  It's not a 5 minute job, sure, but compared to something like WebGPU it's tiny.
- JyrkiAlakuijala 3y ago
  it adds 185 kB of compressed binary size -- probably by compressing the graphics that come along Chromium will 10x counter the added weight and it will actually save size
- gorlilla 3y ago
  And surely doesnt come with any security baggage.
- brucethemoose2 3y ago
  It was already implemented, and gated behind a flag.
DannyBee 3y ago
Uh? This is just a random request on a bug tracker that someone is triaging the same way they triage all other things?
- brucethemoose2 3y ago
  Yeah, it's barely a response at all. But it still more of a response than Google has given in ages.
ksec 3y ago
I dont think anything has changed. JPEG XL being supported by Apple would only be 20% of user world wide. Assuming every one uses it. According to the initial Google thread this is likely not considered as high enough interest. With Google's study [1], by Google's Engineer, JPEG XL is no where near good enough compared to AVIF. None of the above facts have changed since Google Chrome's decision on JPEG XL. /S [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html
- aarmot 3y ago
  That study is far from being conclusive. Please read also https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
  - ksec 3y ago
    >That study is far from being conclusive. Please read also Yes that is why I had "/S" at the end.

tssva 3y ago

This isn't the issue regarding JPEG XL support. That issue is still closed as "won't fix". This is a new issue asking for that issue to be re-opened.

teraflop 3y ago
Although I can sympathize, I don't really understand the point of opening a new issue when all the same information has already been left in comments on the old closed issue. If the new issue gets closed, then it just reaffirms that the Chromium team doesn't care about this feature request. If the new issue somehow convinces the team to do something about it, then it shows that the team is utterly dysfunctional because their decision-making is more influenced by whether you say "pretty pretty please" in the right way than by the content of the discussion.
- rocqua 3y ago
  Further discussion on that closed issue is no longer possible right? So any new information that might cause a re-evaluation needs to be presented in a new issue. The new information here seems to be 'most people thought the previous decision was bad', rather than 'please I really want this'. Changing an old decision because most people think it was bad is not a sign of utter dysfunction.
  - JyrkiAlakuijala 3y ago
    Further discussion is possible there. It just does not get triaged like a new bug.
  - izacus 3y ago
    "most people" of which group thought that?

bricss 3y ago

JXL to de moon!

MikeCapone 3y ago

JPEG XL looks like a great format, I hope it takes over. I get that most bandwidth goes to video, but it would still be nice to have a great modern standard for images.

FoxBJK 3y ago
I think Google's answer to that is WebP.
- account42 3y ago
  Good joke.
- pornel 3y ago
  If anything, it'd be AVIF. WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.
  - JyrkiAlakuijala 3y ago
    AVIF was a quick hack originally by Netflix by placing an AV1 frame into a HEIC container. I believe it was done in a few weeks of work. AV1 was largely based on VP9/VP10 and was developed by a team working in Chrome organization. JPEG XL main mode (VarDCT) and the JPEG recompression is largely developed by Google Research. WebP as a format was based on VP8, a video codec built by On2 Technologies. On2 was bought by Google in 2010 -- a year before Google published WebP. The transparency and lossless encoding as well as non-video keyframe-by-keyframe animation were designed at Google. The On2 VP8 codec used initially in WebP lossy was not that suitable (too many artefacts) for photography transmission. Jeff Muizelaar wrote a great blog post about this. The codec for WebP were redesigned (without format) changes at Google, and kept improving significantly until around 2015 when it reached pretty good maturity. (Personally, I don't like what it does to highly saturated dark colors, such as dark forests or dark red textures, but it is much much better than it was.)
  - 3y ago

baggy_trough 3y ago

Also exciting that AVIF is finally coming to Edge, the last holdout.

thyrox 3y ago

For those who are unaware, this looks like a good article for the backstory. https://www.techspot.com/news/98355-google-deprecating-jpeg-xl-own-predatory-interests-fsf.html https://www.techspot.com/news/98355-google-deprecating-jpeg-...

charcircuit 3y ago
This isn't a good article because of how biased it is against Google. It ignores that there is added cost to Google and their partners in supporting it and ignores the recommendation to use a WASM decoder.
- worrycue 3y ago
  Oh please, Google’s parent company is worth 1.64 trillion USD. They can afford a few programmers to maintain a codec. Lack of popularity hasn’t stop them from supporting webp and AVIF.
  - charcircuit 3y ago
    >They can afford a few programmers to maintain a codec. This is a bad argument because with that money they can also afford to do almost anything. They could also add any random file format to the browser, but that increases costs to support the web for more than just Google. Meanwhile adding a polyfill to support the format is performant without adding complexity to the web.
    - jl6 3y ago
      It’s also a bad argument because it confuses market cap with “money available to invest in developing products” (not that Google isn’t swimming in dumb money for other reasons).

PaulHoule 3y ago

As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s use Rec 2020 which has a huge color gamut, because it is covering a bigger space, 8-bit color is not enough, you need to go to 10-bit, 12-bit or more (I process in 16 bits) and neither JPEG or WEBP can handle that. AVIF can, but so can JPEG XL. I know people doing synthetic tests (instead of looking at the image they run a program that estimates how bad compression artifacts are) are impressed with AVIF but I’ve done some shootouts with JPEG/WEBP/AVIF/JPEG XL where I look at images with my own eyes. For pictures that are moderate-low quality (say images for a blog) I think AVIF does very well, but I want to publish pictures I took with my mirrorless where I work really hard to get them “tack sharp” (e.g. sometimes a 4000x6000 image w/ my Sony looks almost like pixel art when you blow it up) and I want people to see something consistent with that on the web. And my experience is that AVIF falls down at that, it does not really save bits compared to JPEG and WEBP at high quality. JPEG XL gives superior compression at high quality and it supports high color depths and it’s an option I’d really like to have.

ComodoHacker 3y ago
>a 4000x6000 image w/ my Sony looks almost like pixel art Can you share some examples of such images/fragments?
mike_d 3y ago
> I want people to see something consistent with that on the web. Don't get too hung up on picking a file format then. All sorts of middleboxes, CDNs, and edge network acceleration systems can potentially "right-size" your image for what the requesting device can handle optimally.
gsich 3y ago
JPEG has 12-bit somewhere in the standard, not sure on where it's implemented.

purpleblue 3y ago

Can someone summarize the issue with JPEG XL? Is this something that really matters? I've seen this mentioned a couple of times in the last few days but I don't see what the big deal is, is it really that necessary?

gulikoza 3y ago
JPEG is 30 years old so we need something more modern (better compression, less visual artifacts, web optimized, etc...). There already was a plan to change it with JPEG 2000, but it failed, obviously, as we still use jpegs. Now several formats are competing, most notably AVIF (which is basically just single AV1 video compressed frame) and JPEG XL. JPEG XL might be slightly better in some cases (as AVIF is based on a video codec) and most importantly it's backwards compatible with JPEG. So this means we can re-encode 30 years of JPEGs to JPEG XL without image degradation. Having a wide support would help immensely to make the format standard as otherwise everybody will just continue to use JPEGs. Google is somewhat against this as they already have support for AV1 and thus don't need to maintain a separate codec for JPEG XL.
- JyrkiAlakuijala 3y ago
  Google Research is developing and maintaining JPEG XL, including a Chromium patch, without having expressed future maintenance cost worries.
- purpleblue 3y ago
  Thank you! A lot of the context was lost for me!

untitaker_ 3y ago

this is a rando spamming the chromium issue tracker. what is newsworthy about this?

andybak 3y ago
Because lots of people are hoping Google will change is mind and this is a small concrete step towards that.
- insanitybit 3y ago
  Is there a good writeup about why people want this over other, existing formats?
  - FireInsight 3y ago
    I'm not aware, but the gist is that it's in some circumstances better than AVIF in size and/or quality. Both of the new formats are wayy better than good old JPEG and PNG, but AVIF is the one Google is pushing.
    - izacus 3y ago
      > but AVIF is the one Google ... but AVIF is the one Google, Apple, Edge, Firefox are pushing... Let's not be misleading here :)
      - FireInsight 3y ago
        Sure, everyone else is pushing AVIF too. And I don't mind, it's a great format.
  - TacticalCoder 3y ago
    > Is there a good writeup about why people want this over other, existing formats? All the existing JPEG files can be converted to JPEG XL while gaining 20% size and still having all the exact same data. There are, what, tens or hundreds of billions of JPEG files out there for which the "original" (RAW or anything) is long gone (or never existed) and people don't want a "photocopy of a photocopy". You can even decompress the JPEG XL back to the original JPEG file, bit for bit. For that alone there shouldn't be any question: it's a wonderful feature. In addition to that Apple / Safari are going to support JPEG XL and there are huge number of applications supporting that format. People don't want this "over" existing formats. They want this in addition to other formats. And I think they'll get it.

snickerbockers 3y ago

I'm just reading through the wikipedia page on this for the first time. Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis? If it's the former then I can see this offering a lot of utility over other image formats because you'd be able to disable the DCT on high-contrast macroblocks and finally be done with all those god-awful "checkerboard" artifacts around the edges of objects. But if it's merely on a per-channel basis then I'm not sure I see what the point of this is since I can already use a different format when I need lossless encoding; If anything JXL would become an annoyance because I can't tell if a JXL image is lossless or not based on the file's extension.

lifthrasiir 3y ago
> Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis? Tricky but it can be indeed done on a per-macroblock basis. The encoding itself is fixed per frame, but JPEG XL mandates zero-duration frames to be merged with the prior frame, so multiple frames with different encodings can be used for that. In fact I believe patches already work like this.
JyrkiAlakuijala 3y ago
JPEG XL has 10 8x8 transforms and 9 larger transforms (IIRC). Two of the 8x8 transforms are extremely local. One is called IDENTITY and the other DCT2x2. It is very difficult to produce ringing artefacts when using these transforms. When going to higher quality settings in libjxl, it tends to favor the DCT2x2 quite a bit. This is in VarDCT -- not modular coding.
wpietri 3y ago
This is a good look at the benefits of JPEG XL: https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-going https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-g... It was discussed here a few weeks ago: https://news.ycombinator.com/item?id=36801448 https://news.ycombinator.com/item?id=36801448

anotherhue 3y ago

Ignore the codec information (fascinating though that branch of comp.sci. is), what's interesting here is exactly how much Google is in control of Chromium, and by extension the web. The fact that we have to get on our knees and plead for their consideration versus just fork and ship should make you ill. No compression without representation or some such.

boesboes 3y ago

It seems even the triage is done by bots, or they just don't read the issue, or it's just a tactic to prevent anything from being done, but seriously: > @Reporter Could you please confirm the OS details.

pavel_lishin 3y ago
My favorite bit: > As the issue seems similar to crbug.com/1178058 adding firsching to cc list for more inputs.
alex_suzuki 3y ago
Yeah, same thought. This actually does not feel like a bot (see random punctuation), just a typical bad 3rd-level support employee.

izacus 3y ago

At this point this just seems like one of those internet religious wars instead of anything actually tecnically usable. I bet after (re)introduction, most of people yelling for it won't actually convert their JPEGs to XL. Just like almost noone whining about Reader actually uses or pays for any of the alternatives.

dragonwriter 3y ago
> I bet after (re)introduction, most of people yelling for it won't actually convert their JPEGs to XL. The idea is converting workflows to JPEG XL (and particularly to enable uses for which JPEG isn’t suitable and even AVIF is supposedly less optimal), not converting existing JPEGs, mainly.

danShumway 3y ago

I still need to sit down and convert my personal Linux computer over to using JPEG XL for picture archival and figure out what tools need to change or be updated. Using it on the web is one thing, but getting better compression for my family photos would also probably be a win, and I suspect it would be possible to build a pipeline for viewing/editing that would be fairly transparent.

chungy 3y ago
I've been pretty happy with it, myself. All the base OS libraries support JPEG XL so it's nearly pain-free, excepting lack of web browser support. Combined with GNU parallel, I did this: find -type f -iname \*.jpg -print0 | parallel -0 cjxl --lossless_jpeg=1 {} {.}.jxl find -type f -iname \*.png -print0 | parallel -0 cjxl -d 0 {} {.}.jxl find -type f -iname \*.webp -print0 | parallel -0 dwebp -o {.}.png {} \&\& cjxl -d 0 {.}.png {.}.jxl JPEGs get losslessly recompressed with JPEG XL. PNGs and (lossless) WebPs get converted to lossless JPEG XL.
- danShumway 3y ago
  Nice, I should give this a try and see what it does to my photo library size. There are a few holdout programs that I think are missing support (Blender3D springs to mind), but I also think in the rare instances where that's a problem I could probably set up a quick shortcut or some hooks to on-the-fly run cjxl and convert back to jpeg/png temporarily for whatever operation I need to do.

michaelt 3y ago

Personally, I've got no great love for these new image formats. It's always a pain in the ass when you discover your phone has actually been saving your photos as heic or webp or avif or whatever and hardly anything will open them. I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 30 photos every day at 4k resolution, it'd take 20 years to fill up a $50 1TB disk. The other benefits of the format might be great for some specialist applications, but options like billion-pixel-wide images, 32 bits per channel and 4099 channels ready for medical imaging only get a shrug from me. I doubt my browser is going to start displaying 4099 channel images. I just wish we could get rid of heic, webp and avif at the same time.

Exuma 3y ago
You very clearly don't care about 90% of the rest of the world who doesn't have fast internet you also very clearly don't care about the entire internet experience, at all, whatsoever. Edit: 60% space savings only available in the age of the floppy.... what? 60% cost savings when serving multiple terabytes of image data is useless? You seem to view everything through the extremely tiny lens of a photographer or something... pun intended
- shivz45 3y ago
  2g mobile still running in my country
- refulgentis 3y ago
  This is extremely aggressive and personal, I suggest editing out the edit.
sznio 3y ago
> I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 30 photos every day at 4k resolution, it'd take 20 years to fill up a $50 1TB disk. 60% smaller images are great for hosting providers. We have ample storage and bandwidth compared to the 90s, but it still ain't that cheap.

padjo 3y ago

How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?

kbrosnan 3y ago
Integration of a new decoder is not all that complicated code wise. What is complicated is the effects of the change and ongoing support. 1. Binary size cost, in my experience working on Firefox this is in the 100s of KiB range when adding a new decoder. 2. Ongoing costs increased compile times, new integration tests, functional tests and so forth. Keeping those tests passing and non-flaky. 3. Once something is accepted into the web ecosystem the intention is to support it for 10s of years if not forever. Web feature deprecation is quite slow, ex <keygen> & <blink>. The web has not deprecated a primary image format. 4. Security, a 'new' binary format is a place for security vulnerabilities, crashes and hangs. The web is actively hostile place for web browsers.
izacus 3y ago
For a browser, it means permanent, forever, support for the format and continued maintenance and security patching for the library. Any CVE, any issue that might cause the browser to be insecure will be blamed on the browser and the developers will have to make sure any codec they use is safe forever. That's the cost for the maintainers. Codecs are historically one of the most problematic sources of security issues (they're complex code that handles malicious downloaded files) and supporting a new one is a rather big maintenance burden for everyone involved. And if Chrome gets backdoored by a JXL library security hole, everyone will blame Google for it. If, by any chance, supporting JXL becomes too much of a burden, everyone will again blame Google for being evil if they ever remove it from Chrome.
- JyrkiAlakuijala 3y ago
  These sound like good reasons to quickly disable AVIF and move fully to JPEG XL. AVIF is about 3-5x more code than JPEG XL.

trunnell 3y ago

Scanning the comments here and I don't see anyone addressing the elephant in the room: PATENTS. After a bit of searching, it's unclear what degree of "patent risk" comes with JPEG XL. JPEG historically was subject to patent troll lawsuits until the patent expired in 2006. Please note that it's not enough for there to be a "royalty-free reference implementation" of JPEG XL, even if it's licensed with Apache 2.0, because you can't be sure from a glance that the Apache license patent grant includes all relevant patents. If you care about open source and free formats, you should look for two things: a comprehensive patent pool transferred to the standards body AND a royalty-free patent license to anyone with no strings attached. The game here is that companies with potential claims over some techniques used within codecs have an incentive to withhold their patents from the official pool until years after adoption. Then they sue the biggest users of the codec (like Google) for obscene sums of money. That's why ALL of the patents used in a codec must be assigned to the standards body for open licensing, and you have to be SURE that none are withheld. This is difficult. AVIF (and it's standards body, the AOM) was created in part (I believe) to solve this very problem. All the major tech companies are members and they've effectively agreed to a patent truce with regards to codecs. This is arguably the most important commercial concern in distributing a browser for free that includes codecs. If you ship unlicensed codecs, some random company can crawl out of the woodwork 5 year later and sue you for a billion dollars. In my view, AVIF only needs to be competitive with compression and quality. It patent risk is so low that it is the obvious choice. AVIF is truly open, there are multiple implementations, and its reason for existing is to solve the codec patent problem. Source: I was near the activities within Netflix that helped found the AOM. Disclaimer: I'm not a lawyer and this isn't legal advice; also I'm several years out of date w.r.t. JPEG XL specifically, so I'd be happy to be corrected about the relevant patent risk. Maybe someone has better info?

neandrake 3y ago
Did google cite patents as one of the reasons they removed support initially? I thought it was all around lack of benefits and difficulty of maintenance.
Sakos 3y ago
Apparently Microsoft was granted this patent on rANS in early 2022 (https://patents.google.com/patent/US11234023B2/en https://patents.google.com/patent/US11234023B2/en) and Google deprecated JPEG XL support late 2022. JPEG XL uses rANS, so I think there's some likelihood that this motivated Google to change their focus. Google didn't mention anything about this in their reasoning, but would they have mentioned patent issues publicly if that were the real reason? Google isn't obligated to tell us everything and the reasons they gave always felt weak and weirdly dismissive.