Hacker News Reader

Comment by yboris | Hacker News Reader

PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!)

https://jpegxl.info/

View on HN

As a mobile developer I generally see WEBP getting served to Android devices and HEIC to Apple devices. Is there any advantage to JPEG XL over those?

If our app supported older iOS devices, maybe JPEG would be needed as a fallback, but it seems like JPEG XL wouldn't be compatible with old devices anyway, right?

I don't believe any platforms or browsers have enabled JPEG-XL support yet, so right now you'd need to ship the decoder yourself anyway.

But, it's at least as much better than WebP as WebP was better than JPEG. And unlike HEIC, web browsers are considering supporting it, though AVIF is currently ahead of JPEG-XL in browser support.

JPEG-XL also currently beats HEIC and AVIF at medium to high quality, but it's a fair question just how much that's intrinsic to the format and how much that is from libjxl's tuning focus being at those quality levels; AV1 and HEVC encoders have mostly focused on lower bitrates in the range that video would use.

JPEG-XL is the ~best lossless image format currently available, though.

> though AVIF is currently ahead of JPEG-XL in browser support.

It certainly looks like AVIF is ahead because it has landed in and Firefox and Chrome, but it's blocked in Safari by a required OS change[0] (iOS/macOS support if I understand the comment correctly?). Additionally, there's no implementation in Edge (even though it's chromium)[1]. Sorry, I wish I had more details but I'm not sure where to look to find a status update on that.

Meanwhile, JPEG-XL has support behind a feature in every major browser except Safari[2]. As you and others have noted, there seems to be a lot of buzz and excitement around JPEG-XL throughout the ecosystem. The webkit folks seem to be making an effort to get the ball rolling[3]. I might be misinterpreting something but it all looks very encouraging at any rate. It almost seems like it might gain wide support in Firefox and Chromium (Chrome & Edge) around the same time with Webkit following (hopefully) closely thereafter. Heck, I don't see why Webkit doesn't just abandon AVIF and focus on rolling out JPEG-XL.

[0]: https://bugs.webkit.org/show_bug.cgi?id=207750#c25

[1]: https://caniuse.com/avif

[2]: https://caniuse.com/jpegxl

[3]: https://bugs.webkit.org/show_bug.cgi?id=233364

you can serve new devices with JPEG XL and convert it back to JPEG without loss on server for old devices

I think you might have that backwards. JPEG can be losslessly converted to JPEG XL with better compression (~20% smaller), but I haven't seen anything about going the other direction. I'm not sure how it would be possible with JPEG XL's different sized blocks and different available transforms. https://en.wikipedia.org/wiki/JPEG_XL

The JPEG -> JXL conversion is reversible, so you can encode JPEG -> convert JXL -> convert back to JPEG as needed. You could potentially encode a JPEG-XL directly with the subset that can be converted back to JPEG, but it's not clear to me if libjxl currently implements that.

Either way, it's not that useful for anyone that's already deploying post-JPEG formats; even WebP should save more than 20%. Mostly it's useful for CDNs and SaaS companies like Cloudinary to transparently deploy JPEG-XL for JPEG-only customers.

Do you mean that you would want that to happen on the web server, if they detect a user-agent that doesn't support JXL, they would convert back to JPEG? That seems pointlessly costly in CPU.

Also like mkl said, there doesn't seem to be any evidence that JXL->JPEG can be done losslessly.

Dont know about web servers, but there are people doing it on the backup/storage side. https://dropbox.tech/infrastructure/lepton-image-compression...

I tried it locally on my computer, JPEG -> JXL -> JPEG results in two bitwise identical JPEGs.

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer.

I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

try out darktable, its way more capable of a raw editor then those two and usually gets support for new export formats fairly fast.

I actually meant to say Capture One and Photoshop. I know this is HN and we're gung-ho about open source but the last time I tried Darktable it didn't hold a candle to Capture One. To be fair that was a few years ago, but the color work put in to Capture One doesn't really have an equal IMO.

not sure when you used it but you should try it again now... i have been on Lightroom and Capture One for years, tried DT last year and never bothered coming back to them, nothing to do with it being open source its just straight up a better raw editor, yes its hard to learn but once you figure it out you will see how much better it handles editing raw images, especially with the filmic module

It has poor support for input formats though. E.g. it still doesn't support CR3. I prefer RawTherapee which supports CR3, doesn't look like a space station and still is miles ahead of Lightroom in terms of capability.

JPEG2000 is a good option for lossless compression. JPEG XL seems to offer better result and improvements now, but it isn't yet mainstream and has competition.

Have you ever tried to open/save JPEG2000s in Photoshop? It's ridiculously slow compared to pretty much anything else.

Plus, it doesn't really matter when I can't deliver files to clients in that format.

I use the J2K photoshop plug-in - https://www.fnordware.com/j2k/ . And even macOS Preview supports JPEG2000 (HEIF on macOS on the other hand is not suitable for professional graphic works; doesn't work with CMYK).

A jpeg pixel is 64 (=8 x 8), 8 bit coefficients which are summed together for each pixel. That result is not 8 bits, but more; that is a misunderstanding, often repeated. A jpeg is capable of over 11 bits dynamic range. You can figure out that an 11 bit dynamic range image has more than 8 bits. See the wikipedia.

A jpeg pixel is not 64 eight-bit coefficients. Jpeg compresses an 8x8 pixel block at a time by taking a DCT (which mathematically is lossless, but in practice is not due to rounding and quantization at this stage), which turns those original 8x8 values into another set of 8x8 values, then some of these are thrown away and/or quantized for lossy compression.

Decompression is the reverse: take these 8x8 quantized DCT coefficients, perform an inverse 8x8 DCT top get pixel values.

The 11-bit dynamic range part you claim is merely from a color profile, which takes the resulting 8 bits per channel (i.e., 256 possible values) and spreads them over a gamma curve to an 11-bit range. But there are still only 256 possible levels per channel, too few for quality image editing.

Think of it as squaring: taking [0,255] as your input and squaring every value gives you a range of 0 to 255^2 = 65025, but that does not allow you to store any value in that range. It only allows you the 256 values that are squares.

So the dynamic range is 11 stops, but the number of representable levels per channel is still 8 bit: 256 levels. This makes gradients band no matter how you do them in JPEG.

It's why photo processing software wants RAW, not JPEG. JPEG, besides being lossy, does not allow enough steps.

One example: given a so-so RAW, at 11 bits, you can pull out dark things or darken bright things smoothly. This is not possible once you go to jpeg, for any implementation of jpeg.

I said a jpeg pixel is the summation of 64 8 bit coefficients. The coefficients are 8 bit, but obviously the cosine values are not 8 bit. They can be floating point. All a jpeg need give is coefficients, the coder/decoder knows what to do with them. Summing 64 products, with each product = 8 bit numbers x cosine value gives more than an 8 bit result for the resultant pixel. In addition, there is another dct for the color values. This adds more bits of info.

The cosine values are transcendental numbers, they can have an infinite number of decimal places, yes? So adding up 64 products of (cosine values * 8 bit integer) to get 1 pixel value can obviously have more than 8 bits.

No, a jpeg pixel is not "the summation of 64 8 bit coefficients." I've written jpeg codecs (and many other image formats). It works just as I explained above.

Or simply read the libjpeg source.

Don't like that, read this [1]: "JPEG images are always recorded with 8-bit depth. This means the files can record 256 (28) levels of red, green and blue."

Don't like that, here [2] is the JPEG ISO standard, section 4.11, baseline jpeg, "Source image: 8-bit samples within each component".

A DCT takes an 8x8 pixel input, 8 bits per channel, and transforms them into an 8x8 output. It matters not what these are - the information theory content is nothing more than what was put into it. There is not suddenly magically more information content.

More simply, appending zeroes to a number does not mean you can represent more numbers. You simply can represent the exact same numbers, just wasting more space.

None of what you wrote adds more resolution at the output. It simply isn't there.

If I give you 5 possible inputs to a function, then you have 5 possible outputs, not matter how many digits you finagle into representing the output.

Jpeg has 8 bits of resolution per channel. End of story. That is why professional photos are taken and edited in raw - you get more bits of resolution per channel.

I'm not sure why you're still arguing this. It's a longstanding, well known issue, and I explained it all again very simply.

If you think it isn't true, encode one of your magic jepgs with more than 256 levels of gray and post it here. Good luck :)

If you cannot do that, then maybe you should consider that you're wrong.

[1] https://www.photoreview.com.au/tips/editing/bit-depth/

[2] https://www.w3.org/Graphics/JPEG/itu-t81.pdf

What you have described is usually called a 24 bit rgb image--not a 8 bit image. An 8 bit image can have only 256 distinct levels, whereas a jpeg can have ~16 million or 2^24 values for each pixel. 8 bit images are used often for medical imaging, but they are crude compared to 24 bit rgb images. One can argue that 24 bit rgb images are too crude, but they should not, IMHO, be called 8 bit images. But that is often what people say about jpegs. Typical jpegs with 8 bit coefficients have much more information than 8 bit images. Perhaps typical imprecise terminology? [1] https://en.wikipedia.org/wiki/Color_depth#True_color_(24-bit... [2] https://www.quora.com/How-many-colors-does-a-JPEG-contain [3] https://en.wikipedia.org/wiki/JPEG#JPEG_codec_example << They walk thru the steps.

I never called them 8 bit images. I wrote 8 bits per channel. Each of RGB are channels. An RGBA image has 4 channels. A grayscale image has one channel. This is standard terminology. So an 8 bits per channel image with three channels is a 24 but image.

It is very precise terminology, used correctly. It's also covered in your links; you can read it there.

Now, if you encode gray levels in RGB, at 8 bits per channel, you do indeed end up with only 256 gray levels in the image, because for each pixel, R=G=B.

Actually the coefficients are 12 bit in JPEG, before quantization. In principle you can make pretty accurate 10-bit HDR JPEG files, and with an accurate JPEG decoder, it would work well enough.

The most common JPEG decoders though (in particular libjpeg-turbo) are using a cheap but not super precise iDCT that has 8-bit YCbCr as output, which then gets chroma-upsampled if needed and converted to 8-bit RGB. That causes the effective precision in reds and blues to be only 7-bit. But in principle you could have about 10 bits of effective RGB precision, it just requires a sufficiently precise JPEG decoder.

Alternatively, if you're being confused by the quoted intermediate DCT precision, that's not relevant to the final output either. You cannot implement any transform, DCT especially, without having intermediate values with a greater range than the input or output. Like, even a simple average of two 8-bit values (a+b)/2 has an intermediate range of 9 bits.

The JPEG spec does specify both 8 and 12 bit sample precision for lossy, but I don't think anyone ever implemented 12-bit since libjpeg never cared about it.

Libjpeg does have support for it. Unfortunately, you have to have two copies of the library, one for 8 bit and one for 12. And you have to rename all the API methods in one of the libraries so you dont get name collisions. I believe that LibTIFF has a build configuration for this so that 12bit JPEG data can be encapsulated in a TIFF file.

Thanks for that info!

To save others from Googling, the Wikipedia page: https://en.wikipedia.org/wiki/JPEG

Fair enough, but the end result is what really matters, and I regularly see banding in the skies of photos. Some people add grain just to help deal with that, which is a ridiculous problem to have in 2022.

Lossless JPEG transcoding is the killer feature moving forward from existing images. I can't wait for jxl's broad adoption.

If it's fast enough maybe it could be done in browser? Instant backward compatibility!

Did they avoid the prohibitive licensing that left JPEG 2000 dead in the water?

JPEG2000 wasn't technically better enough; wavelets are too blurry and less efficient to decode. For some reason there was an epidemic of terrible codec designs for a decade or two, though it could've all been patent avoidance.

Wavelets were a great idea... except AFAIK we never figured out fast algorithms or hardware implementations to optimize processing them, the way we did with Fourier Transform and the FFT algorithm and IDCT blocks.

A lifting implementation of a wavelet is pretty low complexity, iirc the CDF 9/7 used in JPEG2000 was effectively a 5-tap filter. Implementation-wise, the biggest issue is that approximately no one bothered optimizing their memory access patters for CPU caches with anywhere near the same attention FFTs got. Then unlike block-based codecs, you basically need to store 16-bit coefficients for an entire frame for 8-bit pixels, instead of per-block.

But ultimately, DCTs make it way cheaper to encode similar but wrong details, where in wavelets details are effectively repeated across multiple highpass bands so the only cheap option is to not code detail.

So bad its still industry standard in Cinema quality video codecs? Like the obfuscated jpeg2000 in RED codec.

Who says they know what they're doing?

DCI (how movies are sent to theaters) does use JPEG2000, but I think they just wanted something with 12-bit video and that's pretty rare in any codec.

One advantage is if you want to decode the same picture at lower resolutions; JPEG can do this equivalent to nearest-neighbor, wavelets can do it equivalent to a better filter than that. But still not as good as just decoding and resizing down.

should be FOSS and loyalty free

https://gitlab.com/wg1/jpeg-xl/-/blob/main/LICENSE

That license doesn't say anything about patents. This one does: https://gitlab.com/wg1/jpeg-xl/-/blob/main/PATENTS and only says that patents owned by Google are covered. So it may be that other companies patent the technology. The information in the repository is not enough to decide whether JPEG XL is safe to use.

There's this MS patent though?

https://www.theregister.com/2022/02/17/microsoft_ans_patent/

What's fascinating to me as a web dev is that (unless I'm mistaken), if I store all my images as JPEG-XL, I won't need to create thumbnails or resized images anymore... I think I can literally just hold onto the originals and just truncate the image binary stream at whatever resolution is required.

