Overexposed areas show black when overlayed - suspected bug

[lepr]

.

[Andy Somerfield]

Afternoon,

An interesting discussion - and one which has been had here a few times. A number of blend modes will exhibit the behaviour you describe - not just Overlay.

Other applications which deal with 32bit data usually choose to disable these blend modes in 32bit documents - which makes sense, to a certain extent. We initially planned to do the same.

That said, 32bit mode does serve two distinct purposes: a.) Facilitate compositing with values > 1.0 and < 0.0 and b.) Providing immense, dynamic precision - far beyond what 16bit ushort can deliver.

Some users need a.) - and for those people, the Overlay blend mode makes no sense and looks like a bug.

Users who need only b.) - whose data is always between 0.0 and 1.0 - will happily use Overlay and no problem will manifest.

 

The solution to this, in my mind, is to simply clamp inputs to any offending blend mode to the 0.0 - 1.0 range. This has no consequence for b.) users - but a.) users who mistakenly apply Overlay would lose out-of-bound values - which would break their workflow. I think that if, when in 32bit mode, we showed some sort of yellow warning triangle next to blend modes which will clamp we could find a happy medium - a.) users would be aware of the clamping and b.) users can still use all the blend modes.

 

Thanks,

A

 

[lepr]

.

[Jeroen]

23 hours ago, >|< said:

It would be appropriate to clamp input to the Overlay function to that range, not normalise it, in my opinion.

I now agree. With help of your tip on viewing floating point values I gained a better understanding of 32 bit unbounded editing, and this is indeed how it should be done.

23 hours ago, >|< said:

The software does not perform such automatic normalisation. Values outside of that range are allowed.

Understood.

So, the value range in 32 bit is unbounded and the software displays from that range whatever lies between 0.0 and 1.0. The rest is visually mapped either to black (0,0,0) or to white (255,255,255). But internally everything retains its proper value, so that when you shift the values, as you can do in the preview panel, they come to life again if they then fall in the displayable range. I hope I get this right now.

Also, "invisible" values still influence all kinds of mathematical operations, such as layer blending. This can make for surprising, but very interesting effects.

So, 32 bit editing is actually a very different beast from 16 bit editing (which, by the way, according to James Ritson (https://www.youtube.com/watch?v=UOM_MmM4rvk, 0:22) is based on integer representation of values, not floating point. Perhaps intermediate calculations are done in floating point to avoid cascading of rounding errors, I don't know). Naively, one might think that 32 bit is about better precision, which might be useful in some cases. But much more importantly, other than 16 bit it keeps lots of information that is invisible but still, in principle, could influence operations you perform on what is visible. Weird but interesting.

Having said that, I still find it very misleading that Serif has chosen the same name for operations in 16 bit or 32 bit, respectively, that actually are very different in their visual outcome. I can see that one can take the position "the formulas are equal, therefore we call it the same". But is it unreasonable that a user, seeing the same name of the operation in 16 bit and 32 bit UI's, virtually indistinguishable, expects the results of applying it also to be close to one another? Especially where this operation has a generally (also outside of AP) recognised purpose, namely, to achieve a certain visual effect (a contrast enhancement in the case of overlay blending).

I would not want to argue that for example, overlay blending should clamp the values beforehand in every situation. Keeping them free  can create very interesting effects, and why forbid those? But (a) it can confuse the user who might expect an effect he is familiar with and (b) it forces a work around such as your extra white layer if the user wants to achieve that effect in the first place.

 if I could make a suggestion, it would be along the lines:

- Amend the name of the 32 bit operation to, for example, "(un)bounded overlay" instead of just "overlay". This communicates a gentle warning to the user. An optional information panel to explain the situation might also be nice.

- Create a setting on the operation to choose for "clamp to visible", as per your suggestion. There could be a global default setting, but it should in any case be settable per individual operation. An extra white clamping layer would then not be necessary.

Clamping may have undersirable side effects. The invisible information is gone forever. (Actually, not necessarily. In theory, after calculation of the new visible range using the clamped values, the invisibles could be "unclamped" again. That could have interesting but difficult to grasp ramifications, I think.)

There could be ways to deal better with it. One of the things I wished there were in 32 bit, when I was experimenting, is a filter to apply a value shift to a layer. At the moment, I can use preview to see the effect of value shift, and thus change what is displayed, but that seems only to impact the visual and not to have a lasting effect. I would like to be able to apply it as a filter in the layer stack. Thinking further, there could even be a curve to map values to values. Whatever comes out between 0.0 and 1.0, will be displayed with that value. Outside of that, it will be displayed either black or white. Then your white "clamp" layer could be replace by a "clamp to visible" filter.  Looks interesting to me, but needs further thought. BTW, you do not know of such a value shift filter, do you? I could not find it.

Thanks for listening to theses ramblings, and I would be interested in your views.

 

[Jeroen]

On 5/19/2019 at 2:24 PM, Andy Somerfield said:

Afternoon,

An interesting discussion - and one which has been had here a few times. A number of blend modes will exhibit the behaviour you describe - not just Overlay.

Other applications which deal with 32bit data usually choose to disable these blend modes in 32bit documents - which makes sense, to a certain extent. We initially planned to do the same.

That said, 32bit mode does serve two distinct purposes: a.) Facilitate compositing with values > 1.0 and < 0.0 and b.) Providing immense, dynamic precision - far beyond what 16bit ushort can deliver.

Some users need a.) - and for those people, the Overlay blend mode makes no sense and looks like a bug.

Users who need only b.) - whose data is always between 0.0 and 1.0 - will happily use Overlay and no problem will manifest.

 

The solution to this, in my mind, is to simply clamp inputs to any offending blend mode to the 0.0 - 1.0 range. This has no consequence for b.) users - but a.) users who mistakenly apply Overlay would lose out-of-bound values - which would break their workflow. I think that if, when in 32bit mode, we showed some sort of yellow warning triangle next to blend modes which will clamp we could find a happy medium - a.) users would be aware of the clamping and b.) users can still use all the blend modes.

 

Thanks,

A

 

Only now saw this reply... thank you for taking notice.

I just made a reply to >|<, and you might refer to that. Following is a brief excerpt.

In that post, I take the position that (a) a gentle renaming would help, (b) an information panel would be excellent, and (c)  clamping should perhaps better be made optional, rather than doing it automatically. Coming to think of it, (b) in itself might obviate the need for (a).  Speaking for myself, being primarily a landscape photographer, I am not normally into special effects, but when I experimented with 32 bit overlay blending I achieved some spectacular effects which I liked a lot. I would not block that road forever.

Another issue is that clamping destroys a lot of information. The reason for 32 bit is just to have that information available when and where you want it. Pity to lose it.

One idea might be to optionally "unclamp" after your operation, let's say blending. All pixels that are outside the visible range after blending would then revert to their original value,  at least if that also was out of bounds. The ramifications of that can be difficult to grasp intuitively, but in my view, so are many mathematical operations anyway. I can think of variations on this theme.

Thanks again, and congratulations with all the fine work you are doing.

[fde101]

1 hour ago, Jeroen said:

clamping should perhaps better be made optional, rather than doing it automatically

Agree with making it optional (checkbox), though probably enabled by default, as based on this discussion the vast majority of cases would want it turned on.

[lepr]

.

 

[Jeroen]

59 minutes ago, >|< said:

The exposure adjustment in the 32-bit Preview panel scales the pixel values of the view composite. There is an adjustment layer named Exposure which similarly scales pixel values of the underlying document composite.

Of course! Thanks.