Why can colour values be set to > 100%?

[photoken]

I just noticed that colour values can be set to greater than 100% (and greater than 255 byte, etc.). What does this mean? What can be done with colours having those values? The on-screen appearance of those colours don't look any different than colours limited to <100%....

[Hoogo]

It's for HDR/32Bit, where colors are not restricted from 0 to 100%. They surely look the same on the screen, but look different after applying filters

[Herbert123]

Yes, this is quite important for a HDR workflow. By right-mouse clicking on the colour fields, you may select other units as well: for example, "Float", which is often used in such a workflow. These values cannot be displayed, though. In RAW editing values may exceed the 8bpc values too.

If you feel uncomfortable with these extended colour ranges, you can turn off "Extended Range" in the color editor.

[photoken]

Yes, this is quite important for a HDR workflow.

How is it important? In what scenarios do you use extended colours?

[Herbert123]

For visual effects, film compositing, 3d rendering, and so on, HDR is one of the standard workflows. As you (probably) know, a hdr image consists of multiple brackets, which allows for highlights and shadow to maintain details (which can only be visibly shown when the image is under or over exposed in an image editor) and the HDR look is a common technique.

Matte painters for film and FX have to have access to HDR painting and compositing for their work. Krita, for example, also allows for this:
https://www.youtube.com/watch?v=o7AF302wdrM

It allows one to paint details in the shadows and highlights - and for compositors these mattes can then be lighted and exposed any way they need without blowing out the highlights, for example.

[Hoogo]

The effect becomes most obvious to me when people have a picture with highlights and try to decrease the exposure. For example, the sun shining on some water.
At the start the highlights of a Jpg and a real HDR look the same on the screen, even though the HDR has values >100%, while Jpg has to stop at 100%. There's nothing whiter than white.
When the exposure is decreased, the highlights of the HDR are still highlights, maybe a little smaller, while the highlights of the Jpg are now gray.

So when you want to paint in HDR, at least the color picker should be able to hold colors >100%, but it's better when the color editor itself allows it.

[photoken]

Thanks for the explanations, guys. They make sense, and I did a little experiment:

I created a new 32-bit RGB image with a dark blue background. Then I used a very soft-edged brush to paint three colour swatches on the background layer:

Extended colours 01.jpg

The RGB percentages of the swatches:
Left: 0%, 50%, 50%
Middle: 0%, 50%, 100%
Right: 0%, 50%, 300%

Then I used a Histogram adjustment layer to reduce the highlight values of the output:

Extended colours ss.jpg

I can see the effects that you mentioned, but this experiment raised some more questions:

1. Without the Histogram adjustment, the middle and right swatches are the same colour. I expected to see some difference between the two. Is this a limitation of the computer screen and video driver?
2. Without the Histogram adjustment, there is a noticeable difference in the display of the edges between the middle and the right swatches. The right swatch (with extended colours) does not show a smooth transition along the edges. A smooth transition is only seen at high magnifications. Is this a problem with PL?
3. The effect of using extended colours only occurs with 32-bit images. I expected to see some of the effect on 16-bit images, but don't. Shouldn't the effect also occur with 16-bit images?

(These examples were created with the latest PL beta....)

[Juan]

AFAIK Histogram corection clamp the values, try using optmize hdr to see if it gives the same result.

Cheers,
Juan

[Hoogo]

Think of the old days when color was added to the home computers. Some of them used the RGB color space for their palette, starting with
1 Bit, 2 Levels, 8 colors, for example Sinclair Spectrum 1982
3 levels, 27 colors Schneider CPC 1984
3 Bit, 8 Levels, 512 colors like Atari ST 1985
4 Bit, 16 Levels, 4096 colors of the Amiga 1985,
6 Bit, 64 Levels, 262K colors of VGA 1987
8 Bit, 256 Level 16M colors, maybe XGA 1990?

2Levels_1Bit.png

3levels.png

8Levels_3Bit.png

These are all capabilities (or restrictions) of the hardware, be it the graphics chip, the display or the interface to the display. Obviously the color space has to be between black and the most brightest possible color, all he bits and levels are only used to make gradients finer. I'm quite sure this will also apply to machines with even higher depth of color, available since the late 90s, still anything but common.

