14 ms·

What’s the best lossless image format?

215 points by pmoriarty 4y ago

theandrewbailey 4y ago
(2021) I wonder how AVIF and JPEG XL would stack up today.
- torquemodwanted 4y ago
  There's been discussion lately whether or not JPEG XL adoption will be hindered by patents. https://patents.google.com/patent/US11234023B2/ https://patents.google.com/patent/US11234023B2/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/
- JyrkiAlakuijala 4y ago
  Lossless was not a focus point for AVIF. There JPEG XL wins hands down, with something like 50 % difference. Also, AVIF can only do up to 12 bit lossless, whereas photography workflows benefit from 14+ bits. On lossy JPEG XL wins by 17%: https://twitter.com/jonsneyers/status/1532771586381688833 https://twitter.com/jonsneyers/status/1532771586381688833 "Overall for lossy, for the same visual quality, JPEG XL is ~17% smaller than AVIF, which is ~17% smaller than WebP, which is ~17% smaller than JPEG."
soperj 4y ago
SVG!
- micromacrofoot 4y ago
  All graphics are images, but not all images are graphics
  - cute_boi 4y ago
    Technically ..., but practically you are correct.
  - mdp2021 4y ago
    In my days we would have said, not all images are vector based - some are raster based.
ptidhomme 4y ago
I think decompression times would be a relevant criteria, but they're surprisingly not there...
- petesergeant 4y ago
  Quite, and encoding speed, which is included, seems almost irrelevant
  - pmoriarty 4y ago
    Why is encoding speed irrelevant? I'm currently in the process of scanning and archiving lots of photographs as high-resolution 16-bit PNG's and encoding speed is definitely a significant influence on how long this process takes.
    - somishere 4y ago
      Can I ask why you chose PNG for your archive format?
      - pmoriarty 4y ago
        It's lossless, offers compression, works with 16-bit images, and is well supported in a lot of software on all sorts of platforms.
        somishere 4y ago
        Interesting, thanks. I'd heard of PNG being used for this before and thought people had lost the plot. For context I started a neg scanning project a few years ago, ~150 rolls on an epson v850 (flatbed), and stuck with the default compressed tif after some surface research. There is little chance I would consider another processing step .. unless it was batched on a server somewhere! Very painstaking process, which has been on indefinite hold for a small while now (waiting for the AI to catch up).
    - drblast 4y ago
pizza 4y ago
There is also a new experimental Fast Lossless mode in JPEG XL as well, but it was developed after this post was written https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless https://github.com/libjxl/libjxl/tree/main/experimental/fast...
- fooqux 4y ago
  > but it was developed after this post was written The article literally compares it to others. It might not have been finalized at the time of writing, but it's not like the author was unaware of it.
  - re 4y ago
    I think you misunderstand pizza; the article compares JPEG XL, but it doesn't compare the new lossless coder implementation (fjxl/fast_lossless), which is a separate tool/binary from cjxl.
mg 4y ago
I would love to see an estimation of how small real world images would get if we could calculate their Kolmogorov complexity. Aka if we could find the shortest program that produces the image as output. Some images obviously would become very small. For example an image that is all blue, a spiral, the flag of the United States, the Mandelbrot set ... But what about the average portrait for example?
- 4pkjai 4y ago
  Yes I’ve often thought of this too. Also a lot of images are screenshots of text or UIs.
- SR2Z 4y ago
  You cannot calculate Kolmogorov complexity in all cases because that would involve solving the halting problem. It is worth pointing out that certain formats like AVIF do sort of do this: they use a few different algorithms, see which combination of algo/block split removes the most entropy, and then compress _that_. In practice, this is pretty good for most non-noisy images.
  - l33t2328 4y ago
    Wouldn’t you want entropy to increase when you compress?
    - hinkley 4y ago
      Entropy can be considered on a per-byte or per message basis, and it seems that people who are talking about data at rest (compressed pictures, archives, etc) almost always talk about the per-message numbers. I don't think I've ever seen Kolmogorov complexity applied to a bitstream. It's always been per message. In which case entropy is exactly conserved, unless the encoding is lossy.
      - raxxorraxor 4y ago
        The term is a mess in computer science. The standalone definition almost works reverse to the definition in thermodynamics. There is also entropy coding, which is a compression through a set of prefixes and entropy compression which is about the termination of processes. I am sure there are many more... Most practical approach is to read the meaning through the respective context and sometimes to ignore the sign... That said, I believe the parent is correct. Compressed data certainly has a higher entropy. But any additional bit from an image or sound is rarely independent in the first place like Shannon demanded it to be the case for the definition of entropy. That they are not independent is precisely the attack vector of many forms of compression. For example the base frequency of a JPG has more entropy if we use the literal definition than higher frequencies that get removed because they lack entropy in a information technical sense.