I'm not sure how this would interact with "right-click to save image" though... what resolution would it be at that point?

JPEG similarly has a progressive mode.

The problem with these formats is that they don’t offer enough of an advantage to overcome the disadvantage of have less than the enormous install base of JPEG. Look how much better PNG is than GIF and realize it only succeeded in replacing it (for static images) because of the Unisys patent suits, not because it’s so much better.

> Look how much better PNG is than GIF and realize it only succeeded in replacing it (for static images) because of the Unisys patent suits, not because it’s so much better.

GIF being limited to 8bpp would have meant that it would have been replaced eventually anyway.

>For images, there's a finally successor to jpeg

We've heard this a few times... JPEG2000, WebP, HEIF, AVIF. I bet JPEG XL will finally be it!

In the specifics: WebP is pretty popular in my experience.

In general: I expect that eventually something else will win, even if it takes a long time. There's too much room for improvement for the ecosystem to fossilize just yet.

"Your browser does not support JPEG XL"; I'm sure it's cool technology but whoever is behind it needs to hire developers and advocates to push code to Webkit / Blink to add support for it, else it won't get mainstream adoption.

From their webpage:

  Chrome: behind a flag since version 91.0.4470.0
  Firefox: behind a flag since version 90.0a1
  Edge: behind a flag since version 91
  Opera: behind a flag since version 77
  ImageMagick: since version 7.0.10-54
  XnView MP: since version 0.97.0
  ImageGlass: since version 8.1.4.18
  ExifTool: since version 12.23
  gThumb: since version 3.11.3
  OpenMandriva Lx: since version 4.3 RC
  GIMP: since version 2.99.8
  qimgv: since version 1.0.0
  PhotoQt: since version 2.4
  jxl-winthumb: with WIC-codec since version 0.1.11
  KImageFormats: since version 5.89.0

