Jump to content
You must now use your email address to sign in [click for more info] ×

Overexposed areas show black when overlayed - suspected bug


Recommended Posts

Attached beta project has one pixel layer with overexposed areas. These show as white. If I duplicate the layer and set overlay blend mode, the overexposed areas are shown as black.

The info panel shows them as 0,0,0,0.

Upon export to jpg, these areas remain black.

Same does not happen with 1.6.

overexposed.afphoto

Link to comment
Share on other sites

5 hours ago, Jeroen said:

Attached beta project has one pixel layer with overexposed areas. These show as white. If I duplicate the layer and set overlay blend mode, the overexposed areas are shown as black.

The info panel shows them as 0,0,0,0.

Upon export to jpg, these areas remain black.

Same does not happen with 1.6.

overexposed.afphoto

I can confirm that. But it only happens in 32-bit mode.

overexposed.jpg

iMac 2017, 16 GB RAM, Intel Iris Plus Graphics 640 1536 MB, MacOS Ventura 13.6.6 (22G630) - Affinity V2-Universallizenz 

Link to comment
Share on other sites

24 minutes ago, Jeroen said:

Ahh, thanks for that.

My pleasure. :)

iMac 2017, 16 GB RAM, Intel Iris Plus Graphics 640 1536 MB, MacOS Ventura 13.6.6 (22G630) - Affinity V2-Universallizenz 

Link to comment
Share on other sites

I understand this explanation in the sense that the mathematical formulae for overlay blending mode, when applied to floating point values, can yield negative values that then become zeros when converted to integer values, thus leading to black pixels.

In that sense, all is well. Mathematically, that is.

But I find it surprising, to say the least, that the apparent behaviour of an action like applying a layer blending mode could be radically different depending on whether I work in 16 bits or in 32 bits. Of course there would be differences, but I would expect those to be related to precision (banding, etc.). Not to white pixels to suddenly becoming black.

Mathematically speaking, the algorithms used in 32 bits should be a close approximation to those used in 16 bits, only more precise. And the conversion from floating point to integer should also be as perceptually faithful as possible. 

So, regardless of the explanation how it happens, unless someone convinces me otherwise, I consider this a bug.

Link to comment
Share on other sites

You are right, my formulation was imprecise. And you are correct in your response.

But I stay by my opinion: overlay blending is done incorrectly in 32 bit photo persona. Let me try again.

Suppose I have a raw file and develop it twice: once to a 16 bit image, and also to a 32 bit image, These images will be very close in appearance.

From you, I understand that in the 32 bit photo persona, the values are internally represented as floating points, not 32 bit integers. Fine. With 16 bit, they are certainly integers.

Now suppose I perform the same user action on both, similar, images. In my case, applying overlay blending. This rests on a well defined mathematical formula, which is independent from precision or from integer vs. float considerations. I therefore expect that the results will look similar as well. But that is apparently not the case.

Which is what I consider a bug. As argued below, the 32 bit implementation simply does not achieve its goal: overlay blending. It is in error.

By extension, I would like to formulate the following design principle: in all cases the user should be aware that choosing between 16 bit or 32 bit in the Develop Assistant might  impact precision in the final image. But s/he should also be confident that other than that any operations on the image will have similar results.

This is an opinion, but a very reasonable one in my view. I would be interested to hear arguments to the contrary.

In any case, the current implementation violates this design principle.

===

The following elaborates my statement that "algorithms used in 32 bits should be a close approximation to those used in 16 bits, only more precise". Which does not really identifies the problem,  as you point out.

But that does not mean that all is well. Let me summarise conceptually the steps taken during editing with overlay blending, as I understand them.

- in 16 bits blending this translates into a transformation from an array of 16 bits integer values to another array of 16 bit integer values. These arrays in turn are rendered on a screen or on paper. This will normally go via an intermediate step where an 8 bit RGB array is generated. 

- in 32 bits it is different. Values are represented as floating point, not as integers. Very well. It gives much more precision, especially with many operations in a chain. At the point of rendering, there will be a conversion to an integer array. Whether these are internally 32 bit or 16 bit I don't know, but that is immaterial to the discussion. In either case, in the end 8 bit RGB is again generated for display or printing. For precision, calculations take place as long as possible in the floating point realm.