atoav 4y ago
> What is the best lossless image format? For which application? Otherwise you can only say "depends". Tiff is good if you want to save data fast to disk in Blender. EXR is great if you want 32bit color depth, etc.
- re 4y ago
  > For which application? For this article the context is for use in browsers, and the main metric being measured is compression ratio.
- chungy 4y ago
  > Tiff is good Mind that TIFF is only a container format that can contain any arbitrary codec you like; it can be uncompressed pixels, RLE compressed, it can be a PNG, a JPEG XL, even lossy JPEG or WebP if you'd like. Saying your image format is TIFF is roughly as useful and conveys as much information as saying your video format is MKV.
  - Melatonic 4y ago
    Usually with TIFF people mean uncompressed.
  - ramraj07 4y ago
    In that regard lzw has been the standard lossless tiff compression format I’ve seen.
  - atoav 4y ago
    Good point. What I wanted to say is, that what is "the best" depends a lot on the application. Maybe you don't care about compression/size, but about write speed. Maybe read speed is something you care about, maybe you do actually care about size, but compatibility with certain clients is even more important, maybe you care a lot about how long decompression takes, how much strain it puts on the CPU or the memory, etc. So it is certainly not as simple as just going for the thing that produces the smallest file in some benchmark that may or may not fit your realworld data.
heipei 4y ago
If your dataset allows it, I would look at pngquant for "lossy" compression of PNG images by means of color quantization: https://pngquant.org/ https://pngquant.org/ This works absolute wonders if you are talking about images with a limited amount of colors and without many gradients. I use it to compress screenshots of websites, which, if you think about it, are mostly large blobs of uniform colors with hard edges. I also use it every time I want to include a screenshot from my desktop in some publication or email. The savings in filesize are too good to be true without any apparent loss of visual fidelity.
- mgdlbp 4y ago
  Still hoping for vector desktop screenshots, now that modern GUIs are all vector-based.* 11 years on, gtk-vector-screenshot still stands alone, though we do now have a handful tools for rendering webpages to SVGs. *Add this to Category:Articles_with_obsolete_information: https://en.wikipedia.org/wiki/Vector-based_graphical_user_interface https://en.wikipedia.org/wiki/Vector-based_graphical_user_in...
  - mkl 4y ago
    MacOSX has that for a while, years ago. Mostly I think it was misleading and aimed at print magazines.
emeril 4y ago
For web graphics, isn't a mix of PNG/JPEG good enough generally speaking? I'd imagine the benefits of changing to something more modern/efficient aren't worth the cost/time involved other than in esoteric situations given that most end users have high bandwidth connections and bandwidth costs typically aren't too significant?
- pineconewarrior 4y ago
  webp, webp2, and avif are absolutely worth using in modern web scenarios. It's even considered "poor practice" to serve legacy formats now.
  - alx__ 4y ago
    I wouldn't say it's "poor practice" to serve legacy formats. If you're using a setup to allow for fallbacks, that's the best practice. There are more device types some developers need to consider than the latest version of Chrome.
    - pineconewarrior 4y ago
      That's why I put it in the quotes. Google will flag you for core web vitals issues if you're serving jpegs and pngs all over the place. Many CDNs automatically serve the best format compatible with the useragent these days! Also... the bit about the latest version of Chrome is pretty far off. WebP has been usable for 90+% (for my use cases, 99%) of the web for a LONG time. The only thing holding us back was safari 14.0 which is now not on my list of targets!
- cpncrunch 4y ago
  You might want to check your pagespeed insights to verify that. I noticed that our pagespeed score was very poor (due to google using new methods to calculate those scores). Adding webp versions of images reduced the size of those images significantly, and brought our pagespeed scores back to more reasonable values in google's eyes.
  - 4y ago
