4 ms·

JPEG XL and AVIF have tradeoffs. AVIF works extremely well at compressing images down to very small sizes with minimal losses in quality but loses comparativel

JPEG XL and AVIF have tradeoffs. AVIF works extremely well at compressing images down to very small sizes with minimal losses in quality but loses comparatively to JPEG XL when it comes to compression at higher quality. Also I believe AVIF has an upper limit on canvas sizes (2^16 pixels by 2^16 pixels I think) where JEPGXL doesn't have that limitation. Also existing JPEGs can be losslessly migrated to JPEGXL which is preferable to a lossy conversion to AVIF. So it's preferable to have JPEG XL, webP, and AVIF. - webP fills the PNG role while providing better lossless compression - AVIF fills the JPEG role for most of your standard web content. - JPEG XL migrates old JPEG content to get most of the benefits of JPEG XL or AVIF without lossy conversion. - JPEG XL fills your very-high fidelity image role (currently filled by very large JPEGs or uncompressed TIFFs) while providing very good lossless and lossy compression options.

wongarsu 3y ago
AVIF is even more limited in resolution than that, just 8.9 megapixels in baseline profile or 35 megapixels in the advanced profile. If you have image-heavy workflows and care about storage and/or bandwidth then JPEG-XL pairs great with AVIF: JPEG-XL is great for originals and detail views due to its great performance at high quality settings and high resolution support, meanwhile AVIF excels at thumbnails where resolution doesn't matter and you need good performance at low quality settings.
prox 3y ago
Memory is hazy but doesn’t JXL have better colors or color profile support?
- vanderZwan 3y ago
  You can scroll down (on mobile) to see an overview image comparing technical features on https://jpegxl.info/ https://jpegxl.info/. It doesn't mention color profiles (although I presume that just means they're all equal there), but jxl does support higher max bit depth per channel (32 vs 10 for AVIF) and more channels (4099 vs 10). So for raw sensor data, and intermediate formats for image processing, where information loss should be avoided, it should be a lot better. I'm hoping it gets adopted as a better underlying technology for various RAW formats, and hopefully a better successor to the DNG format while we're at it (currently these are TIFF based). I'm not even a professional photographer, and my hard drive is still mostly occupied by RAW files.
  - prox 3y ago
    Yeah, the points you mention are what I remember what photographers really dig about JXL. Also higher bit depth is a big deal for some pro photographers.
    - vanderZwan 3y ago
      I actually studied photography (technically contemporary art, but photography was my main medium) but chose to not pursue a career in it. You are correct, bit depth matters. It is unlikely 32 bits will ever be needed for RAW files though. Specifically, it matters for source files and intermediate files. With RAW files from the camera, the higher the bit depth of the analog-to-digital conversion (ADC) step, the less posterization this introduces on the signal. Theoretically at least, you're still limited by the sensor's dynamic range, and there are other subtleties involved, like light perception being logarithmic instead of linear, but RAW encodings being linear[0][1]. But in simple terms: paired with a sensor with high dynamic range and good ADC, a higher bit depth results in less noise and higher dynamic range. Which allows one to recover more fine detail from shadows and highlights. Which makes the camera more forgiving in normally difficult lighting scenes (low light and/or high contrast). So a higher bit depth can aid in giving photographers creative freedom when shooting, and more flexibility in editing their photos without loss of fidelity. So yes, it is an important cog in the machine that is the whole processing pipeline. Having said that, as I mentioned our eyes perceive light logarithmically. The dynamic range of the human eye is... complicated to determine, because it adjusts so quickly. At night it may go up to 20 stops, during the day 14 stops is likely to be the typical range[2]. So it's probably not a coincidence that digital cameras have "stalled" at using 14 bits for their RAW files, typically: the photographer likely wouldn't be able to see more contrast in the lights and shadows before taking a photo anyway! [0] https://www.dpreview.com/articles/4653441881/bit-depth-is-about-dynamic-range-not-the-number-of-colors-you-get-to-capture https://www.dpreview.com/articles/4653441881/bit-depth-is-ab... [1] No I don't understand why floating point ADCs aren't used either, seems like it would be a more sensible approach to me and they do exist: https://ieeexplore.ieee.org/abstract/document/776106 https://ieeexplore.ieee.org/abstract/document/776106 [2] https://clarkvision.com/imagedetail/eye-resolution.html https://clarkvision.com/imagedetail/eye-resolution.html
