Possible to reduce aliasing in SATIN mode?

[golanlevin]

Hi @LingDong- , I realize this must seem picky after the incredible work you did with the SATIN optimizer. (Which is amazing.) But it has a kind of unfortunate "aliasing" based on the hatchSpacing: essentially, it is impossible to have a sparsely-filled shape without ALSO having really bad "jaggies" (staircase effect) on some diagonal edges, depending on the orientation. From a visual standpoint there is no good reason for the satin rows to reach all the way to the edge of the shape (or at least, look more precise).

I don't think we need to use the vector data. Rather: Could it simply be possible to improve the situation by quantizing the shape with non-square (rectangular) pixels? Essentially giving the rasterized shape more resolution in the X direction than in the Y direction?

[LingDong-]

@golanlevin Actually I've been thinking about the same issue ;)

I think your solution is pretty neat, essentially when passing in the image, we stretch it horizontally so that it's super fat. And after the algorithm is done, we squeeze it horizontally to the original width.

The solution I had in mind was to save a grayscale value in the edge pixels (we get automatically from Processing smoothing/antialiasing). After the algorithm is done, each stitch check the grayscale, and decide if it should move outward a little bit, or inward a little bit.

Seems like yours is even easier to make, I'll try it out!

[LingDong-]

Now added: ea11605ba4a090e088d5b73fece58e0a9eef2995

just by changing 1 line now the edges are perfectly aligned :)

[golanlevin]

It's much, MUCH better!!! However, I found a glitch, @LingDong- , which I have pushed to the repo in examples/PEmbroider_animated_playback.pde. This happens when the hatchAngle is -70°, and the hatchSpacing is 5 or 6. It looks like bad luck aliasing. Any ideas what we could do here? (Maybe choose a different threshold for the binarization?)

[LingDong-]

@golanlevin Found the issue:

When processing renders the shape, it produced a tiny hole due to aliasing. My algorithm tries to remove the hole by carving a canal to the left border, which unfortunately splits the shape

[golanlevin]

Understood. An understandable bug; this looks fixable. Maybe count the contours in the rasterized shape, see if there are new micro-holes? Or run an algorithm that finds and fills 1-pixel holes after rasterization? I'm certain you have ideas how to fix.

[LingDong-]

@golanlevin now fixed: 427812a67f6b3b57fbfc28b1593830d6f6c15ce2

I was already using a dumb hack that removes 1px holes, now due to the extra fattening the holes are stretched too! So I extended the hack to remove 1-3px wide holes.

[golanlevin]

This SATIN hatcher is so incredibly good. This is professional stuff.

[golanlevin]

Hi @LingDong- , OK , I have the patch for tiny holes but am still seeing this glitch, or something like it. See my new example, PEmbroider_shape_hatching_4.pde:

[LingDong-]

Hi @golanlevin, yes, this is currently how holes are dealt with in SATIN mode. A canal is carved, so the shape no longer has holes, before it is passed in to the algorithm. See https://github.com/CreativeInquiry/PEmbroider/issues/50#issuecomment-649071191 for a solution I'm thinking about.

The hole in the image is not a tiny hole, so it's not affected by the previous patch

[LingDong-]

yet another possible solution: Now the images passed into satin are very very fat. So if we carve a vertical canal instead of a horizontal one, it will look a lot less conspicuous.

[LingDong-]

@golanlevin

tried the vertical canal idea. I think it looks pretty good. ac76d90a2532e28e24a5d5f0e89a875a2dc91209

[golanlevin]

@LingDong- , there's a little gap that occurs at the branching-points of the SATIN skeleton:

You can see this happening in examples/PEmbroider_satin_hatching_1.pde using Theodore's shape with E.hatchAngleDeg(45). Is it possible that this could be resolved by moving the branch-point further towards the next row, by a distance of ½ of a hatchSpacing?

Obviously this gap is negligible for tight hatchSpacing, but it's noticeable with wide.

[LingDong-]

I don't think it's a gap. I think it looks like expected result for zig-zag from variable row width.

When the row is wide, the / part of the zig-zag is long, so it looks emptier. When the row is narrower, the / looks denser.

Compare

_____
 _.-'
'----

vs

_ _ _
/ / /
- - -

Additionally with the raster algorithm I think it is difficult (if not impossible) to move the rows.

[golanlevin]

Alright, we'll ignore this :)