Halftone filter in Photo creates tiles

[Bebebebenny]

What the subject says — adding a halftone filter in Photo creates an ugly repetitive tiling pattern that is clearly visible and draws attention from the image as a whole and to the effect instead. 

I first assumed this was on-screen only, because zooming on screen removes the tiling on some zoom levels.
However, exporting it (or copy-pasting) will reintroduce the tiles, regardless of screen zoom level at time of export.
In a jpg or similar, the tiling pattern will be ingrained in the saved image.

This takes place on an M2 Mac with Sonoma, Affinity 2.4
Example screenshot (detail): 

/B.

[NotMyFault]

Can you uploead the actual file?

[Bebebebenny]

Warning: Potential motion-sickness-inducing image below

I can't upload that very file for client/work-related reasons, but I can create a new one (this is highly reproducible to me) with just a gradient that shows the same issue.
Detail in screenshot, entire file below.

As far as I can tell, this is probably a rounding error in the filter, that semi-regularly makes it position the next screen dot a full pixel too far away from its sibling. I say semi, because in the screenshot below, about a third from the right, there are two columns that are just one screen dot wide until the next "grout" between tiles.

raster-filter-creates-tiling.afphoto

[NotMyFault]

Well - the choice/combination of parameters with extremely small cell size of 6px and cosine mode may show the limits of the current algorithm. Getting heavy artifacts from halftone filter is kind of expected.

This is the reason why you can tune the angle, this is intended to minimize those artifacts.

By design in my view, lets see what the moderators decide.

https://en.wikipedia.org/wiki/Halftone

These angles are optimized to avoid patterns and reduce overlap, which can cause colors to look dimmer.

[Bebebebenny]

57 minutes ago, NotMyFault said:

These angles are optimized to avoid patterns and reduce overlap, which can cause colors to look dimmer.

I'm sorry but no, not at all — that quote relates to 4-color separation, where the angle of screen dots are positioned so as to not create interference with one another.
It has nothing to do with the single matrix of dots that the halftone filter applies to the page; a single pattern of dots cannot create interference with itself.

Even so, you are in fact correct that changing the angle to 120° rather than 45° (or any 90° offset thereof) does provide a workaround where the tiles/canals disappear.
This leads me even stronger to believe that this is a rounding error where what should be integers are allowed to become computer-error floating numbers of almost, but not quite, something-point-zero.

So —
Workaround found: Do not use angles that produce perfectly horizontal/vertical lines (nor perfectly diagonal, as it happens) as this will introduce canals between dots.
Bug found: See workaround.

Also: Arguably, this bug does not go away at larger dot sizes — the 1px canals are just comparatively smaller and less visually noticable. 

 

[NotMyFault]

1 hour ago, Bebebebenny said:

I'm sorry but no, not at all — that quote relates to 4-color separation, where the angle of screen dots are positioned so as to not create interference with one another.
It has nothing to do with the single matrix of dots that the halftone filter applies to the page; a single pattern of dots cannot create interference with itself.

Disagree. It is not bound to 4 color, and happens for 1 color as you actually observe in your example.

I did not found any better reference, but it is absolutely common knowledge that halftone creates moirés patterns and the angle parameter (which is available for monochrome patterns and not reserved to 4 channel) is the way to go. 

I have no interested into having a heated or endless discussion, so I step out of this thread for good.

[Bebebebenny]

1 hour ago, NotMyFault said:

I have no interested into having a heated or endless discussion, so I step out of this thread for good.

That is an unfortunate choice since you are — in good faith, I'm sure, but nonetheless — providing misleading information here. I have worked with printing and publishing since the end of the photographic reproduction era in the early nineties, and can inform you that you are conflating things. This is nothing to be upset about; rather than dismissing a chance to learn as "heated and endless", continuing this conversation might help us both arrive at some knowledge about why my issue with the halftone filter appears in the first place.

First of all, a moirée is the result of two patterns interfering. A lone, evenly distributed pattern cannot produce a moirée. Indeed though, a one-color halftone may still result in interference if the image itself has an inherent pattern with which the screen pattern might interfere. But my provided smooth gradient does not have one, so there is no basis for moirées to happen. The halftone screen has nothing to interfere with.

