← Back to context

Comment by carra

2 days ago

Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.

You can really treat WebP as a universally available format in 2026. It is an old, boring, and safe format to use now.

Browser support for WebP is excellent now. The last browser to add it was Safari 14 in September 16, 2020: https://caniuse.com/webp

It got into Windows 10 1809 in October 2018. Into MacOS Big Sur in November 2020.

Wikipedia has a great list of popular software that supports it: https://en.wikipedia.org/wiki/WebP#Graphics_software

  • Webp can be really annoying once you hit certain encoding edge cases.

    One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.

    • Just out of curiosity, what's the problem libwebp has with them? I wasn't aware of cases where any image format would just cross its arms and refuse point blank like that.

      4 replies →

"JPEG XL" is a little bit of a misnomer as it's not just "JPEG with more bits". It supports lossless encoding of existing content at a smaller file size than PNG and allows you to transcode existing JPEGs recoverably for a 20% space savings, the lossy encoding doesn't look nearly as ugly and artifacted as JPEG, it supports wide gamut and HDR, and delivers images progressively so you get a decent preview with as little as 15% of the image loaded with no additional client-side effort (from https://jpegxl.info/).

It is at least a very good transcoding target for the web, but it genuinely replaces many other formats in a way where the original source file can more or less be regenerated.

  • Honestly, I don't like how webp and now jpegxl support both a lossless and lossy mode.

    Let's say you want to store images lossless. This means you won't tolerate loss of data. Which means you don't want to risk it by using a codec that will compress the image lossy if you forget to enable a setting.

    With PNG there is no way to accidentally make it lossy, which feels a lot safer for cases you want lossless compression.

    • PNG can and is often used in a lossy way. Reducing the number of colors so PNG8 can be used instead of PNG24/PNG32 is the most common way to do that. Tools like pngquant exist, and for example Photoshop when exporting to PNG also has an option to reduce the colors, to flatten the image (remove alpha), or to change the colorspace.

      16-bit PNG files can easily accidentally be reduced to 8-bit, which is of course a lossy operation. Animated PNG files can easily get converted into a still image (keeping only the first frame). CMYK images will have to be converted to RGB when saving them as PNG, which is also a lossy operation. It can happen that an image gets created as or converted to JPEG and then gets saved as PNG - which of course is a bad and lossy workflow, but it does happen.

      So I don't agree that with PNG there is no way to accidentally make it lossy.

      In any case: lossless or lossy is not a property of a format, but of a workflow. For keeping track of provenance information and workflow history, I would recommend looking into JPEG Trust / C2PA, which is a way to embed as metadata what happened to an image since it was captured/generated. Relying on the choice of image format for this is fragile and doesn't allow expressing the nuances, since reality is more complicated than just a binary "lossless or lossy".

    • You can use too few bits of color depth to get lossyness in PNG. More generally, I can't find myself very sympathetic to "I don't want a format that can do X and Y, because I might accidentally select X when I want Y in my software". You might accidentally choose JPG when you want PNG too. Or accidentally resample the image. Or delete your files.

      If you want a robust lossless workflow, PNG isn't the answer. Automating the fiddly parts and validating that the automation does what you want is the answer.

    • Taking a look at the reference codec package at https://gitlab.com/wg1/jpeg-xl, they note:

      > Specifically for JPEG files, the default cjxl behavior is to apply lossless recompression and the default djxl behavior is to reconstruct the original JPEG file (when the extension of the output file is .jpg).

      You're right, however, that you do need to be careful and use the reference codec package for this, as tools like ImageMagick create loss during the decoding of the JPEG into pixels (https://github.com/ImageMagick/ImageMagick/discussions/6046) and ImageMagick sets quality to 92 by default. But perhaps that's something we can change.

You should never use GIF anymore, it is super inefficient. Just do video, it is 5x to 10x more efficient.

https://web.dev/articles/replace-gifs-with-videos

  • There's odd cases where it still has uses. When I was a teacher, some of the gamifying tools don't allow video embeds without a subscription, but I wanted to make some "what 3D operation is shown here" questions with various tools in Blender. GIF sizes were pretty comparable to video with largely static, less-than-a-second loops, and likely had slightly higher quality with care used to reduce color palette usage.

    But I fully realize, there are vanishingly few cases with similar constraints.

  • Videos and images are treated very differently by browsers and OS:es. I'm guessing the better suggestion would be to use apng or animated avif if you are looking for a proper gif alternative.

  • Unfortunately browser vendors didn't want to support silent looping videos in <img> tags so gif stays relevant.