Halftone Live Filter with wrong (?) assumptions on borders

[ndr42]

• If I have a (unfilled, transparent) pixel layer with some lines drawn in different grays
• above I have a live filter with halftone set to point

+ This results (as wanted) in different dense point halftone rasters where the lines are on the layer below

- But the border of the lines are darker, it seems that AP treats the transparent areas as black and so the borders are darker (this is not seen on lines with a smooth border, on the righ topt on the picture are some)

- You can see this effect also when you fill a layer below the live filter completly white -> you would assume that you will geht no halftone points but on the margins of the page you get a darker border, as if AP uses black as an outside border that bleeds into the halftone layer

= The correct behavior (or the one that I would like) is that no transparent or outside areas affects my lines

(I try to replace Clip Studio Paint where I use halftone layers in my comics)

I hope my point is understandable, if not please ask.

It would be nice to hear from somebody at affinity if the behavior is intended.

I attached two screen, the first with halftone live filter layer disabled, the second enabled.

Greetings

Nils

 

Edited December 25, 2022 by ndr42
spelling

[NotMyFault]

Hi Nils,

your observations are correct, i can reproduce this.

This behavior seems unwanted in this case, but it is the default way how Affinity deals with transparent areas: the color is interpreted as black. The same logic happens with all filters. We have the “protect alpha” option for most filters, but it wont help.

To get your desired result, i suggest the following workaround:

1. duplicate pixel layer (you can use duplicate linked).
2. create a rectangular shape, color white
3. nest the lower pixel layer to the white rectangle
4. add the halftone filter, nest it to the rectangle
5. nest the rectangle as child to the copy of the pixel layer

in essence, this uses a white backfill layer, and then the pixel layer as mask.

PS: Thi still will cause Wong colors e.g. for black strokes. see my nest post for better solution.

Edited December 26, 2022 by NotMyFault

[NotMyFault]

 

To get a most accurate result, another approach could be used.

 

1. For every stroke colour, create a rectangular shape in size of the document, and set the colour
2. Add a halftone filter as child layer (except for pure black and pure white)
3. add an empty mask layer
4. now paint on the chosen mask to make strokes visible

This will give you perfect halftone strokes without any false colours impacting the edges.

 

[ndr42]

Thank you NotMyFault!

Your suggestions seem to be good workarounds for special cases with no gradients in the raster – I have checked my doodles and it seems that in +90% I use just a single color for shadows so it really helps.

Regarding the default behavior of AP: "transparent = black" I'm not happy. 100% transparency or the border of the page should not be influencing the color of something.

I understand where AP is coming from (I imagine that hardware acceleration is quite effective if you are just iterating in blocks over the canvas without detecting edges to transparent areas, if its too computational intense you wouldn't have a live filter) but regardless would like Affinity to change the behavior.

[NotMyFault]

I understand and share that you expect a different behavior. But this is no bug, it is how the developers designed it to be.

You can file a feature request in the feedback section of the forum, i will probably add my vote.

[NotMyFault]

1 hour ago, ndr42 said:

for special cases with no gradients in the raster

It expect it will work with gradients too, if you are able to create an edge (outline) of sufficient with for the halftone raster size. Do you have an example where it doesn't work?

The basic challenge for halftone filters is: the visible areas depend on colors of neighboring pixels. In case of fully transparent areas there is no way to decide about what color to use. My workaround provides suitable colors for the areas which later become transparent by the mask. Affinity has no function to extend patterns inside pixel layers into transparent areas. You may try filters like maximize, gaussian blur etc, but the results are disappointing.

[ndr42]

5 hours ago, NotMyFault said:

It expect it will work with gradients too, if you are able to create an edge (outline) of sufficient with for the halftone raster size. Do you have an example where it doesn't work?

I was referring to your second workaround where you use distinct colors/gray levels that are represented by the halftone-raster, because of the multiple layers (each with their own live-filter) I assumed that it would not be possible to blend them smoothly into each other. This workaround would still be good for the majority of my doodles, as I like a more stylized loo with just a small number of gray levels.

Your first walkaround looked as if would work to blend between the gray levels.

My own workaround is visible in my screenshots - there are hidden layers with pure white, black and 50% gray where I was trying to migate the "border-problem", if I set the background to white I have no transparency and then no black border.

It is certainly possible to achieve the desired outcome in AP but often the nested layers and complicated setup is hindering my workflow. I don't know if you are familiar with Clip Studio Paint: It removes (as a more specialized app, I presume) all friction: you can switch every layer (regardless if vector or pixel) to halftone, so you need just 1 layer and no masks, live-filter at all - so easy, that it doesn't hinder creativity. (I just want to get rid of it because of the subscription model that is coming)

6 hours ago, NotMyFault said:

I understand and share that you expect a different behavior. But this is no bug, it is how the developers designed it to be.

You can file a feature request in the feedback section of the forum, i will probably add my vote.

I think you're right – I fear its the the worst outcome: No bug in the technical but the artistical sense and not a feature that would be a priority... 😞

I will file a feature request.