I want a return to an enforced norm of different extensions for lossy and lossless files. With the adoption of WebP, I've repeatedly encountered shady CDNs substituting in lossy .webp files in place of lossless .png files, in a way you can't tell by the filetype alone when saving a file (whereas you could tell when saving a .png URL but get a .jpg file instead). I fear the same will happen with .jxl files.
The lossy vs lossless distinction loses its meaning in the absence of provenance. You can compress a bitmap into a .jpg q=1, and then save it as a .png. The .png is technically lossless, but that clearly doesn't tell much about the image quality. Conversely, many cameras shoot JPEG as the source format. The .jpg is, in effect, the master copy from which the loss is measured (obviously there are losses from the sensor data, but still).
And a CDN could want to do it, because you can degrade a png in lossy ways from the original that make it compress much better, even though the compression is lossless.
It wouldn't be effective in practice. There are tools like pngquant that does lossy compression of png. That shady CDN could just as easily recompress png files.
I voiced the exact same thing for many years and unfortunately the author of jxl doesn't agree with that. I wish the same as well we could just tell by file type.
Seems to be just a rumor, but one that I hope is true. I also hope they use it as an opportunity to finally fix the longstanding ugly wart of having Live Photos be a separate .MOV file sitting alongside the HEIC file. JPEG XL is a container format so it should be possible to include the MOV as a separate box alongside the jxlc data and exif metadata. Of course, HEIF had the same capability and they still didn’t use it.
Technically they could already do this as JPEG allows adding arbitrary data to the file after the image data. ZIP files allow arbitrary data BEFORE the image data, therefore a file can be a valid JPEG and ZIP at the same time. So all you need to do is to put the MOV into a ZIP and append that to the image file, done. Live Photos in a single file!
Btw., you can abuse the „unlimited“ „free“ photos storage that comes with Amazon Prime that way.
You may enjoy the https://pocorgtfo.hacke.rs/ zine where every release is a polyglot file. Some of the PDFs are bootable systems, some are NES cartridges, etc.
In addition to the compression, JPEG-XL has some nice features that make it better image format. It also does lossless compression. It does color spaces.
One cool feature is that can losslessly convert JPEG into JPEG-XL. And back to JPEG. I can't tell if this applies to all or only converted ones, but it might make good source format and convert to JPEG on export.
> I can't tell if this applies to all or only converted ones
JPEG-XL to JPEG is only lossless for JPEG-XL images which were upgraded from JPEG.
Not all JPEG-XL images can even be represented as JPEG; in particular, images with more than three channels (like images with transparency, or images with CMYK color) or with multiple frames (like an animation) certainly can't.
What about those that can be represented? Is it possible to convert lpsslessly by losing some compression efficiency or still only upgraded can be downgraded?
JPEG XL has many compression modes inside, and the lossless JPEG roundtrip works only for one of them that was specifically designed to hold old JPEG's data. You can't take an arbitrary JXL file and turn it into a JPEG without lossy recompression.
The old-JPEG-preserving compression mode also isn't the best that JXL can do. It's better than the old JPEG, but not as good as JXL using all the new bells and whistles.
For images at low bit per pixel, HEIC is actually quite a bit better than JPEG-XL current encoder. I wouldn't say really an upgrade technically speaking, I would put them on same level with XL have some additional interesting feature.
But considering getting HEIC included in other system seems to be difficult due to patents or other reasons. JPEG-XL seems to be the best middle ground in everything.
I am still hoping there could be additional work on JXL in terms of low bit per pixel improvement and encoding / decoding resource usage. Especially in the lossless front.
Yes, the progressive rendering is really cool, lossless mode is better, lossless recompression of JPEGs is a cool feature, it's faster, it supports larger images (without tiling) with more channels and higher bit depths.
Compared to the stark differences between BMP/JPG/PNG/GIF, there's a ton of overlap between WEBP/HEIC/AVIF/JPEGXL.
Naturally, some types of images tend to compress better with some formats than others, and then you may have to take into account things like the desired quality level, encoding time, etc.
Realistically, any of those four new formats would be fine for 99% of the images that exist, but it would still be nice for every browser to support them all so that web developers can choose their favorite format.
Although, on the flip side, the drawback of having so many formats floating around is that software developers have to spend more time supporting it all. Even trillion dollar companies like Microsoft are seemingly in no rush to make sure that formats like WebP are as well integrated into their software as JPG/PNG were.
You forgot that that 12.5% could change "overnight" if Google change their hostile stance, and adding it as a default in a very popular phone increases the chances of that happening, so add a few zeroes to that 2
Interestingly, when visiting the JPEG-XL test page referenced in the article, everything renders but the animation at the bottom for JPEG-XL doesn’t move. The others do. iPhone 15 pro on safari
In which case Google and Microsoft are sure to immediately cease any work on supporting this open format, just so that they can claim Apple is unfairly preventing interoperability.
24 megapixel almost-lossless photos dumped straight from the camera are too heavy to be used directly on the Web. They also have lots of metadata including GPS location, that people usually don't want to share.
In practice you'd want to resize it (HD is 2mpx, and 4K resolution is 8mpx), and recompress to quality suitable for viewing not editing (makes huge difference in file size).
The necessary recompression step makes the input format mostly irrelevant. The upside is that JPEG XL is free to use, so it's possible to legally write tooling using it without touching the mess of H.265 patents.
macOS 14 / Safari 17.6 shows static pics, but no animation.
Honestly, I wish all animated image formats would just die. They are an inefficient way to animate images, because they only use intra frames. H.264, H.265 or AV1 should be used for animations. Fortunately, Safari can display video files in <img> or CSS images, which makes all animated image formats unnecessary.
Yes, it does. It's a limited sort of animation like GIFs were; JPEG XL is not derived from video codecs like WebP, AVIF, and HEIF are, where those formats include "animation" by really breaking out of being a subset and just being the regular intraframe video codec.
The Firefox and Chrome teams will likely get around to adding it eventually, but it's a real shame that they've both chosen to defer it. Normally Safari is the one lagging behind on web standards but somehow it's ended up being the one to lead the charge here.
I like PNG's lossless compression. I feel like PNG was a really bad format back when hard drives were 100GB, but now storage is so cheap. I didn't know JPEP-XL had a lossless mode. Other than that format, I don't know of any other formats that offer lossless compression other than bitmap and TIF. You can't really use TIFs in many contexts and bitmaps have no compression at all.
> I feel like PNG was a really bad format back when hard drives were 100GB
You talk about "hard drive" space even though phones don't have hard drives (more to the point, even if you transfer photos to your desktop they will start on your phone and take up space). The iPhone 15 base model comes with 128GB storage.
Uncompressed images take up huge amounts of space and that still affects network transfer times, phone storage, cloud storage, etc.
Anyway you can shoot RAW on your phone right now, which is what you are looking for. Still, it is a niche application because of the storage required.
Because of how PNG compresses images. The high detail will lead to large images, and at that point it’d be easier to save the RAW output of the camera, offload the images, and do any compression later.
My idea for wanting PNG encoding is that they have lossless compression, and that the other common format that preserves details is bitmap, which has no lossless compression. At least PNG might compress photos somewhat. The web is plagued with images that have been resaved over and over that have JPEG degradation. I did not know JPG-XL had a lossless format so that's promising imo. But JPG-XL isn't supported in many browsers.
