Any way to select color values greater than 255?

[London]

Working in 32-bit HDR mode with CGI-generated files, I want to select whites that are greater than 1 (e.g., have RGB values higher than 255/255/255). Is there any way to do this? 

Also, using the 32-bit preview, those >1 colors show up as black when managing the colors (filmic/sRGB), which is good at times, but difficult to do anything with, since I can't select them. Is there a way to turn off the over 1.0 white indicator? The attached screenshot shows the same image section with OCIO DisplayTransform on (lights image with unaliased black line) and Unmanaged (the darker image). 

 

[Old Bruce]

No. There are no values greater than 1 (255, 255, 255).

[London]

I don't know what you mean by there are no values greater than 1. With HDRs, there are values greater than 1. Sometimes much greater. Is it just that you can't select them?

[Old Bruce]

I don't know what it is that you are doing to get values over 1. You say "CGI generated files", all I can say is that 1 is the pure white and if you want more than that you will only ever get a value of 1. Think of the pixel as some container which holds exactly one liner of water, once you have 1000 ccs in it you cannot put more water into it, you can pour more water into the container but it won't hold more than one litre. 

Are there more than one file/layer in you document from the CGI generated files?

[lepr]

I would say that values over 1.0 being rendered as 0.0 is a bug, not something designed to be helpful to you.

[London]

1 is the highest value for 8-bit/channel images. For 32-bit/channel HDR values, there is no maximum value, just the way light has no maximum value. In computational photography, you can combine multiple photos to get how bright a white value is—something that's 255/255/255 at -10 stops would still be 255/255/255 in an 8-bit image at +10, but in a HDR image it would have a much, much higher value (I'm not sure what the actual value would be—I don't think it's as linear as +20. 

For modern rendering engines creating CGI images, you can save renders in 32-bit formats (usually EXR) that preserve light intensity, which is important for toning images to reflect the way our eyes see them.

[London]

Thanks, anon2. It probably is a bug, although a weird one in a program that has full 32-bit support with a built in OCIO workflow. I'd have expected it to come up in testing all the time.

[lepr]

17 minutes ago, London said:

Thanks, anon2. It probably is a bug, although a weird one in a program that has full 32-bit support with a built in OCIO workflow. I'd have expected it to come up in testing all the time.

Ha, you wouldn't believe some of the bugs that are getting through to the customer as if no testing at all is being done.

[carl123]

I'm sure I read an article about RGB values greater than 1 and they used the Procedural Texture Filter to manipulate them but I can't find it now.

Anyway, the following settings should set any RG or B value greater than 1 to 1

Not sure if it is of any use to anyone but it was interesting to play with

 

 

[London]

1 hour ago, carl123 said:

I'm sure I read an article about RGB values greater than 1 and they used the Procedural Texture Filter to manipulate them but I can't find it now.

Anyway, the following settings should set any RG or B value greater than 1 to 1

Not sure if it is of any use to anyone but it was interesting to play with

 

I haven't played with this, but this sounds great.one of the things I do with >1whites is add a bit of bloom. Usually making a mask for that involve duplicating the layer, setting the exposure very low, and manipulating the levels to get a clean selection. This sounds like a better starting point.

[R C-R]

18 hours ago, anon2 said:

I would say that values over 1.0 being rendered as 0.0 is a bug, not something designed to be helpful to you.

Just curious, but in what way should they be rendered that would be more helpful?

[lepr]

1 hour ago, R C-R said:

Just curious, but in what way should they be rendered that would be more helpful?

There should be toggleable clipping indicators as in Develop Persona.

[London]

2 hours ago, anon2 said:

There should be toggleable clipping indicators as in Develop Persona.

Give that the >1 renders as 0 in exported JPEGs, I'd rather it be white. Most of the time, that's not useful information and it spoils the image.

[lepr]

1 hour ago, London said:

Give that the >1 renders as 0 in exported JPEGs, I'd rather it be white. Most of the time, that's not useful information and it spoils the image.

Yes, rendering >1.0 as 0 instead of 255 in a JPEG has got to be a bug. I can't see that being useful to anyone. I didn't realise the problem is more than just a display problem. There should still be toggleable clipping indicators (with user settable thresholds) in the Photo Persona, though.

[London]

I haven't seen a place on the forums for bug reports. Is there a way to report this? 

[walt.farrell]

2 hours ago, London said:

I haven't seen a place on the forums for bug reports. Is there a way to report this? 

https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/

[James Ritson]

To clarify the information in this thread based off a subsequent discussion in another thread, it's most likely caused by using certain blend modes whose mathematics do not interact well with unbounded floats—typically yielding negative values.

An easy way to test this is to produce a 32-bit document with two rectangles that overlap. Set both rectangles to pure red, then increase their intensity—for example, increase one by +1 and the other by +2. You could use any float values here greater than 1, e.g. 2.54 and 5.43. Scroll through the blend modes on the top-most rectangle and you will quickly see which blend modes produce negative values: Screen, Overlay, Soft Light, Hard Light, Vivid Light, Exclusion, Subtract, Negation, Reflect and Glow. We've discussed adding warnings to these blend modes in the dropdown when a user is in 32-bit, and potentially clamping them as well, with the understanding that this would clip the unbounded value range.

@London your issue should be somewhat mitigated by using those Filmic transform macros I've provided, since all of the transforms will tone map to 0-1 range. Just place any composite layers with the problematic blend modes above the Filmic transform group and you should be good to go!

[London]

Thanks, James. Your support has been fantastic.

[London]

Hi @James Ritson, unfortunately, the 32-bit compositing bug isn't limited to Screen and Lighten. I didn't use your macros for an image I was compositing today (for reasons I forget) and ran into the problem using Add. Actually, every single color mode that lightens the image (Screen, Lighten, Color Dodge (not sure of the exact name), and Add) all produced errors. I'll go back and use your macro to fix this image, but wanted to make you aware of the issue. In the two screenshots, the lighter image is the problem-creating layer (which definitely has over-white highlights) set to Add over the other compositing layers. the darker image is it set to Normal mode. 

The 32-bit view is set to ICC and I used your double OICC transforms (Linear-sRGB + sRRG-Linear) trick in layers above this. I also forgot to turn off the black and white LUT stacked on top of that, but the glitch disappears when I turn this layer off.