lajamerr 4y ago
JPEG XL is the standard to beat them all. Like how Opus became the definitive codec for lossy compression for the web. JPEG XL covers nearly every use case for images, even replacing GIFs with it's animation support. Existing JPEGs can also be re-encoded losslessly into JPEG XL format/data structure and get significant file size savings. This backwards compatiability is very important in transitioning to web to JPEG XL seamlessly. What I'm most excited about for JPEG XL is progressive decoding, I had been following the FLIF project for a while and was disappointed with it's lack of adoption. But it's future found itself in JPEG XL. Without a doubt 5 years now JPEG XL will become like Opus and set the standard for next generation image formats.
- mgraczyk 4y ago
  I used to think this, but I've lost confidence over the last year. I literally work on the software that generates jpg files on Googles Pixel phones, and there seems to be no realistic path to JPEG XL adoption within the next 5 years.
  - jl6 4y ago
    Why not? What’s stopping the next Pixel phone producing JPEG XL images the same way the iPhone switched to HEIC images a few years back?
    - mgraczyk 4y ago
      To first approximation, nothing. And it's possible that we will at some point in the near future. The problem is consuming it. You won't be able to view the photo on device until Android adds it, or until the gallery and camera apps add custom software decoders. You won't be able to share with anybody until Facebook/Whatsapp/etc add support. you won't be able to view online until the browsers add support....
- ComputerGuru 4y ago
  I’ve read up about JPEG XL in the past but a question just occurred to me: is it just an image format or is it also a document format? Can it replace TIFF as a container for multi-page documents/images?
rektide 4y ago
I wonder how fpng[1] would compare- a lossless speed optimized png compressor. Oh! The author Rich screenshoted[2] a really nice deck[3] that also boasts fpnge[4] and fjxl[5], both of which are even faster, both use AVX2 (or neon for FJXL). Notably fjxl is in the reference libjxl tree. I'm not sure what if any constraints fast mode has, what it takes to use. The article uses cjxl, which does not run the fjxl fast mode, and further, fast mode was added after this article was written[6]. Other notes on jpeg-xl: it has progressive rendering. It has hdr! The deck on FJXL & FPNGE is epic. Thanks Quote Ok Image (QOI) format for setting the fire on this all!! [1] https://github.com/richgel999/fpng https://github.com/richgel999/fpng [2] https://twitter.com/richgel999/status/1485976101692358656 https://twitter.com/richgel999/status/1485976101692358656 [3] https://www.lucaversari.it/FJXL_and_FPNGE.pdf https://www.lucaversari.it/FJXL_and_FPNGE.pdf [4] https://github.com/veluca93/fpnge https://github.com/veluca93/fpnge [5] https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless https://github.com/libjxl/libjxl/tree/main/experimental/fast... [6] https://github.com/libjxl/libjxl/pull/1124 https://github.com/libjxl/libjxl/pull/1124
planetsprite 4y ago
JPEG 2000
bumper_crop 4y ago
The best lossless format is the one you can decode back to the original image. When evaluating them, there is an implicit assumption that the decode step will happen a short time later, but that's not always true. Will there be JPEG XL decoders commonly available in 40 years? Will the code even compile then? As a thought experiment, try to find the lossless encodings from 40 years ago and see if they can be faithfully reproduced. (or even 20 years ago, remember JPEG2000?) Framing best in terms of file size or encoding speed is a really use-specific framing, and not ideal for preservation.
- bragr 4y ago
  This seems excessively handwringing about code rot. TIFF was introduced 35 years ago and still well supported. JPEG2000 didn't become super widespread, but is still used in many places. Smart passports encode your passport photo in JPEG2000 for example.
  - accrual 4y ago
    Another example is in radiology. Many thousands of medical images are created and stored in lossless JPEG2000 every day with entire ecosystems of software to store and move them.
    - ollifi 4y ago
      Also in digital cinemas films are JPEG2000 sequences.
      - imagetic 4y ago
        Huh?
        mkl 4y ago
        Exactly what they said. Movies in cinemas with digital projectors are distributed as sequences of JPEG 2000 images: https://en.wikipedia.org/wiki/Digital_Cinema_Package https://en.wikipedia.org/wiki/Digital_Cinema_Package
