Felldude

/

FLUX.2-HDR-VAE

like 5

So no monitor on the market can do 16 bits per channel.

But yes the VAE does produce less quantized color but you must output using OpenCV and normalize by 65k not the standard /255 - If pillow touches the workflow it is ruined.

Right, but arguably there is little to no need for such precision for content consumption, 10bit is far more than enough unless you’re editing. If this can actually reach up to 16bpc then that is actually very impressive and useful if you’re going to further edit, but my question was actually more referring to “HDR” (and WCG) outputs, and more specifically range of the peak brightness/luminance of the image that is generated as well as the color gamut.

Admittedly I’m not very familiar with the workflow you are suggesting, are you saying that it’s not enough to simply use this in place of the standard VAE?

It depends on your goal, with a standard workflow it still increase lab color, total number of colors and other metrics but they will never be in the HDR range with a standard workflow.

When normalizing for a VAE you can either divide by 255 or by 65535 to get your -1 1 float range (See below) OpenCV is needed to do this but nearly every script built uses PIL which does not support this.

So a simple change is to make a comfy node that decodes the latent using the 65535 normalization and saves in 48bit png format using OpenCV

Regarding the human eye most claims say we can not see the billions of color values in 48bit anyway with one exception:
The "Banding" Problem: When you look at an 8bpc gradient (such as a sunset), you may see distinct, chunky lines (banding) because there are only 256 steps from one brightness or color to the next.Where 16bpc Shines: A 16bpc file smooths out these gradients by offering thousands of subtle tonal steps in-between the same physical bounds, making lines or "stripes" invisible to the eye

Range and step size

int8 (0–255) → 256 discrete levels

    Step size when normalized to float32 /255:

    1/255≈0.0039215691 / 255 \approx 0.0039215691/255≈0.003921569

    This means you cannot represent any number between 0 and 0.003921569 in float32 via int8; the spacing is coarse.

int16 (0–65535) → 65,536 discrete levels

    Step size when normalized to float32 /65535:

    1/65535≈0.0000152591 / 65535 \approx 0.0000152591/65535≈0.000015259

    Much finer granularity: you can represent very tiny differences between values, which float32 can capture.