XT, XR, XL, XS. I wish the names were more meaningful. I can never remember which one is which or what they're good for, or even which order they came in (and the jpeg.org pages don't even list years).

JPEG XL is the one currently in development, and it has what sound like some really neat features, like floating point pixel data, and lossless conversion from JPEG (and according to Wikipedia [1] back to JPEG, but I'm guessing that only applies to images that went JPEG -> JPEG XL -> JPEG).

[1] https://en.wikipedia.org/wiki/Joint_Photographic_Experts_Gro...

The answer for JPEG XT is in Wikipedia:

https://en.wikipedia.org/wiki/JPEG_XT

"JPEG XT extensions are backward compatible with base JPEG/JFIF file format - existing software is forward compatible and can read the JPEG XT binary stream, though it would only decode the base 8-bit lossy image."

It is a standardization of how to put additional data in the already existing JPEG file format, the one that we already have supported everywhere.

Then, if some software "understands" what the XT parts of these JPEG files mean, it can use these new parts, still, the files are usable on every device, just these XT parts don't mean anything to the devices that don't understand XT.

The additional data can be used, for example, but neural nets pretrained to cleanup particular images. Similarly, the data could have vectorisation data for key features.

You can think of them all as JPEG NB.. 'no browser support' ;)

Still, "backwards compatible extensions to the legacy JPEG standard". So there's that.

That's what polyfills are for.

Loading a large js library to transcode images in the browser to display them, nice idea /s

Images are much bigger than javascript libraries. So by comparison it's a small library. And you're probably decoding, not transcoding.

You want to get browser support, but a gap-filler can keep you from waiting forever to reach 99.9%. And sometimes bandwidth use is more important than clunkiness.

The FLIF one actually seems to work semi-well. Not as fast as native JPG or PNG or anything but works ok.

https://uprootlabs.github.io/poly-flif/

Being backwards compatible is JPEG XT's tentpole feature.

If no browsers support the extra bits, what's the point?

Because then people can just start using XT without any ill effects. So that’s a definite advantage.

As soon as you have some usage browser vendors will then be much more willing to support it.

Please see the W3C Patent Policy regarding Web standards.

https://www.w3.org/Consortium/Patent-Policy-20040205/

> The goal of this policy is to assure that Recommendations produced under this policy can be implemented on a Royalty-Free (RF) basis.

The browser scene is very different these days. Browsers are evergreen or yearly updated.

So are creation tools such as Adobe’s.

JPEG XR is only supported by IE (since version 2011) and Edge before the switch to Blink/Chromium. Webp is supported by everyone except Safari and IE, but Safari and mobile Safari have about 15-20% combined market share.

New formats are basically only relevant if they get blessed by Google/Chrome, and even then you often need fallbacks for a long time.

The thing that held us back before was legacy tools and browsers. Not anymore.

If we can agree on a standard (hard, I know) we can star using it pretty quickly.

Many browsers support some formats that are favorites of some vendor, but the new formats are not supported cross-browser, so the benefits of switching formats are reduced and the costs are raised -- in particular, one benefit of smaller files is reduced storage cost. If you have to support JPEG for legacy and then something else for Microsoft's format and something else for Google you are increasing your storage cost, encoding complexity, etc.

I looked at alternative image formats for a photo site I was working on and never convinced myself that the benefits of switching formats was worth the trouble.

The only ones I can ever remember are jpeg and jpeg2000. To be honest most tech has horrible naming schemes. The iPhones were a breath of fresh air for a while (iPhone 3G/S, iPhone 4/S, iPhone 5/S, iPhone 6S/Plus) up until the 7.

Patent encumbered?

Yes, there is at least one third party patent license administrator for JPEG-XT:

https://www.sisvel.com/licensing-programs/digital-video-disp...

The JPEG committee didn't believe it was patent encumbered, but Sisvel came along and put together a portfolio of patents it claims must be licensed to use JPEG XT. However, Sisvel at present is only claiming that devices with cameras have to license the patents.

Sisvel did the same thing with VP9 and a couple of other recent video codecs.

You may want to append (2015) to that title.

See also: https://en.wikipedia.org/wiki/JPEG_XT

Jpeg XS Max