pm2222 4y ago
https://bellard.org/bpg/ https://bellard.org/bpg/ Not sure if this fits your bill.
Melatonic 4y ago
If you want something that is going to be around for awhile and has a LOT of features you probably do not need then you are going to want to go probably with a .DPX or .EXR which are the standard for the VFX industry as well as film in general. On the consumer side I guess adobe .DNG might not be bad either or for maximum compatibility but then maybe a Tiff. For video I personally like Cineform but both ProRes and DNxHD are more widely used EXR will get you full 32 bit float if needed
- detuur 4y ago
  How do EXR and JXL compare to each other, feature-wise?
  - Melatonic 4y ago
    I have never used JXL honestly - no job I have had it was ever even considered. Given the Jpeg in the name I doubt any pro studio would consider it given the other options do everything needed. DPX is basically the older standard for film and EXR is the newer one. edit: Just looked at the specs and JpegXL is definitely marketed at least more as a web end viewing file type. It does higher color depths (up to 16 bit) which is pretty good but will not do 32 bit like EXR. Given that EXR is so widely used I would likely not consider anything else.
    - lifthrasiir 4y ago
      JPEG XL definitely supports 32-bit float samples, but cjxl is currently unable to read a 32-bit EXR [1] (compare with PFM [2] which is fully supported). [1] https://github.com/libjxl/libjxl/issues/465 https://github.com/libjxl/libjxl/issues/465 [2] http://www.pauldebevec.com/Research/HDR/PFM/ http://www.pauldebevec.com/Research/HDR/PFM/
      - Melatonic 4y ago
        Got it. Well that is good at least. Realistically I can see JPEGXL becoming a good DELIVERY format but I highly doubt any industries will be swapping to it for production use (or archiving) given there are very widely adopted formats and standards already that can do the same thing. I'm almost tempted to say that trying to make ONE format that is meant for both (delivery and production or archiving which are inherently opposites in terms of requirements) is a bad idea just from a marketing and ease of use standpoint. Sometimes its nice to have two clearly separate technologies meant specifically for their purpose.
aaaaaaaaaaab 4y ago
I want to see if they’re really lossless. I know for a fact that PNG is. But last I checked HEIF didn’t support lossless RGB images, only lossless YUV… So HEIF was unusable for bit-perfect reproduction of the original.
huachimingo 4y ago
PNG vs JPG on a nutshell: https://i.stack.imgur.com/qJoKW.png https://i.stack.imgur.com/qJoKW.png
bobbylarrybobby 4y ago
I guess this would be a good time to plug a small project I worked on: https://github.com/rben01/collagen https://github.com/rben01/collagen . I got tired of seeing how crappy text looked when placed on a JPEG (due to the compression artifacts) and how large some PNGs were because they had a small JPEG-like area, so I made a little CLI program that solves that problem. Rather than settle on any particular image format, it allows the user to provide a collection of inputs -- images (in any format your browser supports), SVGs, shapes, text -- and bundles them into a single SVG file (it base64 encodes the images). So if you want to scale a PNG and place it on top of a JPG, you... just do that, with SVG transforms and whatnot. It produces a single file and is a lot easier than writing out the SVG yourself, and is nearly as easy as opening up a tailor-made mage editor and doing it there. And it's really, truly lossless, as it doesn't touch any of the input data. In theory, you wouldn't even transmit the SVG directly; you'd zip up the components and send them across the network and then encode them into an SVG on the other end, which would mitigate some of the size increase due to base64 encoding.
travisgriggs 4y ago
I was kinda sad QOI (https://github.com/phoboslab/qoi https://github.com/phoboslab/qoi) wasn’t included in the comparisons.
- lifthrasiir 4y ago
  QOI is kinda overrated, especially given the existence of fpng(e) and fjxl which operate within the limitation of existing formats and generally outperform QOI. QOI is a great demonstration that better prediction can make up for less efficient coding, but not much beyond that.
zuzulo 4y ago
Very good article
_448 4y ago
What, no one mentioned MNG[0] yet? :) [0] http://www.libpng.org/pub/mng/spec http://www.libpng.org/pub/mng/spec
raxxorraxor 4y ago
For raw data it would be Bitmap as it provides easy access. As a more obvious answer I would still go with png and webp since it is most widely supported.
F-app 4y ago
High quality? Less size? Most importantly, Microsoft and Apple don't like the new image format. They are founding members of AOM, but they reject AVIF. Most browsers using Blink engines, including Chrome, support avif, but not Edge. Safari? Of course not. Safari is Apple's version of Internet Explorer. The fact that Apple devices cannot use webp efficiently is why many webmasters and service managers still do not adopt webp.

