Selection System Bug - Lines are Generated in Selection - AP 2.3.1

[Grimlock]

Hi, I'm having a problem resulting from a bug in your selection system. As I make a complex selection, then make adjustments to it, grow, feather, and such, there is a miscalculation bug and faint lines are generated. The lines are damaging my work. I'm producing height maps for game world creation. The error is seen when the height map is rendered in 3D. This is fairly easy to recreate, it's just a selection, then I'm using other methods on top of the selection such as layer adjustments and the issue happens. This was probably never noticed because most users don't need accuracy like I do. This is for a VR environment and the lines are visible and look pretty bad in VR. It's going to add a lot of work to remove them and not ruin my slopes.is is probably a simple math error in the code or something like that.

[NotMyFault]

Those lines are most probable caused by one of these issues:

• selection with feathered edges. Partial alpha leads to color „jumps“ at the edges
• pixel position alignment issues (fractional position) This can create again partial alpha and mixing of colors from different layers at the edges
• impact of adjustment layers with masks. Masking adjustments can lead to jumps and edges of masks.
• forgetting to deselect all after creating an adjustment layer (which inherits selection as mask). This can impact further edit steps to selected area, sometimes not intended.

it is very hard work to avoid those issues, and needs constant verification for every step. We would need one example file with the exact steps (saved with history) to investigate deeper.

 

[NotMyFault]

You raised a similar report in the past - can you give an update there if the issue is resolved?

 

[NotMyFault]

17 hours ago, Grimlock said:

This is fairly easy to recreate, it's just a selection, then I'm using other methods on top of the selection such as layer adjustments and the issue happens.

Please elaborate the exact steps, including all files. 
if possible create a simplified file:

suitable area of source file, copied and rasterized and trimmed to get small file.

 

[Grimlock]

I'll create a sample file for you. Can you provide instructions of saving the history steps?

[Old Bruce]

1 minute ago, Grimlock said:

I'll create a sample file for you. Can you provide instructions of saving the history steps?

File > Save history with document.

[Grimlock]

Regarding the previous post, no. I still get different values when I pick up colors in a 16 bit greyscale image. The info window says one thing and the color window says something else. It makes certain works more difficult but I've found work arounds. I have to avoid precision work and use other methods to achieve my end goals. It would be great if you guys could enhance the ability to work with 16-bit greyscale images. Specifically if you could get the info panel to be accurate that would be really nice!

[Grimlock]

Thanks, I'll create the file in the next few days, I'll also provide a link to an app you can use to see the results for yourself. A free height map rendering app.

[Grimlock]

I apologize for the delay, got very busy but I have the file now and some images rendered in Aerialod (Height map renderer) to show the result. Aerialod is a free app, if your programmers would like instructions on how to use it to check for this bug, as a testing process I can explain.

This is a process I use a lot to smooth surfaces up to larger objects, like sand near rocks or a cliff face. In this case, it's creating some islands and then ramping up the edges with a feathered selection and levels adjustment layer. It creates the ramp around the entire set of islands that will later become beach in the game engine when textured and water is rendered.

You can see that something is happening to damage the results. This happened in my previous project and it took a few days to clean up the damage.  I hope this helps you all sort out the bug. I'm really enjoying using the affinity set of applications and I've gotten several other game content developers to pick up the software. I'm teaching others how to craft height maps using Affinity Photo and Designer in unison. I appreciate all your hard work!

Selection and Feather Issue.afphoto

[NotMyFault]

thank you for providing the file.

I can confirm that in the file you provided both the active selection and the inherent mask of the adjustment layers show those lines with small intensity deviations. 
 

But it really depends on the method how you create and manipulate these selections.

the lines are not present in the earlier steps (before move step).

what does the move step do? I can’t see any change in layer position, it seems superfluous. 

 

why do you work with selections and feathering in the first place? 
 

[NotMyFault]

I can confirm the feathering step is causing the unwanted lines.

i tried to replace the feathering step by quick mask mode and a Gaussian blur of 8px.

interestingly, this blur caused a weaker but still noticeable issue with lines.