I have read that both Chrome and Firefox now support it if one enable the proper option in the about:config page (and its Chrome equivalent, but I avoid Chrome by principle).

It's in my to do-list in the coming weeks, I have not verified this yet.

for those that want to try: set image.jxl.enabled and restart the browser (via https://jpegxl.io/tutorials/firefox/#firefoxjpegxltutorial)

So, once again Safari isn't on the list which hinders adoption.

I really wish it stop behaving like IE by being on its own.

It’s available behind a flag, perhaps awaiting v1.0 in the reference implementation or something.

I really hope it takes off. There was a bit poor timing because widespread AVIF support happened _right_ before and now we need to beg browser vendors to adopt JPEG XL! I hope they don't balk at it for starting introduce too much file format cruft because JPEG XL is really, really something they should implement. It can succeed JPEG as well as PNG (lossless JPEG XL tend to destroy even optimized PNG). I'd much rather abandon AVIF support. It's just one of those annoying single-video-frame-as-a-picture hacks like WebP and HEIF without drive to make them outstanding image formats on their own for photography as well as line art.

Whatever happened to FLIF?

Got integrated into JPEG XL.

Is this too late? iPhones are shooting in HEIF now, which means there's already millions of HEIF images in the world. Surely that is the de-facto next generation image standard.

Reply on news.ycombinator.com