215 points by pmoriarty 4y ago

theandrewbailey 4y ago

(2021) I wonder how AVIF and JPEG XL would stack up today.

torquemodwanted 4y ago
There's been discussion lately whether or not JPEG XL adoption will be hindered by patents. https://patents.google.com/patent/US11234023B2/ https://patents.google.com/patent/US11234023B2/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/
JyrkiAlakuijala 4y ago
Lossless was not a focus point for AVIF. There JPEG XL wins hands down, with something like 50 % difference. Also, AVIF can only do up to 12 bit lossless, whereas photography workflows benefit from 14+ bits. On lossy JPEG XL wins by 17%: https://twitter.com/jonsneyers/status/1532771586381688833 https://twitter.com/jonsneyers/status/1532771586381688833 "Overall for lossy, for the same visual quality, JPEG XL is ~17% smaller than AVIF, which is ~17% smaller than WebP, which is ~17% smaller than JPEG."

soperj 4y ago

SVG!

micromacrofoot 4y ago
All graphics are images, but not all images are graphics
- cute_boi 4y ago
  Technically ..., but practically you are correct.
- mdp2021 4y ago
  In my days we would have said, not all images are vector based - some are raster based.

ptidhomme 4y ago

I think decompression times would be a relevant criteria, but they're surprisingly not there...

petesergeant 4y ago
Quite, and encoding speed, which is included, seems almost irrelevant
- pmoriarty 4y ago
  Why is encoding speed irrelevant? I'm currently in the process of scanning and archiving lots of photographs as high-resolution 16-bit PNG's and encoding speed is definitely a significant influence on how long this process takes.
  - somishere 4y ago
    Can I ask why you chose PNG for your archive format?
    - pmoriarty 4y ago
      It's lossless, offers compression, works with 16-bit images, and is well supported in a lot of software on all sorts of platforms.
      - somishere 4y ago
        Interesting, thanks. I'd heard of PNG being used for this before and thought people had lost the plot. For context I started a neg scanning project a few years ago, ~150 rolls on an epson v850 (flatbed), and stuck with the default compressed tif after some surface research. There is little chance I would consider another processing step .. unless it was batched on a server somewhere! Very painstaking process, which has been on indefinite hold for a small while now (waiting for the AI to catch up).
  - drblast 4y ago

pizza 4y ago

There is also a new experimental Fast Lossless mode in JPEG XL as well, but it was developed after this post was written https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless https://github.com/libjxl/libjxl/tree/main/experimental/fast...

fooqux 4y ago
> but it was developed after this post was written The article literally compares it to others. It might not have been finalized at the time of writing, but it's not like the author was unaware of it.
- re 4y ago
  I think you misunderstand pizza; the article compares JPEG XL, but it doesn't compare the new lossless coder implementation (fjxl/fast_lossless), which is a separate tool/binary from cjxl.

mg 4y ago

I would love to see an estimation of how small real world images would get if we could calculate their Kolmogorov complexity. Aka if we could find the shortest program that produces the image as output. Some images obviously would become very small. For example an image that is all blue, a spiral, the flag of the United States, the Mandelbrot set ... But what about the average portrait for example?

4pkjai 4y ago
Yes I’ve often thought of this too. Also a lot of images are screenshots of text or UIs.
SR2Z 4y ago
You cannot calculate Kolmogorov complexity in all cases because that would involve solving the halting problem. It is worth pointing out that certain formats like AVIF do sort of do this: they use a few different algorithms, see which combination of algo/block split removes the most entropy, and then compress _that_. In practice, this is pretty good for most non-noisy images.
- l33t2328 4y ago
  Wouldn’t you want entropy to increase when you compress?
  - hinkley 4y ago
    Entropy can be considered on a per-byte or per message basis, and it seems that people who are talking about data at rest (compressed pictures, archives, etc) almost always talk about the per-message numbers. I don't think I've ever seen Kolmogorov complexity applied to a bitstream. It's always been per message. In which case entropy is exactly conserved, unless the encoding is lossy.
    - raxxorraxor 4y ago
      The term is a mess in computer science. The standalone definition almost works reverse to the definition in thermodynamics. There is also entropy coding, which is a compression through a set of prefixes and entropy compression which is about the termination of processes. I am sure there are many more... Most practical approach is to read the meaning through the respective context and sometimes to ignore the sign... That said, I believe the parent is correct. Compressed data certainly has a higher entropy. But any additional bit from an image or sound is rarely independent in the first place like Shannon demanded it to be the case for the definition of entropy. That they are not independent is precisely the attack vector of many forms of compression. For example the base frequency of a JPG has more entropy if we use the literal definition than higher frequencies that get removed because they lack entropy in a information technical sense.