Instead, we need to look at why the canals happen as a result of the dot matrix itself. To even further dismiss any other source of the error, let's take the gradient out of the picture, and apply a 45° (or 90°) halftone screen on top of a completely solid color. If we do, we will still see canals appear repeatedly between dots. Screendump below.
The distance between those canals will change depending on the chosen dot size — also, the relative width of canals-compared-to-dots will shrink the bigger the dot size, thus becoming less and less noticable — but there will always be a periodically recurring 1-pixel difference between the centerpoints of dots. 
This implies that as the filter lays out the pattern of dots, it reaches a point where the accumulated sum of all dot-to-dot distances-so-far has reached a threshold where rounding pushes us a full pixel ahead. (If I'm right about that, my previous suspicion about a floating point error is probably wrong; rather, it is probably simply a case of unfortunate rounding, along the lines of n x 0.51, where n = 4 produces 2.04 ≈ 2.0, but n = 5 results in 2.55 ≈ 2.6, suddenly giving us a delta of 0.6 where previous and subsequent four deltas are 0.5)

Looking forward to hearing from the developers about this.

 

[loukash]

Cell size "6" at 0° angle is an area of 6×6 pixels.

But by rotating the angle, you cannot rotate the actual pixels. Those will always remain at the right angle. The rotated pattern thus will become irregular, causing a kind of moiré. That's the sheer nature of pixels.
Pixels, not dots.
(If anything, blame Serif for misleadingly using the term "DPI" rather than the factually correct PPI. )

If you need a finer pattern at 45° angle, increase the cell size value.
If your image doesn't have enough pixels for a smooth monochrome cell size of, say, 24, resample the image to 1200 ppi to interpolate more pixels.

This is a very similar scenario like when we use 1200 ppi images to get a sharp print of graphics or logos. As opposed to photos where 300 ppi will suffice for standard offset or digital print.

[Dan C]

Hi @Bebebebenny,

Thanks for your report!

I do not mind admitting that I'm not personally technically knowledged enough in this area to directly confirm if this is a bug, or expected behaviour when using the Halftone Filter with the settings shown above.

However, I can certainly understand why you would believe this to be incorrect based on the rendered results, therefore I'm getting this logged with our development team for further investigation and consideration as to how this filter should react, given the settings provided.

I hope this helps

[Bebebebenny]

16 hours ago, loukash said:

Cell size "6" at 0° angle is an area of 6×6 pixels.

But by rotating the angle, you cannot rotate the actual pixels. Those will always remain at the right angle. The rotated pattern thus will become irregular, causing a kind of moiré. That's the sheer nature of pixels.
Pixels, not dots.
(If anything, blame Serif for misleadingly using the term "DPI" rather than the factually correct PPI. )

Although aaactually, for dots in a halftone screen the term should be "LPI" for "lines"...  

Seriously though, that's a very good point! Pixels can't be rotated — can't argue with that — and while I'm not sure that in itself holds the full answer to the riddle (I spent far too much time thinking about this yesterday) it definitely points us in the right direction. Or perhaps I'm just saying what you're saying but in different words. Here goes:

Since the cell size, as you point out, is 6x6 pixels, when rotated, that 6 pixel length becomes the hypothenuse of an imaginary triangle, whose base is the actual width of the x-axis repeition. At 45°, that repetition will happen at √(6^2÷2), because Pythagoras, which is ≈ 4.24.
Now, my guess here is that this fact, in itself, wouldn't have to cause any canals if the pattern was drawn in memory first, then rotated, then put on screen. Or at least, in my mushy morning brain, canals would then at least appear diagonally. But unless I'm wrong, the canals we're getting imply that the filter will create and rotate the cells one by one in memory, then repeat those cells on the canvas at their mathematically correct positions in document space. Which presents a problem, because we are now positioning cells at non-integer coordinate points, rounding those anchor points off to the nearest full adressable pixel. I could be wrong about that, but the rest of the reasoning applies anyway:

As a result, stacking 4.24 pixels wide cells next to each other, in a non sub-pixel way, will result in a leap-pixel after three drawn cells (the first two will be rounded down to start drawing at 0, 4 and 8 pixels from the left respectively but the fourt will be rounded up to pixel 13) and then at slightly shifting intervals as we keep accumulating cells and find ourselves rounding up and down as we go. This correlates very nicely with the pattern I experience.

If I'm right about this, this is not a question about moirée/interference, nor about rounding errors per se, but about an unfortunate combination of non-subpixel rendering and subpixel maths. 

The solution then, is unintuitive at first glance: Never use perfect integer numbers for the cell size unless at perfectly horizontal or vertical screen angles.
Instead, for all other angles, set the cell size to the closest value that, given your screen angle, will be the hypothenuse of a triangle whose x-axis will be an integer.
In my case of a 6 pixel cell at 45°, instead chosing 5.657 seems to produce a reliable, gap-less pattern.

I fully realize I'm spending far too much thinking about a filter that's probably quite rarely used, but at least I found what I think is an answer. But even so:

Might it be good to have the filter let you set the x-axis baseline width for cells rather than the cell size itself?
So as to not confuse users like me, who assume that integer pixel numbers will produce the least artefacts and rounding issues?
(But if so, what about the y-axis, when using screen angles that are not creating triangle sides with well-behaving relations like 45° or 60°?)

I don't know.
But at least I now know why.
And I know I'll sleep better tonight.

[loukash]

2 hours ago, Bebebebenny said:

Although aaactually, for dots in a halftone screen the term should be "LPI" for "lines"...  

Yes, in the physical world. But here we're still fully in the digital domain, and the halftone pattern is still just a bitmap approximation using pixels.

[loukash]

2 hours ago, Bebebebenny said:

In my case of a 6 pixel cell at 45°, instead chosing 5.657 seems to produce a reliable, gap-less pattern.

Thanks for the math. 
My approach to all this is more of intuitive nature, since my last math/algebra/geometry lessons were about 40 years ago…  

[Bebebebenny]

2 minutes ago, loukash said:

My approach to all this is more of intuitive nature, since my last math/algebra/geometry lessons were about 40 years ago…  

That makes us the same age, but intuition alone would have had a very hard time bringing me to 5.657...

[loukash]

1 minute ago, Bebebebenny said:

intuition alone would have had a very hard time bringing me to 5.657...

Fair enough, I definitely didn't lose any sleep over this issue.  
Although it's an interesting phenomenon for sure.

[Old Bruce]

7 hours ago, Bebebebenny said:

Although aaactually, for dots in a halftone screen the term should be "LPI" for "lines"...

Yes, emphatically yes. Thank you.