Hacker News Reader

Comment by mgraczyk | Hacker News Reader

> Jpegli can be encoded with 10+ bits per component.

How are the extra bits encoded?

Is this the JPEG_R/"Ultra HDR" format, or has Google come up with yet another metadata solution? Something else altogether?

Ultra HDR: https://developer.android.com/media/platform/hdr-image-forma...

View on HN

It's regular old JPEG1. I don't know the details, but it turns out that "8 bit" JPEG actually has enough precision in the format to squeeze out another 2.5 bits, as long as both the encoder and the decoder use high precision math.

Wow, this is the first time I heard about that. I wonder if Lightroom uses high precision math.

This has nothing to do with Ultra HDR. It's "simply" a better JPEG encoder.

Ultra HDR is a standard SDR JPEG + a gain map that allows the construction of an HDR version. Specifically it's an implementation of Adobe's Gain Map specification, with some extra (seemingly pointless) Google bits. Adobe gain Map: https://helpx.adobe.com/camera-raw/using/gain-map.html

Thanks, I was on the team that did Ultra HDR at Google so I was curious if it was being used here. Didn't see anything in the code though so that makes sense.

Something I've been wondering about with the Ultra HDR format, is why did you add the Google GContainer? As far as I can tell, it doesn't do anything that the MPF part doesn't already.

I didn't actually work on the format, just happened to be on the same team. My guess would be that it's related to compatibility with the places the format need to render (android, chrome, photos) or possibly necessary to preserve edit metadata.

Ultra HDR can have two jpegs inside, one for the usual image and another for the gain-map.

Hypothetically, both jpegs can be created with jpegli.

Hypothetically, both Ultra HDR jpegs can be decoded with jpegli.

In theory jpegli would remove the 8 bit striping that would otherwise be present in Ultra HDR.

I am not aware of jpegli-based Ultra HDR implementations.

A personal preference for me would be a single Jpegli JPEG and very fast great local tone mapping (HDR source, tone mapping to SDR). Some industry experts are excited about Ultra HDR, but I consider it is likely too complicated to get right in editing software and automated image processing pipelines.

What is the point of that complexity if JPEG XL can store HDR images ?

The main idea why Ultra HDR is done like that is that the content creator (photographer) can control the local tone mapping. I think.

Reply on news.ycombinator.com