atoav 4y ago

> What is the best lossless image format? For which application? Otherwise you can only say "depends". Tiff is good if you want to save data fast to disk in Blender. EXR is great if you want 32bit color depth, etc.

re 4y ago
> For which application? For this article the context is for use in browsers, and the main metric being measured is compression ratio.
chungy 4y ago
> Tiff is good Mind that TIFF is only a container format that can contain any arbitrary codec you like; it can be uncompressed pixels, RLE compressed, it can be a PNG, a JPEG XL, even lossy JPEG or WebP if you'd like. Saying your image format is TIFF is roughly as useful and conveys as much information as saying your video format is MKV.
- Melatonic 4y ago
  Usually with TIFF people mean uncompressed.
- ramraj07 4y ago
  In that regard lzw has been the standard lossless tiff compression format I’ve seen.
- atoav 4y ago
  Good point. What I wanted to say is, that what is "the best" depends a lot on the application. Maybe you don't care about compression/size, but about write speed. Maybe read speed is something you care about, maybe you do actually care about size, but compatibility with certain clients is even more important, maybe you care a lot about how long decompression takes, how much strain it puts on the CPU or the memory, etc. So it is certainly not as simple as just going for the thing that produces the smallest file in some benchmark that may or may not fit your realworld data.

heipei 4y ago

If your dataset allows it, I would look at pngquant for "lossy" compression of PNG images by means of color quantization: https://pngquant.org/ https://pngquant.org/ This works absolute wonders if you are talking about images with a limited amount of colors and without many gradients. I use it to compress screenshots of websites, which, if you think about it, are mostly large blobs of uniform colors with hard edges. I also use it every time I want to include a screenshot from my desktop in some publication or email. The savings in filesize are too good to be true without any apparent loss of visual fidelity.

mgdlbp 4y ago
Still hoping for vector desktop screenshots, now that modern GUIs are all vector-based.* 11 years on, gtk-vector-screenshot still stands alone, though we do now have a handful tools for rendering webpages to SVGs. *Add this to Category:Articles_with_obsolete_information: https://en.wikipedia.org/wiki/Vector-based_graphical_user_interface https://en.wikipedia.org/wiki/Vector-based_graphical_user_in...
- mkl 4y ago
  MacOSX has that for a while, years ago. Mostly I think it was misleading and aimed at print magazines.

emeril 4y ago

For web graphics, isn't a mix of PNG/JPEG good enough generally speaking? I'd imagine the benefits of changing to something more modern/efficient aren't worth the cost/time involved other than in esoteric situations given that most end users have high bandwidth connections and bandwidth costs typically aren't too significant?

pineconewarrior 4y ago
webp, webp2, and avif are absolutely worth using in modern web scenarios. It's even considered "poor practice" to serve legacy formats now.
- alx__ 4y ago
  I wouldn't say it's "poor practice" to serve legacy formats. If you're using a setup to allow for fallbacks, that's the best practice. There are more device types some developers need to consider than the latest version of Chrome.
  - pineconewarrior 4y ago
    That's why I put it in the quotes. Google will flag you for core web vitals issues if you're serving jpegs and pngs all over the place. Many CDNs automatically serve the best format compatible with the useragent these days! Also... the bit about the latest version of Chrome is pretty far off. WebP has been usable for 90+% (for my use cases, 99%) of the web for a LONG time. The only thing holding us back was safari 14.0 which is now not on my list of targets!
cpncrunch 4y ago
You might want to check your pagespeed insights to verify that. I noticed that our pagespeed score was very poor (due to google using new methods to calculate those scores). Adding webp versions of images reduced the size of those images significantly, and brought our pagespeed scores back to more reasonable values in google's eyes.
- 4y ago

lajamerr 4y ago