Now to the problem at hand. It is the task of the implementation to realise overlay blend mode. There is a mathematical formula for that. Taken from Wikipedia (https://en.wikipedia.org/wiki/Blend_modes#Overlay): 

f(a, b) = 2ab if a < 0.5

f(a, b) = 1 - 2(1-a)(1-b) otherwise

where a is the base layer value, b the top layer value.

These formulae are independent of representation as integer or floating point values, or of bit size. Any real implementation will be an approximation. A good implementation makes the approximation mathematically as close as possible given the circumstances.

If, therefore, the 32 bit implementation of overlay blending gives very different results from the 16 bit implementation, one of the two must be at fault. And it is obvious in this case that it is the 32 bit implementation.

Technically, the problem appears at the point where conversion to integer takes place. Either that conversion must take into account what floating point has done to values that is significantly different from what integer does, or the implementation of floating point overlay transformation must be adapted to the integer conversion algorithm. Or both.

Bottom line: Overlay blending is done wrong in 32 bit photo persona. This is not necessarily due to either the way floating points calculations are done for overlay blending, or to the way floating point  is converted to integer, but to the interplay of the two.

Link to comment
Share on other sites

1 hour ago, >|< said:

I already told you that the app has only one implementation of Overlay blending; that is a floating point maths implementation regardless of a document having integer format or floating-point format.

Perhaps that is the problem?

Windows 11 Pro, XP-Pen Deco 03, AP, AD & APub

Link to comment
Share on other sites

8 minutes ago, >|< said:

No, the problem was that brighter than white pixels were being Overlay blended. There's a solution in the file that I posted.

What I was getting at was that perhaps a different algorithm should be used in cases where the problem occurs, such that these puzzling issues do not occur.

 

Windows 11 Pro, XP-Pen Deco 03, AP, AD & APub

Link to comment
Share on other sites

Sorry >|<, but Casterle is right. 

You keep saying that the behaviour is a consequence of the way the function is implemented. I get that. But the point is, that this implementation does not result in a proper overlay blending as is generally defined (and as is realized in the 16 bit implementation).

The only conclusion from this, is that the 32 bit implementation is faulty. There is no other way of looking at it. To be very specific: if you look at the formula I quoted, you find that if you overlay-blend an image with itself, all white pixels come out white again. In my 32 bit example, they come out black. That is wrong, period.

Since you tell me that this also occurs in 1.6 with 32 bit, and thank you for that, apparently this is a bug in 1.6 as well. I will log it as such in the proper forum.

Link to comment
Share on other sites

7 minutes ago, >|< said:

I guess it wouldn't be difficult to change the software so that it automatically clamps values to the range 0.0 through 1.0 before passing them to the existing Overlay blending function.

Let's hope it's that simple. Anyway, I will log it and we'll see what happens.

Link to comment
Share on other sites

A workaround to me is not a solution.

There is, I think, nothing I can further say that might convince you. So unless something new comes up, I will close this discussion, file the bug, and move on. Thank you for your particiiation.

Link to comment
Share on other sites

My apologies if I angered you. I myself felt annoyed that you seemed to keep denying my position that there is a real problem in the software, without addressing my arguments. This might have coloured my replies in turn. Sorry again if that angered you. Perhaps it was all miscommunication.

To be clear, my posting was not so much to ask for a way around the practical problem how to deal with a faulty implementation, but to alert Serif to a possible issue with their beta software. After all, that’s what beta’s are for. That I now, thanks to you, know that the same issue exists with 1.6 makes it all the more relevant.

You suggested a practical way for me around the problem for now, and thank you for that. For myself, the simplest solution is to stick to 16 bits until the problem is solved. I can live without 32 bits.

Thanks again, and no hard feelings I hope.

Link to comment
Share on other sites

  

14 hours ago, >|< said:

I get the same blackened result from 1.6.7 and 1.7 beta.

Are you sure about 1.6.7? I don't see it with my file on 1.6.7, 32 bits (MacOS). All concerned pixels are white, as they should be.

Before I log a bug with 1.6, based on your statement, could you provide an image where you see the problem with 1.6.7?

Link to comment
Share on other sites

3 hours ago, >|< said:

The file I posted earlier opens in AP 1.6.7 and 1.7.0.125. If you disable the white Fill layers, the composite has the same blackened and cyan areas (with negative colour component values, as there should be, according to the formula for Overlay blend) in both apps.

compare.thumb.png.dd29fa1b01ad30fbf28ab57d2409d02c.png

 

986007087_overlayformula.png.b288bd2b9b7f94bc9b69d2412b1b4b04.png

Overlay blending one of your RGB(1.73, 1.73, 1.73) overexposed pixels that is almost twice as bright as white (RGB(1.0, 1.0, 1.0)) with itself:

f(1.73, 1.73) = 1 - 2(1 - 1.73)(1 - 1.73) = -0.07

The result is RGB(-0.07, -0.07, -0.07), which can be sampled in the composite, and that becomes black RGB(0, 0, 0) when converted to integer format for display or export.

Thanks, that clarifies a lot. I did not realise the answer was in your file all the time. Clever to use a regular white filled mask with Darken blend mode to clamp to regular white. And it confirms that, indeed, 1.6.7 has exactly the same problem in 32 bit development.

But I think you apply the formula too hastily. The formula expects all values to lie between 0 and 1 to start with. From the same Wikipedia page:

"In the formulas shown on this page, values go from 0.0 (black) to 1.0 (white)".

This means that all values should first be normalised to lie between 0.0 and 1.0, before the formula may be applied. A value like 1.73 should not be used. No negative values can then ever be generated, and, in fact, white remains white:

f(1.0, 1.0)  = 1.0 - 2(1.0-1.0)(.01-1.0) = 1.0.

Now, I have no idea how Serif maps the internal 32 bit floating point pixel representations to normalised values between 0.0 and 1.0. Nor do I know how the demosaicing algorithm assigns those floating point values to pixels in the first place. I assume all raw development programs have their own way of doing that, with slightly different results. A trade secret, if you will, and very camera dependent.

I am doing some experimentation to get some grip on what is really going on behind the screens. For that I need some kind of idea what the floating point representation of a pixel is. You might help me with that: Where do you see that my white has RGB value 1.73,1.73,1.73? That must be related to its floating point value. In the Info panel I see only the regular 8 bit RGB values, which are 255,255,255. And those values do not change after application of the fill layer. So that tells me nothing. But this must be too coarse a way of looking at it, since the floating point representations must be different or your approach would not work.

So, where do you find that my white RGB pixels are considered 1.73,1.73,1.73 over-white, instead of 1.0,1.0,1.0 regular white?

Thanks for you help.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.