Graphic formats in the computer can be in different depths and formats. In the old days these formats were closely tied to their hardware, but this wasn't useful for too long. There are file formats for 12 or 16 Bit per channel, still in the range of 0 to 100%, even though most of the hardware is using 8Bit. And there is HDR, that even exceeds the hardware limit of the range 0 to 100%.

1. Without the Histogram adjustment, the middle and right swatches are the same colour. I expected to see some difference between the two. Is this a limitation of the computer screen and video driver?
2. Without the Histogram adjustment, there is a noticeable difference in the display of the edges between the middle and the right swatches. The right swatch (with extended colours) does not show a smooth transition along the edges. A smooth transition is only seen at high magnifications. Is this a problem with PL?
3. The effect of using extended colours only occurs with 32-bit images. I expected to see some of the effect on 16-bit images, but don't. Shouldn't the effect also occur with 16-bit images?

1) The 100% is already the brightest possible color for the output device. It's a task for the program how it treats colors exceeding the limit, but clipping looks like a very reasonable way to handle it. Though Modulo, an automatic histogram correction or other options before output could be discussed, not only for HDR...
2) I guess it's because the transition goes from 300% to 0% over the same distance.
3) 16Bit are used for finer gradients, but they could in fact be used to have some headroom instead. I sometimes used 16Bit with headroom before PL had 32Bit. It's easy, just darken the picture with histogram correction, then add an adjustment layer to correct that. With other histogram corrections you could also add footroom, or have own bit depths for your picture, without having to change the program at all. But it isn't worth the effort anymore since 32Bit are available. 32Bit floating point numbers ignore the restrictions quite naturally, and 32Bit is not about finer gradients (though it has).

[Hoogo]

Just for fun: With good dithering pictures look quite well even if the bit depth is very shallow. This is still useful today, even with 8Bit you can still see banding sometimes. PL dithers pictures of 16 or 32Bit to the screen when Anti-Aliasing is enabled.

[bkh]

Without the Histogram adjustment, the middle and right swatches are the same colour. I expected to see some difference between the two. Is this a limitation of the computer screen and video driver?

If you are using colour management, this mainly depends on the colour management engine, display colour profile and chosen rendering intent. If you don't use colour management, I suppose that RGB values above 100 % are just clipped to 100 %.

[*]Without the Histogram adjustment, there is a noticeable difference in the display of the edges between the middle and the right swatches. The right swatch (with extended colours) does not show a smooth transition along the edges. A smooth transition is only seen at high magnifications. Is this a problem with PL?

I think that, again, this is a colour management problem. In your example, the transition seems smooth after you apply the histogram correction. If I use a matrix display profile, I can see all kinds of strange banding problems and strange colour shifts. CLUT profiles seem to work better.

[*]The effect of using extended colours only occurs with 32-bit images. I expected to see some of the effect on 16-bit images, but don't. Shouldn't the effect also occur with 16-bit images?[/list]

No, 16 bit values in PL only represent values between 0 % and 100 %, just with smaller steps than 8 bit. 32 bit images in PL have floating point values, so they can represent (virtually) arbitrary numbers, including negative ones.

Cheers,

Burkhard.

[photoken]

[*]Without the Histogram adjustment, there is a noticeable difference in the display of the edges between the middle and the right swatches. The right swatch (with extended colours) does not show a smooth transition along the edges. A smooth transition is only seen at high magnifications. Is this a problem with PL?

I think that, again, this is a colour management problem. In your example, the transition seems smooth after you apply the histogram correction. If I use a matrix display profile, I can see all kinds of strange banding problems and strange colour shifts. CLUT profiles seem to work better.

I think the banding (non-smooth transition) is probably affected by the fact that the Green value remained at 50%. Here's a blowup of the edges from a new experiment with a 32-bit image. The left swatch had RGB values of 0%, 50%, 300%; and the right swatch had RGB values of 0%, 300%, 300%:

colour banding.jpg

[*]The effect of using extended colours only occurs with 32-bit images. I expected to see some of the effect on 16-bit images, but don't. Shouldn't the effect also occur with 16-bit images?[/list]

No, 16 bit values in PL only represent values between 0 % and 100 %, just with smaller steps than 8 bit. 32 bit images in PL have floating point values, so they can represent (virtually) arbitrary numbers, including negative ones.

Just for the helluvit, I repeated the experiment on a 16-bit image using floating-point units for the colours. The results were the same as before, so it confirms what you said.