JPEG XL is the standard to beat them all. Like how Opus became the definitive codec for lossy compression for the web. JPEG XL covers nearly every use case for images, even replacing GIFs with it's animation support. Existing JPEGs can also be re-encoded losslessly into JPEG XL format/data structure and get significant file size savings. This backwards compatiability is very important in transitioning to web to JPEG XL seamlessly. What I'm most excited about for JPEG XL is progressive decoding, I had been following the FLIF project for a while and was disappointed with it's lack of adoption. But it's future found itself in JPEG XL. Without a doubt 5 years now JPEG XL will become like Opus and set the standard for next generation image formats.

mgraczyk 4y ago
I used to think this, but I've lost confidence over the last year. I literally work on the software that generates jpg files on Googles Pixel phones, and there seems to be no realistic path to JPEG XL adoption within the next 5 years.
- jl6 4y ago
  Why not? What’s stopping the next Pixel phone producing JPEG XL images the same way the iPhone switched to HEIC images a few years back?
  - mgraczyk 4y ago
    To first approximation, nothing. And it's possible that we will at some point in the near future. The problem is consuming it. You won't be able to view the photo on device until Android adds it, or until the gallery and camera apps add custom software decoders. You won't be able to share with anybody until Facebook/Whatsapp/etc add support. you won't be able to view online until the browsers add support....
ComputerGuru 4y ago
I’ve read up about JPEG XL in the past but a question just occurred to me: is it just an image format or is it also a document format? Can it replace TIFF as a container for multi-page documents/images?

rektide 4y ago

I wonder how fpng[1] would compare- a lossless speed optimized png compressor. Oh! The author Rich screenshoted[2] a really nice deck[3] that also boasts fpnge[4] and fjxl[5], both of which are even faster, both use AVX2 (or neon for FJXL). Notably fjxl is in the reference libjxl tree. I'm not sure what if any constraints fast mode has, what it takes to use. The article uses cjxl, which does not run the fjxl fast mode, and further, fast mode was added after this article was written[6]. Other notes on jpeg-xl: it has progressive rendering. It has hdr! The deck on FJXL & FPNGE is epic. Thanks Quote Ok Image (QOI) format for setting the fire on this all!! [1] https://github.com/richgel999/fpng https://github.com/richgel999/fpng [2] https://twitter.com/richgel999/status/1485976101692358656 https://twitter.com/richgel999/status/1485976101692358656 [3] https://www.lucaversari.it/FJXL_and_FPNGE.pdf https://www.lucaversari.it/FJXL_and_FPNGE.pdf [4] https://github.com/veluca93/fpnge https://github.com/veluca93/fpnge [5] https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless https://github.com/libjxl/libjxl/tree/main/experimental/fast... [6] https://github.com/libjxl/libjxl/pull/1124 https://github.com/libjxl/libjxl/pull/1124

planetsprite 4y ago

JPEG 2000

bumper_crop 4y ago

The best lossless format is the one you can decode back to the original image. When evaluating them, there is an implicit assumption that the decode step will happen a short time later, but that's not always true. Will there be JPEG XL decoders commonly available in 40 years? Will the code even compile then? As a thought experiment, try to find the lossless encodings from 40 years ago and see if they can be faithfully reproduced. (or even 20 years ago, remember JPEG2000?) Framing best in terms of file size or encoding speed is a really use-specific framing, and not ideal for preservation.

bragr 4y ago
This seems excessively handwringing about code rot. TIFF was introduced 35 years ago and still well supported. JPEG2000 didn't become super widespread, but is still used in many places. Smart passports encode your passport photo in JPEG2000 for example.
- accrual 4y ago
  Another example is in radiology. Many thousands of medical images are created and stored in lossless JPEG2000 every day with entire ecosystems of software to store and move them.
  - ollifi 4y ago
    Also in digital cinemas films are JPEG2000 sequences.
    - imagetic 4y ago
      Huh?
      - mkl 4y ago
        Exactly what they said. Movies in cinemas with digital projectors are distributed as sequences of JPEG 2000 images: https://en.wikipedia.org/wiki/Digital_Cinema_Package https://en.wikipedia.org/wiki/Digital_Cinema_Package

pm2222 4y ago

https://bellard.org/bpg/ https://bellard.org/bpg/ Not sure if this fits your bill.

Melatonic 4y ago