so root cause seems to be blur (feather is another kind of blur action) is causing small errors in lightness for grey/16 documents.

 

grey16 blur bug.afphoto

[NotMyFault]

Affects live and destructive blur filter.

Affects grey/16 and rgb/16 color mode.

steps to reproduce:

1. create new rgb/16 document 
2. add pixel layer
3. fill with black color
4. choose paintbrush, white color
5. paint some white areas
6. add levels adjustment 
7. set white level to 0%
8. zoom to 100%
9. use destructive Gaussian blur with 8px radius 

tested on iPad M1 with 2.4 beta and retail.

Artifacts are visible even after merge visible.

[NotMyFault]

After experimenting a bit more, the issue is probably a rounding issue in less significant bit. In case you have an area with strong contrast, Gaussian blur may create ghost pixels in the distance which corresponds to the blur radius, starting at about 6px. Those ghost pixel propagate downwards (similar to game of live). After some distance they may stop further propagating.

To make this visible, a need to add levels adjustment which boost the lightness by factor ~10.000. this is about 32*256 or bit 12/13. Maybe Affinity is limited to 12 bit numeric precision (for certain filters only). There are other functions not working with color depth beyond 8 bit, e.g. screen rendering is currently capped at 8 bits resolution for any 16 bit document format.

i really don’t know if you can call this a bug or by design. For regular edit jobs this an irrelevant rounding issue. For your highly specific use case it is absolutely relevant - but then you may need to take it as by design functional limitation and adjust your workflow around this.

Hope that moderators step in and give an official statement.

 

[NotMyFault]

One way to avoid seems to use 5px blur radius as maximum.

If you want more blurriness, repeat multiple rounds of 5px radius blur. Not the same, but maybe ok for your workflow.

[Grimlock]

On 3/8/2024 at 4:26 PM, NotMyFault said:

thank you for providing the file.

I can confirm that in the file you provided both the active selection and the inherent mask of the adjustment layers show those lines with small intensity deviations. 
 

But it really depends on the method how you create and manipulate these selections.

the lines are not present in the earlier steps (before move step).

what does the move step do? I can’t see any change in layer position, it seems superfluous. 

 

why do you work with selections and feathering in the first place? 
 

I use a feathered selection as a way to apply the lift I needed to pull terrain up at a gradual rate, up against other objects. In this case, it was to create a uniform coastal beach along the rim of the islands. It worked excellent other than the lines created. 

The move, I'm not sure, I may have bumped the mouse button, but not enough to move anything.

Personally, it feels like a bug. Users should be able to feather a selection and make adjustments without adding unintended oddities to the results. Hopefully it gets some attention, or some kind of explanation.

Thank you for your efforts @NotMyFault 

 

[Dan C]

Apologies for the delayed response here!

On 3/8/2024 at 10:51 PM, NotMyFault said:

steps to reproduce:

1. create new rgb/16 document 
2. add pixel layer
3. fill with black color
4. choose paintbrush, white color
5. paint some white areas
6. add levels adjustment 
7. set white level to 0%
8. zoom to 100%
9. use destructive Gaussian blur with 8px radius 

I can confirm I've been able to replicate this issue here - it appears to be a Metal rendering bug as I cannot replicate this on macOS with Metal Acceleration disabled. Therefore I'm getting this logged with our development team now.

With the same file/workflow on Windows, ensuring Hardware Acceleration is enabled, the Levels Adjustment is not correctly applying the 0% white level value, so I am logging this with the team also - however the 'corruption' shown on macOS is not present on Windows at any time.

However, as I understand it, the OPs report is using Windows and not macOS, so I'm unsure exactly how the above bug is relevant to their selection issue.

 

@Grimlock, unfortunately I don't fully understand your exact workflow in Affinity currently - even with the file you've provided.

Out of interest, if you navigate to Edit > Settings > Performance and untick Hardware Acceleration, then restart the app as prompted and try creating/feathering your selection once again, does the same issue still occur?

If so, are you able to outline the exact steps you're taking, so that I can reproduce this here and log it with our team?