pmarreck 3y ago
Possibly an underrated but potentially very useful unique feature of JXL is that it completely eliminates the need to use a third party thumbnail/image-scaling rendering site or workflow. If you need a full size JXL image rendered down to 25% size for one of your web views, you literally just truncate the bitstream at 1/4 the total (or whatever percentage of the total number of pixels of the full-size image you need, that's a trivial math calculation) and send just that. That's tremendously simpler, both from an architectural and maintenance standpoint (for any site that deals with images), than what you would usually have to do, such as relying on either a third party host (and added cost, latency (without caching), and potential downtime/outage) or pushing it through the (very terrible and memory/cpu-wasteful codebase at this point) ImageMagick/GraphicsMagick library (and potentially managing that conversion as a background job which incurs additional maintenance overhead), or getting VIPS to actually successfully build in your CI/CD workflow (an issue I struggled with in the past while trying to get away from "ImageTragick"). You get to chuck ALL of that and simply hold onto the originals in your choice of stateful store (S3, DB, etc.), possibly caching it locally to the webserver, and just... compute the number of pixels you need given the requested dimensions (which is basically just: ((requested x)*(requested y))/((full-size x)*(full-size y)) percentage of the total binary size, capping at 100%), and bam, truncate. Having built out multiple image-scaling (and caching, and sometimes third-party-hosted) workflows at this point, this is a very attractive feature, speaking as a developer.
- adzm 3y ago
  This is fascinating, I had never heard of this aspect of JXL.
- deleted 3y ago
  [deleted]
- magicalist 3y ago
  That's just progressive decoding, though, and is only possible if you encoded the image correctly (which is optional). You can also do similar things with progressive jpeg, png, and webp, with jpeg being the most flexible. The unique part AFAIK is that you can order the data blocks however you want, allowing progressive loading that prioritizes more important or higher detailed areas: https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html https://opensource.googleblog.com/2021/09/using-saliency-in-... (your thumbnails may or may not look terrible this way, as well. really better suited for progressive loading)
quikoa 3y ago
JPEG XL Lossless: about 35% smaller than PNG (50% smaller for HDR). Source: https://jpegxl.info/ https://jpegxl.info/ So with JPEG XL WebP may not serve any real purpose anymore.
worrycue 3y ago
Or JPEG XL can takeover all of it. - JPEG XL can do lossless compression better than PNG if I’m right. - At low bit rates, JPEG XL isn’t that far from AVIF quality. You will only use it for less important stuff like “decorations” and previews anyway so we can be less picky about the quality. - For the main content, you will want high bit rates which is where JPEG XL excels. - Legacy JPEG can be converted to JPEG XL for space savings at no quality loss.
- ksec 3y ago
  Thank You both. Couldn't have said it better. The use cases of WebP is limited, the actual advantage over decent JPEG and isn't that big, and unless you use a lot of lossless PNG I would argue it should have never been pushed as the replacement of JPEG. To this day I still dont know why people are happy about WebP. According to Google Chrome, 80% of images transferred has an BPP 1.0 or above. The so called "low bit rate" happens at below BPP 0.5. The current JPEG XL is still no optimised for low bitrate. And judging from the author's tweet I dont think they intend to do it any time soon. And I can understand why.

wongarsu 3y ago

AVIF is even more limited in resolution than that, just 8.9 megapixels in baseline profile or 35 megapixels in the advanced profile. If you have image-heavy workflows and care about storage and/or bandwidth then JPEG-XL pairs great with AVIF: JPEG-XL is great for originals and detail views due to its great performance at high quality settings and high resolution support, meanwhile AVIF excels at thumbnails where resolution doesn't matter and you need good performance at low quality settings.

prox 3y ago

Memory is hazy but doesn’t JXL have better colors or color profile support?

vanderZwan 3y ago
You can scroll down (on mobile) to see an overview image comparing technical features on https://jpegxl.info/ https://jpegxl.info/. It doesn't mention color profiles (although I presume that just means they're all equal there), but jxl does support higher max bit depth per channel (32 vs 10 for AVIF) and more channels (4099 vs 10). So for raw sensor data, and intermediate formats for image processing, where information loss should be avoided, it should be a lot better. I'm hoping it gets adopted as a better underlying technology for various RAW formats, and hopefully a better successor to the DNG format while we're at it (currently these are TIFF based). I'm not even a professional photographer, and my hard drive is still mostly occupied by RAW files.
- prox 3y ago
  Yeah, the points you mention are what I remember what photographers really dig about JXL. Also higher bit depth is a big deal for some pro photographers.
  - vanderZwan 3y ago
    I actually studied photography (technically contemporary art, but photography was my main medium) but chose to not pursue a career in it. You are correct, bit depth matters. It is unlikely 32 bits will ever be needed for RAW files though. Specifically, it matters for source files and intermediate files. With RAW files from the camera, the higher the bit depth of the analog-to-digital conversion (ADC) step, the less posterization this introduces on the signal. Theoretically at least, you're still limited by the sensor's dynamic range, and there are other subtleties involved, like light perception being logarithmic instead of linear, but RAW encodings being linear[0][1]. But in simple terms: paired with a sensor with high dynamic range and good ADC, a higher bit depth results in less noise and higher dynamic range. Which allows one to recover more fine detail from shadows and highlights. Which makes the camera more forgiving in normally difficult lighting scenes (low light and/or high contrast). So a higher bit depth can aid in giving photographers creative freedom when shooting, and more flexibility in editing their photos without loss of fidelity. So yes, it is an important cog in the machine that is the whole processing pipeline. Having said that, as I mentioned our eyes perceive light logarithmically. The dynamic range of the human eye is... complicated to determine, because it adjusts so quickly. At night it may go up to 20 stops, during the day 14 stops is likely to be the typical range[2]. So it's probably not a coincidence that digital cameras have "stalled" at using 14 bits for their RAW files, typically: the photographer likely wouldn't be able to see more contrast in the lights and shadows before taking a photo anyway! [0] https://www.dpreview.com/articles/4653441881/bit-depth-is-about-dynamic-range-not-the-number-of-colors-you-get-to-capture https://www.dpreview.com/articles/4653441881/bit-depth-is-ab... [1] No I don't understand why floating point ADCs aren't used either, seems like it would be a more sensible approach to me and they do exist: https://ieeexplore.ieee.org/abstract/document/776106 https://ieeexplore.ieee.org/abstract/document/776106 [2] https://clarkvision.com/imagedetail/eye-resolution.html https://clarkvision.com/imagedetail/eye-resolution.html

pmarreck 3y ago

Possibly an underrated but potentially very useful unique feature of JXL is that it completely eliminates the need to use a third party thumbnail/image-scaling rendering site or workflow. If you need a full size JXL image rendered down to 25% size for one of your web views, you literally just truncate the bitstream at 1/4 the total (or whatever percentage of the total number of pixels of the full-size image you need, that's a trivial math calculation) and send just that. That's tremendously simpler, both from an architectural and maintenance standpoint (for any site that deals with images), than what you would usually have to do, such as relying on either a third party host (and added cost, latency (without caching), and potential downtime/outage) or pushing it through the (very terrible and memory/cpu-wasteful codebase at this point) ImageMagick/GraphicsMagick library (and potentially managing that conversion as a background job which incurs additional maintenance overhead), or getting VIPS to actually successfully build in your CI/CD workflow (an issue I struggled with in the past while trying to get away from "ImageTragick"). You get to chuck ALL of that and simply hold onto the originals in your choice of stateful store (S3, DB, etc.), possibly caching it locally to the webserver, and just... compute the number of pixels you need given the requested dimensions (which is basically just: ((requested x)*(requested y))/((full-size x)*(full-size y)) percentage of the total binary size, capping at 100%), and bam, truncate. Having built out multiple image-scaling (and caching, and sometimes third-party-hosted) workflows at this point, this is a very attractive feature, speaking as a developer.

adzm 3y ago
This is fascinating, I had never heard of this aspect of JXL.
deleted 3y ago
[deleted]
magicalist 3y ago
That's just progressive decoding, though, and is only possible if you encoded the image correctly (which is optional). You can also do similar things with progressive jpeg, png, and webp, with jpeg being the most flexible. The unique part AFAIK is that you can order the data blocks however you want, allowing progressive loading that prioritizes more important or higher detailed areas: https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html https://opensource.googleblog.com/2021/09/using-saliency-in-... (your thumbnails may or may not look terrible this way, as well. really better suited for progressive loading)

quikoa 3y ago

JPEG XL Lossless: about 35% smaller than PNG (50% smaller for HDR). Source: https://jpegxl.info/ https://jpegxl.info/ So with JPEG XL WebP may not serve any real purpose anymore.

worrycue 3y ago

Or JPEG XL can takeover all of it. - JPEG XL can do lossless compression better than PNG if I’m right. - At low bit rates, JPEG XL isn’t that far from AVIF quality. You will only use it for less important stuff like “decorations” and previews anyway so we can be less picky about the quality. - For the main content, you will want high bit rates which is where JPEG XL excels. - Legacy JPEG can be converted to JPEG XL for space savings at no quality loss.

ksec 3y ago
Thank You both. Couldn't have said it better. The use cases of WebP is limited, the actual advantage over decent JPEG and isn't that big, and unless you use a lot of lossless PNG I would argue it should have never been pushed as the replacement of JPEG. To this day I still dont know why people are happy about WebP. According to Google Chrome, 80% of images transferred has an BPP 1.0 or above. The so called "low bit rate" happens at below BPP 0.5. The current JPEG XL is still no optimised for low bitrate. And judging from the author's tweet I dont think they intend to do it any time soon. And I can understand why.