JPEG XL(jpegxl.info)
jpegxl.info
JPEG XL
https://jpegxl.info
239 コメント
I agree with this, and I think for this reason it is best if a new codec gets wide adoption also outside browsers, instead of having the approach of a "web codec" where it suffices that servers and browsers know about it but the wider ecosystem doesn't support it.
WebP in particular, as the name suggests, was conceived as an "image format for the web" and while I think it's good to have the web in mind when designing an image codec, I think it's a bad idea to limit the scope like that. Design decisions like limiting the maximum dimensions and bit depth at the codec level "because that's all the web needs" plus limited attention/focus to adoption outside browsers does lead to the phenomenon you describe where "it doesn't work for everyone", causing the small gain of improved compression to be dwarfed by the huge inconvenience of breaking workflows.
Any new codec of course has this problem even if they do target wide adoption (like JPEG XL): adoption is never instantaneous. It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software, so it does make sense to start there even when it will still cause things to break in software that doesn't support it yet.
To mitigate that, I think it would help a lot of browsers would have a "Save As..." dialog box on images that gives users the choice to save the actual image in whatever format it is in, or to convert it to PNG or JPEG.
WebP in particular, as the name suggests, was conceived as an "image format for the web" and while I think it's good to have the web in mind when designing an image codec, I think it's a bad idea to limit the scope like that. Design decisions like limiting the maximum dimensions and bit depth at the codec level "because that's all the web needs" plus limited attention/focus to adoption outside browsers does lead to the phenomenon you describe where "it doesn't work for everyone", causing the small gain of improved compression to be dwarfed by the huge inconvenience of breaking workflows.
Any new codec of course has this problem even if they do target wide adoption (like JPEG XL): adoption is never instantaneous. It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software, so it does make sense to start there even when it will still cause things to break in software that doesn't support it yet.
To mitigate that, I think it would help a lot of browsers would have a "Save As..." dialog box on images that gives users the choice to save the actual image in whatever format it is in, or to convert it to PNG or JPEG.
> It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software,
Also there is a huge financial incentive for large web hosting companies (e.g. Google, Facebook) to adopt compression formats that save bandwidth, using automated tools to apply those wherever possible.
People making e.g. image archives or building image capture hardware are going to be slower. They don’t want to use new untested technologies that might not succeed, and they don’t want to switch more frequently than necessary. When they do transition it will be by applying new technologies to new images but not immediately transforming older images to use the new technology.
Also there is a huge financial incentive for large web hosting companies (e.g. Google, Facebook) to adopt compression formats that save bandwidth, using automated tools to apply those wherever possible.
People making e.g. image archives or building image capture hardware are going to be slower. They don’t want to use new untested technologies that might not succeed, and they don’t want to switch more frequently than necessary. When they do transition it will be by applying new technologies to new images but not immediately transforming older images to use the new technology.
True — which is one of the reasons why JPEG XL includes a risk-free JPEG recompression option: if needed, you can just undo it and get the bit-exact same JPEG files back.
Applying lossy recompression on already-lossy-compressed images is something you should avoid at all cost, since it inevitably causes generation loss (and it is also likely to not be very effective, since you're basically spending a lot of bits in the new codec on replicating compression artifacts of the old codec).
Applying lossy recompression on already-lossy-compressed images is something you should avoid at all cost, since it inevitably causes generation loss (and it is also likely to not be very effective, since you're basically spending a lot of bits in the new codec on replicating compression artifacts of the old codec).
Happy users, faster growing userbase, more e-store revenue, higher click-through rates, lower latency, better quality-of-experience, or more 7-day-returning users can be more important financial incentives than bandwidth. Humans are more than thousands of times more valuable than a computer.
When image quality and observed latency are at a level where users don't care even subconsciously (say, images look like camera originals and load in 100 ms), then bandwidth cost optimization may become a good 2nd objective.
When image quality and observed latency are at a level where users don't care even subconsciously (say, images look like camera originals and load in 100 ms), then bandwidth cost optimization may become a good 2nd objective.
This is a strange argument. The larger companies have plenty of people to work on all the things you mentioned plus bandwidth optimizations. Also, they’re rarely the same people.
The claim (from one of the people working on JPEG XL at Google) is that better image compression is going to reduce latency (or allow higher-quality images) and thereby improve other metrics besides bandwidth costs, giving internet companies even more incentive to adopt better codecs.
We automatically convert user generated images to WebP if feasible and then use the <picture> element to display alternatives (the original format as the fallback). I'm pretty sure that this might be a common pattern.
Browsers could allow a selection of all sources provided by the picture element (this would also include differently scaled variants based on media queries) in a download dialog.
Browsers could allow a selection of all sources provided by the picture element (this would also include differently scaled variants based on media queries) in a download dialog.
It's not a option doing that if you need to serve a TiB of images and you need, yet, to support IE 11.
JPEG XL on fly conversion to JPEG, offers a nice solution for this use case.
JPEG XL on fly conversion to JPEG, offers a nice solution for this use case.
We support IE11 with a polyfill.
The images are converted and stored when they are uploaded or changed. I can see this being an issue with that kind of volume though. But it’s a performance gain for the clients while content doesn’t need to worry about it.
The images are converted and stored when they are uploaded or changed. I can see this being an issue with that kind of volume though. But it’s a performance gain for the clients while content doesn’t need to worry about it.
Another solution could be that "someone" creates a library supporting all these formats that everyone else can then use. If the supported formats are queried at run-time, this means that just updating the library will automagically add support into other programs.
This would significantly increases browser attack surface area. Coders are usually much more complicated than decoders.
Browsers already have to include an encoder for JPEG and PNG. They need that anyway for things like toDataURL(), see
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
The browser has to decompress the image into raw pixels to display it anyway.
Dumping these raw pixels into a trivial intermediate format, like uncompressed PNG or BMP, should not increase the attack surface in any noticeable way.
Dumping these raw pixels into a trivial intermediate format, like uncompressed PNG or BMP, should not increase the attack surface in any noticeable way.
The input data to an encoder is very simple since it's just pixels. It's possible to find a crash but it would be surprising to find an exploitable one.
I'm worried about whether it will get adoption outside of browsers.
> It would be amazing if the browsers offered a built-in „Download & Convert“ feature for images and videos.
In a way, they already do for images: right-click and "Copy". In some desktop environments, you can even paste that directly into a folder to save it as a file. Dolphin allows choosing which format (of those that the browser can convert to) to save it in.
In a way, they already do for images: right-click and "Copy". In some desktop environments, you can even paste that directly into a folder to save it as a file. Dolphin allows choosing which format (of those that the browser can convert to) to save it in.
Chrome does seem to save the JPEG version on some WebP or AVIF URLs where there is also a JPEG version available too, although it seems to be 'clever' about it rather than explicitly offering the option, which can make saving the actual WebP or AVIF mildly annoying.
I've noticed this too but I couldn't determine any clear patterns. It's also very confusing when the file ending in the URL does not match what I download (that's why an explicit "save as" might be better than an implicit auto conversion). I think I also had situations where it did the opposite, download the webp even though the URL had jpeg in the name. I assumed that it's the webserver serving the image being too clever.
I've noticed sometimes that when Cloudflare optimises images and serves up their own WebP versions of your existing images, if you go to save it you get the original jpg/png back.
Presumably the HTTP request that gets sent when you save an image sends different Accept headers.
Doesn't seem to work all the time, but presumably thats down to a combination of different Cloudflare settings, origin server configuration and what format the original image were in too.
Presumably the HTTP request that gets sent when you save an image sends different Accept headers.
Doesn't seem to work all the time, but presumably thats down to a combination of different Cloudflare settings, origin server configuration and what format the original image were in too.
My guess is that the HTTP client request, when you do right click "Save Image As", is sent with Cache-Control:no-cache
and Pragma:no-cache headers. Which bypasses Cloudflare.
I think it just re-requests without the "Accept: image/webp" in the request header, so you get whatever the server would have sent to a browser that doesn't know about WebP.
At the same time content providers are trying to make it as difficult as possible to 'steal' their videos and images.
I like how you put steal in quotes to minimize the fact that is what you are doing. If you walk into an art gallery or musuem, you can't just take art of the wall and walk out with it. Just because the gallery is a website, people feel like they can just right-click and save as and walk out the door with it. Yet, people understand that highlighting text copy&pasting it into their own work is plagiarism. I honestly do not understand the disconnect. If the website felt like the imagery should be free for people to do what they want with, then they would provide a link to a higher quality image rather than a highly compressed one.
Wonky comparison, as plagiarism involves claiming authorship/evading citing, not literally copying text and keeping it somewhere else. I CAN go and copy text from any textbook into my notebook without consequences, why couldn't I download a copy of an image?
Did you ask for permission and were granted permission to take that image from the server for any other use than for viewing in a browser? What is the purpose of downloading the image? To share with friends? Why not send a link to the site? To use a desktop background? Did you pay to license for that use? To store on your phone for your own personal enjoyment? Again, why not reload the website?
As a lowly end user not intending to widely redistribute the content, I decline this absurd level of responsibility, and the doctrine of fair use would tend to agree.
And as long as websites tend to modify, delete, move, or otherwise play games with urls and content, I will see value in saving a permanent copy. That I should be able to do that is frankly how the internet was intended to function; if that's not desirable for the content, then perhaps it should not be published on the internet at all.
And as long as websites tend to modify, delete, move, or otherwise play games with urls and content, I will see value in saving a permanent copy. That I should be able to do that is frankly how the internet was intended to function; if that's not desirable for the content, then perhaps it should not be published on the internet at all.
>And as long as websites tend to modify, delete, move, or otherwise play games with urls and content <snip> then perhaps it should not be published on the internet at all.
Except an artist can deliberately decide to only make an image publicly available for a limited time, and therefore taken the image down from the website. Just like art moves from museum to museum, an artist can allow an image to be used within a pre-defined window. Just because you have the technical know how to extract an image that is not readibly downloadable via the UI does not mean you should.
Maybe one of the features of JXL would be a timebomb type of setting where after a certain date the data is no longer useable.
I sympathize with both sides of this argument. I get that info wants to be free blah blah, but I also understand that artists are in a difficult situation with the internet. I mean, an artist's work posted on the internet is not the cure for cancer, or basic information on algebra where the info should be evergreen. The group think is more of "I want what I want" vs consideration for what the artist's intentions are. If you enjoy an image so much that you're willing to go to the effort to get the image, why not acquire the image throuh legit method?
Except an artist can deliberately decide to only make an image publicly available for a limited time, and therefore taken the image down from the website. Just like art moves from museum to museum, an artist can allow an image to be used within a pre-defined window. Just because you have the technical know how to extract an image that is not readibly downloadable via the UI does not mean you should.
Maybe one of the features of JXL would be a timebomb type of setting where after a certain date the data is no longer useable.
I sympathize with both sides of this argument. I get that info wants to be free blah blah, but I also understand that artists are in a difficult situation with the internet. I mean, an artist's work posted on the internet is not the cure for cancer, or basic information on algebra where the info should be evergreen. The group think is more of "I want what I want" vs consideration for what the artist's intentions are. If you enjoy an image so much that you're willing to go to the effort to get the image, why not acquire the image throuh legit method?
If someone saves an image for private use, that doesn't interfere with limited public availability.
> If you enjoy an image so much that you're willing to go to the effort to get the image, why not acquire the image throuh legit method?
Do you make the same argument when people use a VHS? If you're willing to go through the effort to press the record button, you should go buy a copy for $20?
> If you enjoy an image so much that you're willing to go to the effort to get the image, why not acquire the image throuh legit method?
Do you make the same argument when people use a VHS? If you're willing to go through the effort to press the record button, you should go buy a copy for $20?
Depends on the purpose the use of the VHS. Copying something you brought home from Blockbuster would definitely qualify. Recording something off of TV to watch at a later more convenient time was just the precursor to DVR.
The image file you downloaded from someone's website without their permission in miles better in quality than the stupid VHS. It's more like the DVD/Blu-ray you ripped from your buddy that actually paid for it. Just because you can doesn't mean you should
The image file you downloaded from someone's website without their permission in miles better in quality than the stupid VHS. It's more like the DVD/Blu-ray you ripped from your buddy that actually paid for it. Just because you can doesn't mean you should
Saving an image is very high quality. But so is DVR. Usually a DVR copy is perfect.
DVR sounds like a very good analogy to me. The website is showing you something, and you make a personal capture that you can replay at any time. It was distributed to you specifically, and you're time-shifting it. You're not taking a personal copy held by one person and making it two personal copies held by two people, which is what happens when you rip someone else's DVD. And the same way, you shouldn't take that image you saved and start distributing it around.
DVR sounds like a very good analogy to me. The website is showing you something, and you make a personal capture that you can replay at any time. It was distributed to you specifically, and you're time-shifting it. You're not taking a personal copy held by one person and making it two personal copies held by two people, which is what happens when you rip someone else's DVD. And the same way, you shouldn't take that image you saved and start distributing it around.
Some countries, like France <https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI0000...> and Switzerland <https://www.fedlex.admin.ch/eli/cc/1993/1798_1798_1798/en#ti...>, cite several exceptions to copyright including private copying.
It's a bad metaphor, because if you take the image from the gallery, other people cannot enjoy it anymore, while with the right click/save you make a copy, so it's still there for everyone.
A better analogy would be if you make a painting of a painting without paying the original artist, is it stealing ?
It's not : it can be construed as counterfeiting though, and it might cause the artist to stop painting because he does not make enough money, but calling it stealing is simply wrong.
A better analogy would be if you make a painting of a painting without paying the original artist, is it stealing ?
It's not : it can be construed as counterfeiting though, and it might cause the artist to stop painting because he does not make enough money, but calling it stealing is simply wrong.
Okay, so you're one of those hung up on a definition. What do you call it when you use something without someone's explicit permission whether because you didn't ask for it first or knowingly using it after it has been posted on a website that you do not have permission to use it?
Normally, discussions about semantics are indeed pointless. But this is a rare exception.
The word "steal" is chosen because it carries a strong negative connotation. It is an example of loaded language (https://en.wikipedia.org/wiki/Loaded_language).
Regardless of whether it's ethical to copy whatever files in whatever situation being discussed, the term "steal" is intended to sidestep that question and make it feel unethical by drawing an equivalence between it and something most people agree is unethical.
It's a slightly underhanded rhetorical technique, so it's reasonable to put the word "steal" in quotation marks to call attention to it.
The word "steal" is chosen because it carries a strong negative connotation. It is an example of loaded language (https://en.wikipedia.org/wiki/Loaded_language).
Regardless of whether it's ethical to copy whatever files in whatever situation being discussed, the term "steal" is intended to sidestep that question and make it feel unethical by drawing an equivalence between it and something most people agree is unethical.
It's a slightly underhanded rhetorical technique, so it's reasonable to put the word "steal" in quotation marks to call attention to it.
Depends on the context. If the person loses access to what I'm taking (typical in the physical world), stealing. If the person does not loses access (typical in the virtual world or with artificial scarcity items), counterfeiting.
Yea its awful the number of sites that use .jpg but its actualy a webp with the wrong extension, like thanks I hate it.
Thanks Clouflare for that.
What would be even more amazing, is that browsers would compress / convert formats on upload. Especially video. It's stupid to upload gigabytes of raw video to a server which then compresses it to a few megabytes.
If you're willing for your video to suffer quality from bad compression settings because your browser is a "dumb" tool that just applies some preconfigured compression scheme, then great. Also, how many people are going to accept that instead of just uploading files and seeing immediate progress vs waiting for a browser to compress a file from some sub-$500 laptop? What codec is it encoding to? H.265? good luck getting that to complete this week on that cheap laptop.
I always hated when people sent me screenshots instead of just downloading the images, but for the reasons you mentioned I know often find myself screenshotting stuff....
At least I cut the image so it's not obvious
At least I cut the image so it's not obvious
[deleted]
Reminds me of the native plugin days where based on mine type, a plugin would handle the content.
Could WASM in an extension be good enough for some use cases like this?
Could WASM in an extension be good enough for some use cases like this?
Desktop Firefox already has it.
Right click — "Copy image" — paste into any program that supports PNG.
On Android though this is not the case.
Right click — "Copy image" — paste into any program that supports PNG.
On Android though this is not the case.
Really? I'm getting "your browser does not support JPEG XL" in Firefox.
I mean the way to export an arbitrary image in an open format, not JPEG XL support yet.
You can try Firefox Nightly with the jxl flag enabled...
It is a bad idea with lossy compression. Every convertation will make quality worse.
Really?
I find browsers as a software that recognizes fewest number of image formats.
ImageMagick is just few keystroke away and you can convert to almost any format you like.
ImageMagick is just few keystroke away and you can convert to almost any format you like.
Google Image search even does this! Incredibly annoying - only to go to the source image itself and find it to be JPEG or PNG.
Very confused as to why this is done - anyone?
Very confused as to why this is done - anyone?
Check it out with your own eyes with the most recent comparison site for WebP, AVIF and JPEG XL:
https://storage.googleapis.com/demos.webmproject.org/webp/cm...
Most comparison links posted here are to older (almost a year old) versions that don't reflect the current state of encoding. Both JPEG XL and AVIF have improved tremendously.
https://storage.googleapis.com/demos.webmproject.org/webp/cm...
Most comparison links posted here are to older (almost a year old) versions that don't reflect the current state of encoding. Both JPEG XL and AVIF have improved tremendously.
Some notable features of JPEG XL that don't show up in side-by-sides:
1) Progressive decoding. Like the original .jpg, .jxl can give you a low-quality image when a fraction of the file is loaded, then a decent-quality image, then the final image. This can give JPEG XL the edge in perceived load speed even when the full .avif is smaller than the full .jxl. (Old demo from a JXL contributor at https://www.youtube.com/watch?v=UphN1_7nP8U )
2) Fast conversion: JPEG XL encoding/decoding is fast without dedicated hardware. Facebook found encode/decode speed and progressive decoding to be points in favor of JPEG XL for their use: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18
3) .jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller without any additional loss; the original .jpg file can be recovered bit-for-bit.
4) Lossless mode. JXL's lossless mode is the successor to FLIF/FUIF, is really good, and also has progressive decoding. AVIF has a lossless mode too, but JPEG XL seems ahead here.
(I know the parent comment is from a JXL contributor, I'm saying this for other folks.)
I think those will give JPEG XL a niche on the Web. Meanwhile I suspect e.g. Android phone cameras will save .avif someday, like iPhones save .heic now. Phones want the encode hardware anyway for video, and you can crunch a zillion megapixels down to a smaller file with AVIF before attention-grabbing artifacts crop up--at low bitrates AVIF seems good at preserving sharp lines and mostly blurring low-contrast details (compare Tiny images).
Finally, worth noting the codecs are different due to a bunch of rational choices by their devs. AVIF is the format for AV1 video keyframes. Progressive decoding doesn't help there, and doesn't jibe well with spatial prediction, which helps AV1 and other video codecs preserve sharp lines. And video codecs need hardware support to thrive anyway, so optimizing for fast software encoding probably wasn't an early priority. Otherwise the new formats have a lot of overlap in fundamentals--variable size and shape DCTs, better entropy encoding, chroma-from-luma, anti-ringing postfilters, etc.
Glad to see support for both getting more widespread.
1) Progressive decoding. Like the original .jpg, .jxl can give you a low-quality image when a fraction of the file is loaded, then a decent-quality image, then the final image. This can give JPEG XL the edge in perceived load speed even when the full .avif is smaller than the full .jxl. (Old demo from a JXL contributor at https://www.youtube.com/watch?v=UphN1_7nP8U )
2) Fast conversion: JPEG XL encoding/decoding is fast without dedicated hardware. Facebook found encode/decode speed and progressive decoding to be points in favor of JPEG XL for their use: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18
3) .jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller without any additional loss; the original .jpg file can be recovered bit-for-bit.
4) Lossless mode. JXL's lossless mode is the successor to FLIF/FUIF, is really good, and also has progressive decoding. AVIF has a lossless mode too, but JPEG XL seems ahead here.
(I know the parent comment is from a JXL contributor, I'm saying this for other folks.)
I think those will give JPEG XL a niche on the Web. Meanwhile I suspect e.g. Android phone cameras will save .avif someday, like iPhones save .heic now. Phones want the encode hardware anyway for video, and you can crunch a zillion megapixels down to a smaller file with AVIF before attention-grabbing artifacts crop up--at low bitrates AVIF seems good at preserving sharp lines and mostly blurring low-contrast details (compare Tiny images).
Finally, worth noting the codecs are different due to a bunch of rational choices by their devs. AVIF is the format for AV1 video keyframes. Progressive decoding doesn't help there, and doesn't jibe well with spatial prediction, which helps AV1 and other video codecs preserve sharp lines. And video codecs need hardware support to thrive anyway, so optimizing for fast software encoding probably wasn't an early priority. Otherwise the new formats have a lot of overlap in fundamentals--variable size and shape DCTs, better entropy encoding, chroma-from-luma, anti-ringing postfilters, etc.
Glad to see support for both getting more widespread.
Note that AVIF is not just AV1 video keyframes. The entire compliment of AV1 video coding tools (including inter prediction with motion vectors) are available. This includes spatial and temporal scaling.
Note this means that animated images on the web (like GIF) are significantly smaller with AVIF than JPEG-XL which has no inter prediction.
Note this means that animated images on the web (like GIF) are significantly smaller with AVIF than JPEG-XL which has no inter prediction.
Yes, for animation a video codec like AV1 is much more suitable than a still image codec like JPEG XL.
JPEG XL does have some weak forms of inter prediction though (but they were designed mostly for still image purposes). One of them is patches: you can take any rectangle from a previously 'saved' frame (there are four 'slots' for that) and blit it at some arbitrary position in the current frame, using some blend mode of choice (just replace, add, alpha blend over, multiply, alpha blend under, etc). This is obviously not as powerful as full motion vectors etc, but it does bring some possibilities for something like a simple moving sprite animation. This coding tool is currently only used in the encoder for still images, namely to extract repeating text-like elements in an image (individual letters, icons etc) and store them in a separate invisible frame, encoded with non-DCT methods (which are more effective for that kind of thing) and then patch-add them to the VarDCT image. The current jxl encoder is not even trying to be good at animation because this is not quite its purpose (it can do it, but 'reluctantly').
Anyway, I think that animation is in any case best done with video codecs (this is what video codecs are made for), and I wish browsers would just start accepting in an <img> tag all the video codecs they accept in a <video> tag (just played looping, muted, autoplay), so we can for once and for all get rid of GIF.
JPEG XL does have some weak forms of inter prediction though (but they were designed mostly for still image purposes). One of them is patches: you can take any rectangle from a previously 'saved' frame (there are four 'slots' for that) and blit it at some arbitrary position in the current frame, using some blend mode of choice (just replace, add, alpha blend over, multiply, alpha blend under, etc). This is obviously not as powerful as full motion vectors etc, but it does bring some possibilities for something like a simple moving sprite animation. This coding tool is currently only used in the encoder for still images, namely to extract repeating text-like elements in an image (individual letters, icons etc) and store them in a separate invisible frame, encoded with non-DCT methods (which are more effective for that kind of thing) and then patch-add them to the VarDCT image. The current jxl encoder is not even trying to be good at animation because this is not quite its purpose (it can do it, but 'reluctantly').
Anyway, I think that animation is in any case best done with video codecs (this is what video codecs are made for), and I wish browsers would just start accepting in an <img> tag all the video codecs they accept in a <video> tag (just played looping, muted, autoplay), so we can for once and for all get rid of GIF.
I don't think this should be solved with tags (or other OOB methods). Just set a "loop" flag in the container (or metadata). GIF is perfect because it doesn't require ANY additional info when it comes to looping or animation.
Any format that doesn't have this is doomed to fail as a GIF replacement.
Any format that doesn't have this is doomed to fail as a GIF replacement.
++ to making it easier to use other codecs in place of .gif!
Good point. AV1 and AVIF could improve on how some sites (like Twitter) turn actual GIFs into video now.
Also a plus for saving phone snaps, since the camera often saves a short video these days anyway.
Also a plus for saving phone snaps, since the camera often saves a short video these days anyway.
For some images like https://storage.googleapis.com/demos.webmproject.org/webp/cm... jpeg xl is really behind.
They originally chose to use x265 to calibrate the bitrates, possibly something went wrong there and the 'Tiny', 'Big', etc. are somewhat meaningless.
At 'Large' and 'Big' settings of this image -- which are still in much less than 1 bpp bitrates, i.e., below internet image quality -- you can still observe significant differences in the clouds even if balloons are relatively well rendered.
At 'Large' and 'Big' settings of this image -- which are still in much less than 1 bpp bitrates, i.e., below internet image quality -- you can still observe significant differences in the clouds even if balloons are relatively well rendered.
Nothing went wrong there, it's just what you get if you configure an encoder using just some quantization setting and not a visual target. The same will happen if you would encode images with libjpeg quality 50 (and then derive all other bitrates from there). In some cases the image will look OK-ish at that setting, in other cases it will be complete garbage.
JPEG XL is the first codec to have a practical encoder that can be configured by saying "I want the worst visual difference to be X units of just-noticeable-difference". All other encoders are basically configured by saying "I want to use this scaling factor for the quantization tables, and let's hope that the result will look OK".
JPEG XL is the first codec to have a practical encoder that can be configured by saying "I want the worst visual difference to be X units of just-noticeable-difference". All other encoders are basically configured by saying "I want to use this scaling factor for the quantization tables, and let's hope that the result will look OK".
> All other encoders are basically configured by saying "I want to use this scaling factor for the quantization tables, and let's hope that the result will look OK".
crf in x264/x265 is smarter than that, but it's still a closed-form solution. That's probably easier to work with than optimizing for constant SSIM or whatever, it always takes one pass and those objective metrics are not actually very good.
crf in x264/x265 is smarter than that, but it's still a closed-form solution. That's probably easier to work with than optimizing for constant SSIM or whatever, it always takes one pass and those objective metrics are not actually very good.
JPEG XL isn't yet optimised for extremely low bpp. I thought the label for tiny, large and medium etc are sort of misleading without looking at bpp number.
It is a bit like looking at bitrate for Video quality without looking at video resolution.
It is a bit like looking at bitrate for Video quality without looking at video resolution.
The labels are indeed not very useful. It would have been better to use bitrates based on the jxl encoder, which has a perceptual-target based setting (--distance), as opposed to setting it based on absolute HEVC quantization settings (as was done here), which for some images causes 'Big' to be great and for others makes 'Big' still kind of low quality.
When is JPEG XL ready for use? Wikipedia [1] says that Part 4 will be released in 2022?
[1] https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status
[1] https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status
Part 1 and 2 define the codestream and file format, respectively. They are both finalized at the technical level (the ISO process is still ongoing, but there is no more opportunity for technical changes, the JPEG committee has approved the final draft). So it is ready for use now: the bitstream has been frozen since January, free and open source reference software is available.
Part 3 will describe conformance testing (how to verify that an alternative decoder implementation is in fact correct), and part 4 will just be just a snapshot of the reference software that gets archived by ISO, but for all practical purposes you should just get the most recent git version. Parts 3 and 4 are not at all needed to start using JPEG XL.
Part 3 will describe conformance testing (how to verify that an alternative decoder implementation is in fact correct), and part 4 will just be just a snapshot of the reference software that gets archived by ISO, but for all practical purposes you should just get the most recent git version. Parts 3 and 4 are not at all needed to start using JPEG XL.
I've been watching developments here since FLIF days and I wanted to say thank for you for taking the serious time, effort, and tireless communication to see things through the standards processes. That takes perseverance!
Thanks! Yes, it is a long and tricky process (and the hardest part is right now: adoption!).
The quality is normalized to x265 q24 setting. I believe this process/setting is either not working for images or something else went wrong there, because the observable quality as well as the bitrates vary from image to image.
Bitrates vary from 0.26 bpp (Nestor/AVIF) to 4+ bpp (205/AVIF) at the finest setting. Nestor at lowest setting is just 0.05 bpp, somewhat unusual for an internet image. A full HD image at 0.05 bpp transfers over average mobile speed in 5 ms and is 12 kB in size. I rather wait for a full 100 ms and get a proper 1 bpp image.
Bitrates vary from 0.26 bpp (Nestor/AVIF) to 4+ bpp (205/AVIF) at the finest setting. Nestor at lowest setting is just 0.05 bpp, somewhat unusual for an internet image. A full HD image at 0.05 bpp transfers over average mobile speed in 5 ms and is 12 kB in size. I rather wait for a full 100 ms and get a proper 1 bpp image.
It seems to try really hard to preserve high frequencies, where WebP just gives up. Hopefully it's just a question of tuning the quantisation tables for low bitrate.
The differences IMO are even more impressive at higher compression. WebP on "tiny" loses a lot of detail whereas JPEG XL retains most details while still losing overall image quality.
[deleted]
Why does JPEG XL affect the image quality even in lossless mode?
I just compared the original tiger image to the lossless version for JPEG XL but there's some small changes that it makes.
I just compared the original tiger image to the lossless version for JPEG XL but there's some small changes that it makes.
I think this is a quirk in the tool, even if you choose Original on both sides there is some difference that looks like a scaling that's off by a few pixels
The site doesn't state this, but https://jpeg.org/jpegxl/ says:
JPEG XL further includes features such as:
- animation
- alpha channels
- layers
- thumbnails
- lossless and progressive coding
I wonder if progressive loading can halt loading (network I/O) at certain resolutions. This would remove the need of img-sets.
Edit:
Interesting talk at https://www.youtube.com/watch?v=t63DBrQCUWc and https://www.youtube.com/watch?v=RYJf7kelYQQ
Esp. the "visual target" instead of "technical target" when deciding the encoding quality. Also, the lossless and reversible transcoding from JPEG, GIF and PNG.
JPEG XL further includes features such as:
- animation
- alpha channels
- layers
- thumbnails
- lossless and progressive coding
I wonder if progressive loading can halt loading (network I/O) at certain resolutions. This would remove the need of img-sets.
Edit:
Interesting talk at https://www.youtube.com/watch?v=t63DBrQCUWc and https://www.youtube.com/watch?v=RYJf7kelYQQ
Esp. the "visual target" instead of "technical target" when deciding the encoding quality. Also, the lossless and reversible transcoding from JPEG, GIF and PNG.
>I wonder if progressive loading can halt loading (network I/O) at certain resolutions. This would remove the need of img-sets.
Yes, not resolution but predetermined quality levels.
Yes, not resolution but predetermined quality levels.
I was playing with progressive PNGs, and with an "intelligent" web server, it's possible to halt image transmission (either temporarily or permanently) at a server-decided quality level.
Here is a demo, which uses the different resolutions to create a pseudo-animation:
https://www.da.vidbuchanan.co.uk/adamation/image.png
It would be theoretically possible to write a server with a "give me the next quality level now" API endpoint, to enable the client to signal that it's ready for the next resolution.
This is far too janky to be used in production, but at least its fun.
Here is a demo, which uses the different resolutions to create a pseudo-animation:
https://www.da.vidbuchanan.co.uk/adamation/image.png
It would be theoretically possible to write a server with a "give me the next quality level now" API endpoint, to enable the client to signal that it's ready for the next resolution.
This is far too janky to be used in production, but at least its fun.
Interesting, but doing it server side can screw up CDNs (which are quite important for images). It's better if the client takes care of that, so CDNs can cache the full image.
There has to be some incoming header / query param to indicate the resolution the browser is asking for in order know when to stop delivering bytes, so that can be used to vary the CDNs cache key.
I believe it can also resume from where it left off, if you click a thumbnail to get a closer look.
I guess you trade responsiveness for 'on-demand' data transfers. I would guess that the moment you click the button is too late to resume the loading.
Otoh the low-res thumbnail might be just enough to show as a (big) placeholder to bridge the (short) loading time to bring the image to a resolution that the user won't notice a difference.
(brain off ... can't write coherently ...)
Otoh the low-res thumbnail might be just enough to show as a (big) placeholder to bridge the (short) loading time to bring the image to a resolution that the user won't notice a difference.
(brain off ... can't write coherently ...)
I think, though I don't know how good the actual support is, that you can start the download from an arbitrary point so if you already have the thumbnail, you only need to download from that point on. If you are 80% sure people are going to click on the link to zoom, you could preload medium and then only load the final quality after they click.
One of the surprises of progressive loading, and why it's so good that JPEGXL has it, is how quickly you get to "good enough" and showing that before you get all the way to perfect.
One of the surprises of progressive loading, and why it's so good that JPEGXL has it, is how quickly you get to "good enough" and showing that before you get all the way to perfect.
What about meta-data?
The usual XMP and Exif metadata are supported in the file format, as well as JUMBF extensible metadata. It can optionally be Brotli-compressed too.
Chrome status: In developer trial (Behind a flag)
FireFox status: Only in Nightly and behind a flag
https://caniuse.com/?search=jpeg-xl
FireFox status: Only in Nightly and behind a flag
https://caniuse.com/?search=jpeg-xl
Aldo, note that while Edge has initial support as well, it’s behind a command-like attribute rather than a flag. Not sure why they didn’t just do it like Chromium but I have a suspicion they might want to remove it later and replace it with a JPEG XL image extension like they’ve done recently for AVIF etc. The reason is that this then benefits the entire system.
But regardless. All main browsers but Safari will get it. The jury’s still out on Safari/WebKit.
But regardless. All main browsers but Safari will get it. The jury’s still out on Safari/WebKit.
Here is something you can do to enable jxl in Edge without having to pass the command line option:
https://gist.github.com/ziemek99/6295222469218427bb160cf849c...
The Firefox flag is "image.jxl.enabled" and the Chrome flag is "enable-jxl", in case anyone else was searching for jpegxl or something instead.
You don't really need to alter the flags directly if you are on Firefox nightly. Firefox nightly already has a dedicated page for recent experiments in setting page. JPEG XL is already on it for a few months.
That's cool. I've been running Nightly for a while but I haven't been keeping up on new things in that tab.
A game changer delivered by JPEG XL that is often overlooked:
https://www.youtube.com/watch?v=lqi5U6dxeZU&t=223s
To summarize, JPEG XL has the potential to use a single file to deliver many formats. This would deprecate the current practice of web developers storing many versions of the same image to optimize for different device types/sizes.
The advantages are shockingly large:
- It simply is much easier (time saved)
- Huge storage/cost savings for media-heavy sites/apps
- Significant world wide environmental benefit
- Less need for huge platforms (Facebook, Twitter) to aggressively compress photos
- No need to constantly add new sizes, future-proof
A dream feature, if you ask me. Do note that this feature requires both browser and web server support, so don't hold your breath. But one can dream.
https://www.youtube.com/watch?v=lqi5U6dxeZU&t=223s
To summarize, JPEG XL has the potential to use a single file to deliver many formats. This would deprecate the current practice of web developers storing many versions of the same image to optimize for different device types/sizes.
The advantages are shockingly large:
- It simply is much easier (time saved)
- Huge storage/cost savings for media-heavy sites/apps
- Significant world wide environmental benefit
- Less need for huge platforms (Facebook, Twitter) to aggressively compress photos
- No need to constantly add new sizes, future-proof
A dream feature, if you ask me. Do note that this feature requires both browser and web server support, so don't hold your breath. But one can dream.
Very nice practical feature: "Existing JPEG data can be represented as-is in JPEG XL: no lossy transcoding!" If you need ever to convert huge amount of archieved jpeg, you can config the conversion not to lose anything.
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLj...
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLj...
I know it's not the same, but technically you could do that with every format: just ship a JPEG decoder and detect if the input is a JPEG. The other way round would be much cooler, i.e. if each JPEG XL file also was a valid JPEG.
Sure, if you didn't care about the size of the file you could do lots of silly cross-format things.
I really want this to work.
As has been pointed out in the comments, it needs to be adopted beyond the browser. And easily.
Anyone hear of FlashPix[0]?
Anyone?
Bueller?
It was a staged-resolution format that was introduced by a consortium in the 1990s.
The biggest problem (of many) was that, in order to read or write the format, you needed to use the Microsoft Structured Storage[1] library, which was a huge pig (at that time. I assume it's better, these days).
The format was basically strangled in the crib. It was actually a fairly interesting idea, at the time, but files could be huge.
[0] https://en.wikipedia.org/wiki/FlashPix
[1] https://en.wikipedia.org/wiki/COM_Structured_Storage
As has been pointed out in the comments, it needs to be adopted beyond the browser. And easily.
Anyone hear of FlashPix[0]?
Anyone?
Bueller?
It was a staged-resolution format that was introduced by a consortium in the 1990s.
The biggest problem (of many) was that, in order to read or write the format, you needed to use the Microsoft Structured Storage[1] library, which was a huge pig (at that time. I assume it's better, these days).
The format was basically strangled in the crib. It was actually a fairly interesting idea, at the time, but files could be huge.
[0] https://en.wikipedia.org/wiki/FlashPix
[1] https://en.wikipedia.org/wiki/COM_Structured_Storage
> The biggest problem (of many) was that, in order to read or write the format, you needed to use the Microsoft Structured Storage[1] library, which was a huge pig (at that time. I assume it's better, these days).
HEIC and AVIF are based on the QuickTime file format, which doesn't seem very svelte either. I can't find any reference on the JPEG XL container format so it's probably it's own thing.
HEIC and AVIF are based on the QuickTime file format, which doesn't seem very svelte either. I can't find any reference on the JPEG XL container format so it's probably it's own thing.
HEIC and AVIF are both based on HEIF, which is based on ISOBMFF (just like for example MP4).
The JPEG XL container (which is optional and only needed if you want to attach metadata to an image) is also based (more directly and with less header overhead) on ISOBMFF.
The JPEG XL container (which is optional and only needed if you want to attach metadata to an image) is also based (more directly and with less header overhead) on ISOBMFF.
The ISO media file format is, like GP said, basically QuickTime.
This can be a problem if you're the kind of completionist who needs to implement everything they see and make one C++ class per QuickTime atom - a problem I saw with a lot of mp4 codebases.
But there's no need to do this because almost all the things in the spec don't matter. Just don't read any of them and handle the rest procedurally and it'll be fine. It looks like JPEG XL also has too many features (like this animation and patching thing) so maybe just ignore that too.
This can be a problem if you're the kind of completionist who needs to implement everything they see and make one C++ class per QuickTime atom - a problem I saw with a lot of mp4 codebases.
But there's no need to do this because almost all the things in the spec don't matter. Just don't read any of them and handle the rest procedurally and it'll be fine. It looks like JPEG XL also has too many features (like this animation and patching thing) so maybe just ignore that too.
Ignoring stuff is fine if you make an encoder. When you're making a decoder, it's a big no-go. If implementers of the original JPEG would have implemented the whole spec, we would have 12-bit and lossless JPEGs. Instead we're stuck with the de facto JPEG standard, the subset of the spec that everyone ended up implementing.
libjpeg supports that with a compile time option. Nobody used it because you can't abstract over bit-depth (and sometimes pixel format) without losing all performance, because it means a lot of if statements have to go inside every hot loop, so instead you have to duplicate all related code. Also, there wasn't a way to view them until HDR displays came around recently.
The main issue with implementing all of MPEG-4 is the spec is overdetermined (the same fields exist at different layers and can disagree), but also it's full of nonsense nobody cares about, like the alternate codec for animating faces only.
https://core.ac.uk/download/pdf/207365065.pdf
The main issue with implementing all of MPEG-4 is the spec is overdetermined (the same fields exist at different layers and can disagree), but also it's full of nonsense nobody cares about, like the alternate codec for animating faces only.
https://core.ac.uk/download/pdf/207365065.pdf
> When you're making a decoder, it's a big no-go.
I remember one of my first big OO projects was writing a TIFF reader.
What a nightmare.
I remember one of my first big OO projects was writing a TIFF reader.
What a nightmare.
Good chance it’s TIFF, like JFIF.
No thanks, the only TIFF you'll find in a JXL is the (optional) Exif metadata.
I was really excited about JPEG 2000 when I first heard about it in the mid 2000s. As is tradition it was pretty much killed by the possibility of patents that weren't part of the industry agreement.
JPEG2000 just wasn't a great format either. Wavelets don't compress well because they get blurry, which isn't pleasant to look at, and it's slow to decode, so sticking with JPEG was a good idea. Similar issues with WebP, it wasn't good enough to move to.
That might've been true at the time. But what about today? Can't we use the higher settings for JPEG 2000? At least speed shouldn't be an issue now.
Hmm I don’t know enough to say, but speed is still important because speed = battery life.
The counterpoint to that is that some things are fast in hardware even if slow in software. H.264 is like this due to some design mistakes but JPEG2K could be the other way round.
The counterpoint to that is that some things are fast in hardware even if slow in software. H.264 is like this due to some design mistakes but JPEG2K could be the other way round.
Somewhat unfortunate naming for a format that presumably tries to be as small as possible.
I first thought the name must be a clever pun when I saw that the original JPEG was dated 1992. But sadly my brain was off by a decade, JPEG XL is in fact not JPEG 40.
They could have gone with JPEG XXL or JPEG XXX but the former is a bit too fanciful and the latter might cause some adoption problems outside a certain niche industry.
They could have gone with JPEG XXL or JPEG XXX but the former is a bit too fanciful and the latter might cause some adoption problems outside a certain niche industry.
JPEG MMXXI ?
JPEG-XL can encode huge images, whereas JPEG is limited to a maximum width and height of 65535 pixels.
Is support for 5 gigapixel images really such a killer feature to put it in the name?
That's not where the name comes from :)
https://en.wikipedia.org/wiki/JPEG_XL#Name
https://en.wikipedia.org/wiki/JPEG_XL#Name
It's also very similar to JPEG-XR.
And JPEG XT. And JPEG XS.
I prefer calling it JXL (or jxl) which is visually sufficiently unique to avoid confusion.
I prefer calling it JXL (or jxl) which is visually sufficiently unique to avoid confusion.
Very curious to see if this codec gets implemented into After Effects. I've been rendering out of Maya to a PNG sequence for many years since it's lossless and includes an alpha channel. But the decompression times leave me wishing for TIFF, TARGA, EXR, or such... But the cumulative file size difference is dramatic. And that matters when I'm rendering for example 10 tests, each with 2 layers, and also each have 10,000 frames.
Does After Effects support APNG? Most browsers do.
https://en.wikipedia.org/wiki/APNG
https://en.wikipedia.org/wiki/APNG
This is not at all what it is for. Being an intermediary isn't even what png is for. Exr is made for it and can zip compress individual lines while having 16 or 32 bit floats per channel.
JPEG XL can do lossless compression of 16-bit or 32-bit (or even 24-bit and other custom float types) float data, just like EXR. It can do pretty fast encode/decode (for mezzanine use cases) and also (if you have time for encoding) it can do the densest lossless compression.
The point here is that EXR has taken care of being an intermediate format for 20 years but this person is using pngs and is hoping jpegxl fills the same slot of a solved problem.
> It can do pretty fast encode/decode (for mezzanine use cases)
I'm not sure what this means, but zipping individual lines takes care of the interactivity problem of working with compressed intermediary frames.
> It can do pretty fast encode/decode (for mezzanine use cases)
I'm not sure what this means, but zipping individual lines takes care of the interactivity problem of working with compressed intermediary frames.
My biggest image format question, which I haven’t seen a clear answer to, is as an iPhone camera user should I be keeping the JPEG or the HEIC as my archival format? I theorized the HEIC had more information, but I don’t really know. Unfortunately keeping both is a usability nightmare in all the tools I’ve seen. Anyone have an informed opinion or good link?
Apple used to have a spectacular record with stable formats: see HFS+.
Unfortunately, over the last several years, that's gone out the window.
Mojave can't read some Big Sur volumes, even though both are using "Apple File System".
HEIC image formats coming out of iPhones have changed /several/ times in the past couple years: witness the scrambling by the libheif project as they find out they can't read images from the latest iDevice.
Apple's in-device conversion to JPEG is lossy, but I don't expect you will notice. Most of the metadata it's retained (at least with the current iOS), and I couldn't see egregious artifacting.
I'd personally keep the original and hope tooling keeps up with Apple shenanigans, but disk is cheap, and if you're worried at all, use `sips` (if you're on a Mac), the built-in "compatibility mode" conversion, or `heif-convert` to transcode to JPEG.
(Source: building support for HEIC in PhotoStructure)
Unfortunately, over the last several years, that's gone out the window.
Mojave can't read some Big Sur volumes, even though both are using "Apple File System".
HEIC image formats coming out of iPhones have changed /several/ times in the past couple years: witness the scrambling by the libheif project as they find out they can't read images from the latest iDevice.
Apple's in-device conversion to JPEG is lossy, but I don't expect you will notice. Most of the metadata it's retained (at least with the current iOS), and I couldn't see egregious artifacting.
I'd personally keep the original and hope tooling keeps up with Apple shenanigans, but disk is cheap, and if you're worried at all, use `sips` (if you're on a Mac), the built-in "compatibility mode" conversion, or `heif-convert` to transcode to JPEG.
(Source: building support for HEIC in PhotoStructure)
HEIC is in general better than JPEG (as a codec; not in terms of interoperability), but the way Apple does HEIC, I strongly suspect that JPEG is actually a better choice. Your files will of course be larger, but the HEIC will be a bit overcompressed compared to the JPEG: it will have some blurring/smearing artifacts that the JPEG will not have.
The reason is that they do fast hardware HEIC encoding at relatively aggressive quality settings in order to get the file size savings they want to boast about. They claim the quality to be the same, but that's not actually true. It is a lower quality.
One advantage of HEIC though is that it can also contain the depth map (in 'Portrait mode'), which I assume gets lost when you use JPEG. This is the information that gives a rough separation of foreground and background, so you can later do effects like applying bokeh to the background only.
The reason is that they do fast hardware HEIC encoding at relatively aggressive quality settings in order to get the file size savings they want to boast about. They claim the quality to be the same, but that's not actually true. It is a lower quality.
One advantage of HEIC though is that it can also contain the depth map (in 'Portrait mode'), which I assume gets lost when you use JPEG. This is the information that gives a rough separation of foreground and background, so you can later do effects like applying bokeh to the background only.
The depth map is actually stored as an image: PhotoStructure accidentally used them as preview images several versions back (when depth maps were fairly novel) and I had some interesting discussions with users complaining about "ghosts" in their library:
https://forum.photostructure.com/t/i-see-ghosts/41
https://forum.photostructure.com/t/i-see-ghosts/41
The Apple portrait depth map is also stored in a JPEG. I believe they use MPO. The Google camera can do it too. Apparently it uses XMP metadata for this purpose.
If you want to preserve fidelity indefinitely, PNG or RAW might be a better bet. Lossless formats usually are better for archival, you can always get a lossy compression out of it later and don't have to worry about generational losses.
.. but this is an iPhone, so the options for "original" are HEIC, JPEG, and "proraw" https://support.apple.com/en-gb/HT211965
I don't have an iPhone, hence a minor speculation on what it supports, if you forgive that.
If you're looking into archival, you'll probably want the PRORAW then, sounds like that is the lossless format.
Converting from JPEG/HEIV to lossless is a bit of a pointless thing to do, you already incur generational loss from that.
If you're looking into archival, you'll probably want the PRORAW then, sounds like that is the lossless format.
Converting from JPEG/HEIV to lossless is a bit of a pointless thing to do, you already incur generational loss from that.
For archival, you need to worry about long term ability
to read the format easily. JPEG wins that fight out of the three easily.
RAW is a very old format that has been around for some time, Apple's ProRAW is backwards compatible and has some additional metadata attached (IIRC ProRaw attaches the image pipeline the iphone would have used, so that image software can recover this and produce the same image the iphone would have after the image pipeline). RAW is older (1988) than JPEG (1992), largely because RAW is largely based on TIFF (and any vendor specific variation is usually TIFF-like too) in it's mid-1980s state. The latest standard RAW standard (TIFF/EP) is from 2001.
So in terms of long term ability to read... RAW wins, various versions aren't as old but JPEG got it's fair few of extensions too.
For long term readability, I don't think JPEG would win on another standpoint; bitrot. It'll happen eventually, even if you use ZFS, you will eventually loose some bits. Maybe a sector of data. JPEG doesn't like loosing parts of the file.
On the other hand, a TIFF file can be recovered from bitrot, if you don't mind loosing a part of the image. Because there is no compression, loosing a sector of data amounts to loosing the bits on that sector. The only sensitive part of the file would be the header, which isn't terribly complex and can be typed on notepad if needed be.
So in terms of long term ability to read... RAW wins, various versions aren't as old but JPEG got it's fair few of extensions too.
For long term readability, I don't think JPEG would win on another standpoint; bitrot. It'll happen eventually, even if you use ZFS, you will eventually loose some bits. Maybe a sector of data. JPEG doesn't like loosing parts of the file.
On the other hand, a TIFF file can be recovered from bitrot, if you don't mind loosing a part of the image. Because there is no compression, loosing a sector of data amounts to loosing the bits on that sector. The only sensitive part of the file would be the header, which isn't terribly complex and can be typed on notepad if needed be.
You obviously have a very different experience with TIFF or RAW than I have had?
Every vendor and application has weird extensions or behaviors with the format that means only custom built support for the software that makes it actually works well.
Every piece of software on the planet seems to support jpeg out of the box.
Every vendor and application has weird extensions or behaviors with the format that means only custom built support for the software that makes it actually works well.
Every piece of software on the planet seems to support jpeg out of the box.
“raw” is a generic term that refers to many different raw formats, most of them compressed.
If you care about bit rot then add some parity.
Or even store multiple copies, it's still smaller!
Or even store multiple copies, it's still smaller!
Multiple copies of a smaller file are still susceptible to bit rot. In fact, RAW is still more resistant because it can still be read even if multiple sectors corrupt, while many small files might each individually be toast.
(And btw, parity doesn't protect you from bitrot forever, only for like a decade or two)
(And btw, parity doesn't protect you from bitrot forever, only for like a decade or two)
If you have three copies then you can automatically heal from any single sector going bad, and semi-automatically heal from a sector going bad in the same spot in two copies at once. Or you could make five copies even.
> (And btw, parity doesn't protect you from bitrot forever, only for like a decade or two)
Based on what settings and what environment?
By the time you're losing a large percentage of your sectors, you're probably losing everything regardless of format. You don't use file formats to protect from entire disks or tapes failing.
Also, if you set up paranoid levels of parity you can recover a perfect image even when a RAW file would be covered in gaps and noise, while still being a lot smaller.
> (And btw, parity doesn't protect you from bitrot forever, only for like a decade or two)
Based on what settings and what environment?
By the time you're losing a large percentage of your sectors, you're probably losing everything regardless of format. You don't use file formats to protect from entire disks or tapes failing.
Also, if you set up paranoid levels of parity you can recover a perfect image even when a RAW file would be covered in gaps and noise, while still being a lot smaller.
And at what paranoia level would you rather loose data to lossy compression than use the original without and just spend a dollar more on storage?
Let's assume I'm willing to spend the dollar more on storage for both options.
I can either store one copy of a RAW, or I can store an unholy ball of parity that's exactly the same size.
The unholy ball of parity can lose up to 90% of the data and still be completely recovered, giving you a very high quality image, but if you lose more than 90% you get nothing.
A RAW image degrades more and more as you lose data, and if you lose 90% it's going to be useless anyway.
I'll definitely pick the compression+parity option.
I can either store one copy of a RAW, or I can store an unholy ball of parity that's exactly the same size.
The unholy ball of parity can lose up to 90% of the data and still be completely recovered, giving you a very high quality image, but if you lose more than 90% you get nothing.
A RAW image degrades more and more as you lose data, and if you lose 90% it's going to be useless anyway.
I'll definitely pick the compression+parity option.
ProRAW is lossless, if you’re willing to pay the size price (~40MB/image.)
If you convert the full-resolution JPEG/HEIC to PNG you won't lose any information, right?
Technically, you do lose _some_ information. PNG cannot represent DCT coefficients nor YCbCr data, and the conversion of those things to (8-bit) RGB is a (slightly) lossy operation.
Sure, but what's the advantage to blowing up the file size to losslessly preserve all the lossy artifacts from JPEG or HEIC?
Is it just me or do all the comparisons linked from the page show that webp actually looks better?
Still, the JPEG recompression feature might be what helps adoption.
Still, the JPEG recompression feature might be what helps adoption.
By golly, you're right.
eg. https://eclipseo.github.io/image-comparison-web/#us-open&WEB... The player is missing the corner of her mouth in the JXL version.
JXL Medium (32KB) is about the same quality as WebP Small (19KB)
eg. https://eclipseo.github.io/image-comparison-web/#us-open&WEB... The player is missing the corner of her mouth in the JXL version.
JXL Medium (32KB) is about the same quality as WebP Small (19KB)
Although the Moscow demo[0] look better (in my eyes) in jxl than wepb.
Note also that JXL is still being worked on. We have no information also about which encoder was used (I am assuming the reference encoder, since it is the only one that I know off right now) and which version.
Edit: the Citroën demo is also a clear win for JXL.
[0] https://eclipseo.github.io/image-comparison-web/#moscow&WEBP...
Note also that JXL is still being worked on. We have no information also about which encoder was used (I am assuming the reference encoder, since it is the only one that I know off right now) and which version.
Edit: the Citroën demo is also a clear win for JXL.
[0] https://eclipseo.github.io/image-comparison-web/#moscow&WEBP...
One case where JXL is very noticeably more accurate is here: https://storage.googleapis.com/demos.webmproject.org/webp/cm...
The singer’s left hand has wrinkles in the original image that disappear in WebP2.
Overall, WebP2 and especially AVIF are really good at very low bitrates (<1 bit per pixel), but unlike video, images on the Web will always be shown at the smallest bitrate necessary to be indistinguishable from the original; there, JXL tends to show all the details at a lower bitrate.
The singer’s left hand has wrinkles in the original image that disappear in WebP2.
Overall, WebP2 and especially AVIF are really good at very low bitrates (<1 bit per pixel), but unlike video, images on the Web will always be shown at the smallest bitrate necessary to be indistinguishable from the original; there, JXL tends to show all the details at a lower bitrate.
I'd say JXL Medium is slightly better than WebP Small - compare e.g. the racket, face, and left hand.
But it's also slightly worse than WepB Medium, e.g. with the corner of her mouth.
But it's also slightly worse than WepB Medium, e.g. with the corner of her mouth.
JXL's design operating point is "no visible compression artefacts".
Most people do not want to have visible compression artefacts on the images they put on their web pages. JXL starts from this premise and tries to answer the question: "How small can we then make the image?"
Care must be taken when trying to compare the performance of image codecs by increasing compression density until there are very visible compression artefacts and then evaluating whether A's or B's artefacts look worse: If both A's and B's artefacts are so bad that one would not want to put such an image on one's website, such an experiment gives no insight on what one would pick for images that one would actually put on one's website.
Figuratively speaking, if I buy a shirt, my main criterion is that it looks good in good condition, and not that it still looks good if I put a coffee stain on it.
So, before comparing codec quality at compression levels where artefacts show, always ask yourself: At that level of visual quality, would I actually want to put either of the two options on my website? Now, it is of course tempting to compare "away from the actual operating point", because it is just so much easier to do comparisons if there are very visible differences. Comparing near-identical images for quality is hard. Doing this over and over again in a human rater experiment is exhausting. But that's then answering the actual performance questions that need to be answered.
Most people do not want to have visible compression artefacts on the images they put on their web pages. JXL starts from this premise and tries to answer the question: "How small can we then make the image?"
Care must be taken when trying to compare the performance of image codecs by increasing compression density until there are very visible compression artefacts and then evaluating whether A's or B's artefacts look worse: If both A's and B's artefacts are so bad that one would not want to put such an image on one's website, such an experiment gives no insight on what one would pick for images that one would actually put on one's website.
Figuratively speaking, if I buy a shirt, my main criterion is that it looks good in good condition, and not that it still looks good if I put a coffee stain on it.
So, before comparing codec quality at compression levels where artefacts show, always ask yourself: At that level of visual quality, would I actually want to put either of the two options on my website? Now, it is of course tempting to compare "away from the actual operating point", because it is just so much easier to do comparisons if there are very visible differences. Comparing near-identical images for quality is hard. Doing this over and over again in a human rater experiment is exhausting. But that's then answering the actual performance questions that need to be answered.
^^^ This.
Comparing artifacts at 0.2 bpp is tempting because the artifacts are big there. But it's like buying a car based on how it performs when you are using only the first gear.
Comparing artifacts at 0.2 bpp is tempting because the artifacts are big there. But it's like buying a car based on how it performs when you are using only the first gear.
This blog, linked from the original article goes into this idea in detail, describing how JXL was focused on improving compression of high fidelity images, and has not focused as much on the appeal of highly compressed images.
https://cloudinary.com/blog/what_to_focus_on_in_image_compre...
https://cloudinary.com/blog/what_to_focus_on_in_image_compre...
Great point!
You can get a more up-to-date comparison from the WebP team's comparison page: https://storage.googleapis.com/demos.webmproject.org/webp/cm...
Internet uses jpeg qualities that average around 2-3 bpp today, and an improvement in compression density through a new format that compresses 50 % better would push it down to 1-1.5 bpp. The comparison tool displays the bitrates when you hover on the images.
Internet uses jpeg qualities that average around 2-3 bpp today, and an improvement in compression density through a new format that compresses 50 % better would push it down to 1-1.5 bpp. The comparison tool displays the bitrates when you hover on the images.
Yeah, I agree that webp looks better for many of the images. For most of them it comes back to the subjective issue that webp (and VP9) choose to err on the side of blurring detail they can't encode, while jpeg XL (and x264, etc) try to keep all the detail they can at the expense of more artifacts. There are very vocal proponents of both approaches, and personally I think it varies by the image content.
For all these examples, I was comparing at Small (as with Tiny they were both bad enough but in different ways that I often couldn't decide which was least bad). For the Abandoned Factory and Panthera Tigres, I think the extra detail of JXL looks better than the blurring of WEBP. On the otherhand, I think WEBP looks cleaner than JXL for Buenos Aires, Reykjavik, B-24 Bombers without loosing significant detail. And Avenches is a mix as JXL looks much better than WEBP for the trees and tile roof, but has worse chroma artifacts near the edges of the hat and clothing.
But that isn't the whole story, as for some of the images WEBP seems to both preserve more detail, and have fewer artifacts, such as Air Force Academy Chapel, Pont de Quebec, Steinway and White Dunes. What all these cases seem to have in common is a smooth gradient adjacent to sharp detail. WEBP seems to do a much better job of dealing with that boundary by blurring the smooth part, put preserving the sharp lines.
And if you bump up to WEBP2, the number of cases where it both preserves more detail and has fewer artifacts than JXL increases significantly.
For all these examples, I was comparing at Small (as with Tiny they were both bad enough but in different ways that I often couldn't decide which was least bad). For the Abandoned Factory and Panthera Tigres, I think the extra detail of JXL looks better than the blurring of WEBP. On the otherhand, I think WEBP looks cleaner than JXL for Buenos Aires, Reykjavik, B-24 Bombers without loosing significant detail. And Avenches is a mix as JXL looks much better than WEBP for the trees and tile roof, but has worse chroma artifacts near the edges of the hat and clothing.
But that isn't the whole story, as for some of the images WEBP seems to both preserve more detail, and have fewer artifacts, such as Air Force Academy Chapel, Pont de Quebec, Steinway and White Dunes. What all these cases seem to have in common is a smooth gradient adjacent to sharp detail. WEBP seems to do a much better job of dealing with that boundary by blurring the smooth part, put preserving the sharp lines.
And if you bump up to WEBP2, the number of cases where it both preserves more detail and has fewer artifacts than JXL increases significantly.
> Yeah, I agree that webp looks better for many of the images. For most of them it comes back to the subjective issue that webp (and VP9) choose to err on the side of blurring detail they can't encode, while jpeg XL (and x264, etc) try to keep all the detail they can at the expense of more artifacts. There are very vocal proponents of both approaches, and personally I think it varies by the image content.
In VP9/WebP this wasn't a "choice" so much as they were optimizing for good looking marketing graphs instead of pictures. You get blurry images if you target a metric like PSNR instead of actually looking at your output. x264 does have a few different tunings, the film one will try to turn detail to noise and the animation one won't.
In VP9/WebP this wasn't a "choice" so much as they were optimizing for good looking marketing graphs instead of pictures. You get blurry images if you target a metric like PSNR instead of actually looking at your output. x264 does have a few different tunings, the film one will try to turn detail to noise and the animation one won't.
The amount of artefacts should be substantially reduced in JPEG XL in the next round of comparisons.
Last week I submitted the 'ac strategy decision tree traversal' change to libjxl, which reduces ringing artefacts substantially, often by 60-70 %. It does a diligent job by choosing the best combination of small integral transforms (there are 10 different 8x8 transforms) instead of just satisfying with a large transform.
This change also improves on image quality, sharpness and truthfulness, it doesn't just blur the artefacts away.
Last week I submitted the 'ac strategy decision tree traversal' change to libjxl, which reduces ringing artefacts substantially, often by 60-70 %. It does a diligent job by choosing the best combination of small integral transforms (there are 10 different 8x8 transforms) instead of just satisfying with a large transform.
This change also improves on image quality, sharpness and truthfulness, it doesn't just blur the artefacts away.
On discord someone posted a before-after-original animations about last week's improvements in low-bpp JPEG XL compression for anime drawings: https://cdn.discordapp.com/attachments/852294618694942750/85...
This JPEG XL quality improvement has not yet landed in online comparison tools.
This JPEG XL quality improvement has not yet landed in online comparison tools.
Lossless JPEG transcoding making images 20% smaller is nice, though you can already losslessly shrink many JPEG files by up to 10% by using https://github.com/tjko/jpegoptim/ and making them interlaced.
Related ongoing thread, complete with newly-added title qualification:
JPEG XL would be Turing-complete without the 1024×1024 pixel limitation - https://news.ycombinator.com/item?id=27559748 - June 2021 (34 comments)
JPEG XL would be Turing-complete without the 1024×1024 pixel limitation - https://news.ycombinator.com/item?id=27559748 - June 2021 (34 comments)
Comment from Facebook Infra [1],
>Erik Andre from the Images Infra team at Facebook here. I'd like to share a bit of our view on JPEG XL in the context of new image formats (e.g AVIF, JPEG XL, WEBP2, ...) and how browser adoption will let us move forward with our plans to test and hopefully roll out JPEG XL.
>After spending the last 5 months investigating and evaluating JPEG XL from both a performance and quality point of view, it's our opinion that JPEG XL has the most potential of the new generation of image formats that are trying to succeed JPEG.
>This opinion is based on the following findings:
>JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). This means that it's practical to encode JPEG XL images on the fly and serve to client. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers much less flexibility when it comes to delivering dynamically sized and compressed content. Depending on the settings used, JPEG XL can also be very fast to decode. Our mobile benchmarks show that we can reach parity with JPEG when using multiple threads to decode. This matches and in many cases surpasses the decoding performance of other new image formats. The JPEG XL image format supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.
>Having browser support from all the major browsers is going to make our lives a lot easier in upcoming WWW experiments and ensure that we can deliver a consistent experience across platforms and browsers.
Blink Tracking Bug [2] currently behind a flag ,Firefox on both [1] and [3], currently in about:preferences#experimental on Firefox Nightly. If I remember correctly it is supported on Edge behind a parameter as well. I thought it was all very quiet after the standard was published, turns out both Chrome and Firefox intent to support it.
AFAIK, neither Webkit nor Safari has any plan or intention to support JPEGXL. I think ( someone correct me if I am wrong ) Safari uses macOS image decoding library. So supporting JPEGXL may come from an OS update and not browser?
Finally, an open standard, Royalty Free, open-source reference implementation, and it is nearly better than all other alternative. As an image format on the web it is quite possibly close to perfect [4]. It is exciting and I hope JPEG XL will succeed.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1707590
[4] I remember the conversion from a little more than 6 months ago current encoder is not optimised for image quality below bpp 1.0, those are going to be the focus once all the initial reference encoder and decoder standards and issues are done. So in case anyone wondering it doesn't look as good as other competitors ( but still a lot better than JPEG ), those improvements are coming later.
>Erik Andre from the Images Infra team at Facebook here. I'd like to share a bit of our view on JPEG XL in the context of new image formats (e.g AVIF, JPEG XL, WEBP2, ...) and how browser adoption will let us move forward with our plans to test and hopefully roll out JPEG XL.
>After spending the last 5 months investigating and evaluating JPEG XL from both a performance and quality point of view, it's our opinion that JPEG XL has the most potential of the new generation of image formats that are trying to succeed JPEG.
>This opinion is based on the following findings:
>JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). This means that it's practical to encode JPEG XL images on the fly and serve to client. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers much less flexibility when it comes to delivering dynamically sized and compressed content. Depending on the settings used, JPEG XL can also be very fast to decode. Our mobile benchmarks show that we can reach parity with JPEG when using multiple threads to decode. This matches and in many cases surpasses the decoding performance of other new image formats. The JPEG XL image format supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.
>Having browser support from all the major browsers is going to make our lives a lot easier in upcoming WWW experiments and ensure that we can deliver a consistent experience across platforms and browsers.
Blink Tracking Bug [2] currently behind a flag ,Firefox on both [1] and [3], currently in about:preferences#experimental on Firefox Nightly. If I remember correctly it is supported on Edge behind a parameter as well. I thought it was all very quiet after the standard was published, turns out both Chrome and Firefox intent to support it.
AFAIK, neither Webkit nor Safari has any plan or intention to support JPEGXL. I think ( someone correct me if I am wrong ) Safari uses macOS image decoding library. So supporting JPEGXL may come from an OS update and not browser?
Finally, an open standard, Royalty Free, open-source reference implementation, and it is nearly better than all other alternative. As an image format on the web it is quite possibly close to perfect [4]. It is exciting and I hope JPEG XL will succeed.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1707590
[4] I remember the conversion from a little more than 6 months ago current encoder is not optimised for image quality below bpp 1.0, those are going to be the focus once all the initial reference encoder and decoder standards and issues are done. So in case anyone wondering it doesn't look as good as other competitors ( but still a lot better than JPEG ), those improvements are coming later.
That's correct, Safari does its image decoding via OS-level image decoding (https://developer.apple.com/documentation/coreimage).
The only power Safari devs basically have is to decide which OS-supported formats to enable/allow and which ones to disable (e.g. JPEG 2000 is enabled but HEIC isn't).
So getting JPEG XL supported in Safari will most likely first require it to be supported in MacOS and iOS. If you have an Apple device and would like it to get JPEG XL support, then feel free to open a Feedback Assistant ticket (there's an OS-level application to do that) to make a feature request. (I did that 5 weeks ago but haven't heard back yet)
The only power Safari devs basically have is to decide which OS-supported formats to enable/allow and which ones to disable (e.g. JPEG 2000 is enabled but HEIC isn't).
So getting JPEG XL supported in Safari will most likely first require it to be supported in MacOS and iOS. If you have an Apple device and would like it to get JPEG XL support, then feel free to open a Feedback Assistant ticket (there's an OS-level application to do that) to make a feature request. (I did that 5 weeks ago but haven't heard back yet)
You probably meant the Image I/O framework, not the CoreImage framework.
https://developer.apple.com/documentation/imageio/
https://developer.apple.com/documentation/imageio/
Huh. So that explains why WEBP worked in Safari 14 for Big Sur but not Catalina or Mojave.
I'm looking at an original vs jpeg-xl in lossless and it seems that jpeg-xl alters the colors (blue in particular) noticeably?
https://eclipseo.github.io/image-comparison-web/#abandonned-...
Not sure if this is a good or bad thing.
EDIT: Looking at https://eclipseo.github.io/image-comparison-web/#japan-expo&... some details about the metallic structure in the background are noticeably worse (less defined) in the jpeg-xl version.
https://eclipseo.github.io/image-comparison-web/#abandonned-...
Not sure if this is a good or bad thing.
EDIT: Looking at https://eclipseo.github.io/image-comparison-web/#japan-expo&... some details about the metallic structure in the background are noticeably worse (less defined) in the jpeg-xl version.
If Original vs Lossless does not look the same, it is because your browser does not do color management correctly. JPEG XL's lossless is mathematically lossless, so there cannot be any actual difference.
What can happen though is that the "Original PNG" doesn't have an ICC profile and gets treated by your browser in a different way than the PNG produced by the jxl decoder. This is a problem of your browser though, not of JPEG XL, and likely the image you see for "lossless JPEG XL" is the correct one.
What can happen though is that the "Original PNG" doesn't have an ICC profile and gets treated by your browser in a different way than the PNG produced by the jxl decoder. This is a problem of your browser though, not of JPEG XL, and likely the image you see for "lossless JPEG XL" is the correct one.
According to IrfanView, the Lossless JPEG XL one has 167959 unique colors, while the original one has 233263.
For me it looks different in Firefox, the same in Brave (the uncompressed one in Firefox is the odd one out)
For me it looks different in Firefox, the same in Brave (the uncompressed one in Firefox is the odd one out)
I'm curious how IrfanView is counting colors then.
Looks identical on Windows, Chrome Canary 93.0.4549.0
Both comparisons appear identical to me in Firefox.
In Chrome it looks identical.
While the collaboration between Google and Cloudinary is very welcome and the JPEG standardisation will accelerate adoption, it would be nice to see a comparison of JPEG XL versus FLIF/FUIF, it doesn't seem to have improved over it and it is unclear if it retains all features such as progressive decoding of animated images Cf https://flif.info/animation.html
JPEG XL's Modular mode is based on the best elements of FLIF/FUIF and lossless WebP. For lossless compression, it does improve quite significantly over FLIF, see e.g. https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...
(FLIF is on average 7.2% larger than JXL, and for some categories like pixel art the gap is larger). It also decodes significantly faster, and it has fast encode options that make it more suitable as a PNG replacement in image authoring use cases where density is not the most important thing.
Progressive animation is a neat feature of FLIF but it is totally impractical in terms of decode speed and memory consumption. In general I think animation is better handled with video codecs (with multiple resolutions/bitrates to cover various devices/network conditions).
Progressive animation is a neat feature of FLIF but it is totally impractical in terms of decode speed and memory consumption. In general I think animation is better handled with video codecs (with multiple resolutions/bitrates to cover various devices/network conditions).
Well, the author of FLIF/FUIF, Jon Sneyers, is actually a large contributor to Jpeg XL, and from what I've seen he thinks Jpeg XL is superior.
Interesting, any source? I wonder in what way he finds it superior.
He's written about it in his blog: https://cloudinary.com/blog/author/jon_sneyers
Oh nice, it seems they learned from the JPEG2000 fiasco and released this with an open source license.
https://gitlab.com/wg1/jpeg-xl/-/blob/master/LICENSE
https://gitlab.com/wg1/jpeg-xl/-/blob/master/LICENSE
Curious to see how it compares to BGP:
https://bellard.org/bpg/
Comparison:
http://xooyoozoo.github.io/yolo-octo-bugfixes/
But again, the main bottleneck with image compression is embedded software, like smartphone, cameras, etc. There is a compromise and cost/benefit between file size, transistor requirement, CPU cycles, power required, etc.
For example, I would be interested to see the size of binary code required to compress JPG, JPG XL, BGP, WEBP, etc.
https://bellard.org/bpg/
Comparison:
http://xooyoozoo.github.io/yolo-octo-bugfixes/
But again, the main bottleneck with image compression is embedded software, like smartphone, cameras, etc. There is a compromise and cost/benefit between file size, transistor requirement, CPU cycles, power required, etc.
For example, I would be interested to see the size of binary code required to compress JPG, JPG XL, BGP, WEBP, etc.
Quality wise, BPG is essentially the same thing as HEIF because both base on HEVC. There are comparisons with HEIF in the slides linked on the JPEG XL homepage: https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLj...
n.b. HEVC is not royalty-free, while JPEG XL is.
Thanks for mentioning this, I was curious and I thought it would be getting more discussion here.
Been evaluating lossless alternatives to .PNG, the nice thing about .webp is that it is multi-threadable (hard to come by as far as lossless compression algorithms go), can JPEG-XL (lossless) say the same?
Yes, JPEG XL lossy and lossless formats both enable parallel and region of interest decoding by splitting the image into "groups"/tiles.
The parallel speedup for lossless mode depends on the speed setting.
The parallel speedup for lossless mode depends on the speed setting.
This is going to sound childish, but PIK (Google Pik) is literally “dick” in my language. I can’t help to chuckle at the notion of using PIK-images - literally dickpics.
I'm a native Dutch (of the Belgian variety) speaker and my proposal was called FUIF (which means "party" in Dutch, but it's also a backronym for Free Universal Image Format).
I am very happy the result of combining PIK and FUIF was not called PIKFUIF (or FUIFPIK). Some say JPEG XL is a bad name, but it could have been so much worse...
I am very happy the result of combining PIK and FUIF was not called PIKFUIF (or FUIFPIK). Some say JPEG XL is a bad name, but it could have been so much worse...
No matter the technical quality of a product such as jpeg XL, it is the adoption by browsers that will make it a concrete product ?
Both chrome and Firefox have it in their nightlies. Similarly to webp, as soon as they have it it will be usable with header sniffing quickly.
Facebook likes it too. And honestly that's a pretty big egg if browsers are the chicken. What are you looking for to recognize a "concrete" product?
An important niche to consider might be face recognition. For example the "US Open" image on medium JXL is significantly distorted in the face. As the face area is critical to the overall image quality perception, that area would benefit from reduced compression.
edit: This is also the case in other images with faces (and especially the eyes).
edit: This is also the case in other images with faces (and especially the eyes).
The only missing part is support in all browsers and operating systems.
This may be my memory playing tricks on me (after all, time perception changes as you get older), but if I think back to the speed of adoption of just about any image format that came after JPEG and GIF, then JPEG XL seems to be moving really fast by comparison.
EDIT: granted, computers being stuck on old versions of Internet Explorer back in the day and therefore holding back (for example) PNG adoption is a very different situation than that of the modern web, which makes it a bit of an unfair comparison.
EDIT: granted, computers being stuck on old versions of Internet Explorer back in the day and therefore holding back (for example) PNG adoption is a very different situation than that of the modern web, which makes it a bit of an unfair comparison.
i don't think your memory is playing tricks. from all these new formats, only PNG has really caught on yet. i don't think jpegxl will be adopted any faster.
Already in Chrome, Firefox, Edge: https://www.ghacks.net/2021/05/11/find-out-if-your-browser-s...
Yes but behind a Flag. With default settings, it hasn't landed in any browser yet: https://caniuse.com/jpegxl
I hope that Safari does not take as long to implement it as with WEBP...
I hope that Safari does not take as long to implement it as with WEBP...
I doubt it will be enabled by default until it reaches version 1.0, it is currently at 0.3 IIRC
This is only 1 browser with 3 distributors.
Firefox is a very different browser. Edge shares its base with Chrome, and that's derived from WebKit.
firefox is chrome distribution? that's new to me
discussed at https://news.ycombinator.com/item?id=27559748
[deleted]
Not directly relevant to the discussion, but I'm glad to see some (ex?) KU Leuven people involved in this.
I wonder how good the lossy quality and size is compared to JPEG Mini.
all of this was posted 6+ months ago via various urls jpeg.org, sneyers.info/jxl/ etc (with years of posts about the proposals etc)
what is new here?
what is new here?
A few cynical comments so far about this being one more standard to replace all the other standards a la the XKCD joke, but this is an effort that I have some faith in to actually deliver on that promise.
Lots of technical, practical and and political reasons why this could quickly replace a whole bunch of legacy formats in various roles that have been hanging around for a while for one obscure reason or another.
A faster, better-looking, and simpler web, yes please! Please support this so that it actually happens this time.
Lots of technical, practical and and political reasons why this could quickly replace a whole bunch of legacy formats in various roles that have been hanging around for a while for one obscure reason or another.
A faster, better-looking, and simpler web, yes please! Please support this so that it actually happens this time.
> this being one more standard to replace all the other standards a la the XKCD joke
Even if JPEG XL does not replace all other image formats, note that as the computing industry is growing, so is the number of use cases for image formats. There is no law that there has to be one format to rule them all, how inconvenient that may be.
E.g. some users might want to edit and encode extremely high resolution images on their embedded smartphones with weak processing power. They might not care if their images are 5% larger, they don't want their friends to wait for the encode to finish so that they can make another picture.
Other users might only encode an image once and then distribute it to millions of users. 5% improvement in bandwidth cost might be quite significant here. On the other hand, they have lots of and computational resources to throw at making the optimal image.
Can both use cases be served by the same format? Maybe. Maybe JPEG XL is that format. But these use cases came up as computers became embedded so you could carry them around, and as websites sprung up with billions of visitors. This is a development of the last 20 years.
Often the response to such developments is an increase in complexity: more formats, more tools, etc.
Even if JPEG XL does not replace all other image formats, note that as the computing industry is growing, so is the number of use cases for image formats. There is no law that there has to be one format to rule them all, how inconvenient that may be.
E.g. some users might want to edit and encode extremely high resolution images on their embedded smartphones with weak processing power. They might not care if their images are 5% larger, they don't want their friends to wait for the encode to finish so that they can make another picture.
Other users might only encode an image once and then distribute it to millions of users. 5% improvement in bandwidth cost might be quite significant here. On the other hand, they have lots of and computational resources to throw at making the optimal image.
Can both use cases be served by the same format? Maybe. Maybe JPEG XL is that format. But these use cases came up as computers became embedded so you could carry them around, and as websites sprung up with billions of visitors. This is a development of the last 20 years.
Often the response to such developments is an increase in complexity: more formats, more tools, etc.
baal80spam(3)
Not gonna fly, unless it's supported by PDF.
Leonard Rosenthol from Adobe and a key person in the PDF standardization has spoken out in favor of JPEG XL: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
It does seem likely that a future edition of PDF will include JPEG XL.
It does seem likely that a future edition of PDF will include JPEG XL.
JPEG XL is available (in beta/with a flag) in Chrome, Edge, and Firefox. Seems likely once it's no longer in beta that some web developers will start conditionally using it depending on the user's browser.
It doesn't need to be useful everywhere to be useful.
It doesn't need to be useful everywhere to be useful.
Not gonna fly, sorry. Come back to this comment in 5 years and you’ll see.
What is the Weissman score?
Oh look, another barely used image format alongside WebP, Animated PNG, AVIF, JPEG2000, and a bunch of others so obscure I forgot them.
It seems image formats have ossified. Nobody cares if the images are 50% smaller because storage and network are cheap enough not to deal with the hassle of using a non-standard image format.
It seems image formats have ossified. Nobody cares if the images are 50% smaller because storage and network are cheap enough not to deal with the hassle of using a non-standard image format.
If nobody would care, then how do you explain all the effort that went into MozJPEG, WebP, BPG, FLIF, HEIC, AVIF and JPEG XL?
Do you really think people are working on improved image compression just for fun, and not because "somebody actually cares"?
Also, it is not just about compression, it is also about functionality. HDR displays are a thing, images with alpha transparency are also a thing. There just is no way to properly do HDR and alpha without "dealing with the hassle of using a non-standard image format", unless you think 16-bit PNGs are a good idea for the web.
Do you really think people are working on improved image compression just for fun, and not because "somebody actually cares"?
Also, it is not just about compression, it is also about functionality. HDR displays are a thing, images with alpha transparency are also a thing. There just is no way to properly do HDR and alpha without "dealing with the hassle of using a non-standard image format", unless you think 16-bit PNGs are a good idea for the web.
Neat... But the only image on this page (the logo) is still a gif, an image format from 33 years ago, without any updates for 32 years.
Sure, if you don't need images, then that's fine and you obviously don't need a new codec. There is a significant chunk of the web though that does make significant use of images.
I would not call JPEG2000 being "barely used" - it is the standard format for all digital cinema movie packages.
Its also heavily used in the medical imaging field for radiographs etc
also for aerial photography images.
What is a digital cinema movie package?
To simplify its a tar with jpeg2000s as an image stream, plus audio and some metadata.
Its then (usually, but it is optional) encrypted to make sure that its hard to copy. The keys are sent directly to each projector to allow time limited, and or other limited use.
The reason why its used is because it optimized for quality, rather than size. It also allows custom colour spaces and other tweaks to maintain/enforce colour correctness/image quality.
Its then (usually, but it is optional) encrypted to make sure that its hard to copy. The keys are sent directly to each projector to allow time limited, and or other limited use.
The reason why its used is because it optimized for quality, rather than size. It also allows custom colour spaces and other tweaks to maintain/enforce colour correctness/image quality.
Cinemas don't use consumer grave video compression like h265, instead each frame is a jpeg 2000 image. It's heavy.
The data format used to send movies to cinemas.
So just halt innovation because a fraction of the internet's users have fast connection speeds?
> So just halt innovation because a fraction of the internet's users have fast connection speeds?
Inovation ? Will it make life easier for people ? No. You still need to update. Will the page load faster ? No page still has 30 Mb at 50 kbps. Lossless ? Same as PNG. Lossy - same as JPG. So what is the inovation ? That with 20 threads on an Epyc is very fast ? How about my 1ghz phone with 4 cores ?
Inovation ? Will it make life easier for people ? No. You still need to update. Will the page load faster ? No page still has 30 Mb at 50 kbps. Lossless ? Same as PNG. Lossy - same as JPG. So what is the inovation ? That with 20 threads on an Epyc is very fast ? How about my 1ghz phone with 4 cores ?
Lots of users in the world are still on 2G/3G and would greatly benefit from a faster image format.
> Lossless ? Same as PNG. Lossy - same as JPG.
This is incorrect, JPEG XL is smaller.
Also why do you put spaces before your question marks? It makes your post look rushed.
> Lossless ? Same as PNG. Lossy - same as JPG.
This is incorrect, JPEG XL is smaller.
Also why do you put spaces before your question marks? It makes your post look rushed.
Pages automatically defaulting to webp so you try to send the link through a messenger and you might notice that it doesn‘t work for everyone, either iOS users can‘t see it or the messenger interprets it strangely. So you try to save the image and send that, same problem, you get the webp image…