If you want something that is going to be around for awhile and has a LOT of features you probably do not need then you are going to want to go probably with a .DPX or .EXR which are the standard for the VFX industry as well as film in general. On the consumer side I guess adobe .DNG might not be bad either or for maximum compatibility but then maybe a Tiff. For video I personally like Cineform but both ProRes and DNxHD are more widely used EXR will get you full 32 bit float if needed

detuur 4y ago
How do EXR and JXL compare to each other, feature-wise?
- Melatonic 4y ago
  I have never used JXL honestly - no job I have had it was ever even considered. Given the Jpeg in the name I doubt any pro studio would consider it given the other options do everything needed. DPX is basically the older standard for film and EXR is the newer one. edit: Just looked at the specs and JpegXL is definitely marketed at least more as a web end viewing file type. It does higher color depths (up to 16 bit) which is pretty good but will not do 32 bit like EXR. Given that EXR is so widely used I would likely not consider anything else.
  - lifthrasiir 4y ago
    JPEG XL definitely supports 32-bit float samples, but cjxl is currently unable to read a 32-bit EXR [1] (compare with PFM [2] which is fully supported). [1] https://github.com/libjxl/libjxl/issues/465 https://github.com/libjxl/libjxl/issues/465 [2] http://www.pauldebevec.com/Research/HDR/PFM/ http://www.pauldebevec.com/Research/HDR/PFM/
    - Melatonic 4y ago
      Got it. Well that is good at least. Realistically I can see JPEGXL becoming a good DELIVERY format but I highly doubt any industries will be swapping to it for production use (or archiving) given there are very widely adopted formats and standards already that can do the same thing. I'm almost tempted to say that trying to make ONE format that is meant for both (delivery and production or archiving which are inherently opposites in terms of requirements) is a bad idea just from a marketing and ease of use standpoint. Sometimes its nice to have two clearly separate technologies meant specifically for their purpose.

aaaaaaaaaaab 4y ago

I want to see if they’re really lossless. I know for a fact that PNG is. But last I checked HEIF didn’t support lossless RGB images, only lossless YUV… So HEIF was unusable for bit-perfect reproduction of the original.

huachimingo 4y ago

PNG vs JPG on a nutshell: https://i.stack.imgur.com/qJoKW.png https://i.stack.imgur.com/qJoKW.png

bobbylarrybobby 4y ago

I guess this would be a good time to plug a small project I worked on: https://github.com/rben01/collagen https://github.com/rben01/collagen . I got tired of seeing how crappy text looked when placed on a JPEG (due to the compression artifacts) and how large some PNGs were because they had a small JPEG-like area, so I made a little CLI program that solves that problem. Rather than settle on any particular image format, it allows the user to provide a collection of inputs -- images (in any format your browser supports), SVGs, shapes, text -- and bundles them into a single SVG file (it base64 encodes the images). So if you want to scale a PNG and place it on top of a JPG, you... just do that, with SVG transforms and whatnot. It produces a single file and is a lot easier than writing out the SVG yourself, and is nearly as easy as opening up a tailor-made mage editor and doing it there. And it's really, truly lossless, as it doesn't touch any of the input data. In theory, you wouldn't even transmit the SVG directly; you'd zip up the components and send them across the network and then encode them into an SVG on the other end, which would mitigate some of the size increase due to base64 encoding.

travisgriggs 4y ago

I was kinda sad QOI (https://github.com/phoboslab/qoi https://github.com/phoboslab/qoi) wasn’t included in the comparisons.

lifthrasiir 4y ago
QOI is kinda overrated, especially given the existence of fpng(e) and fjxl which operate within the limitation of existing formats and generally outperform QOI. QOI is a great demonstration that better prediction can make up for less efficient coding, but not much beyond that.

zuzulo 4y ago

Very good article

_448 4y ago

What, no one mentioned MNG[0] yet? :) [0] http://www.libpng.org/pub/mng/spec http://www.libpng.org/pub/mng/spec

raxxorraxor 4y ago

For raw data it would be Bitmap as it provides easy access. As a more obvious answer I would still go with png and webp since it is most widely supported.

F-app 4y ago

High quality? Less size? Most importantly, Microsoft and Apple don't like the new image format. They are founding members of AOM, but they reject AVIF. Most browsers using Blink engines, including Chrome, support avif, but not Edge. Safari? Of course not. Safari is Apple's version of Internet Explorer. The fact that Apple devices cannot use webp efficiently is why many webmasters and service managers still do not adopt webp.