How advanced should the stabilizer be?

[tatarize]

Currently it's super-dumb, but also entirely optional.

When it loads a file, currently the preferred method it has is just cycle through the commands and find stretches of unbroken stitches and call that a stitch block and add that to the destination pattern. This actually means it will trim in locations where it threw in a jump stitch. It will trim if it ejected a sequin (heck if it turned on sequin mode). Basically it only searches for uninterrupted series of of stitches. Adds some bounds to those and tells the encoder to fix it, if you save it out.

There's also things like #22 which is a perfectly reasonable idea, but involves a bit of math and some fuzzy deciding logic as to whether the color_change is some distance away, has displacing jumps on both sides of it, etc. Currently stablizing does prohibitively disruptive things like stripping out sequins and stops. Though it's not actually a critical feature of the program. It just makes sure all the bits and bops are in the right place by converting the whole thing to middle-level stitch commands.

There's a clear chain of thought, that says it's not really my job to figure out what is or isn't relevant in a bunch of format ordered commands and data etc. But, there's another that says it might be better if you aren't required to figure out if the data came from a .dst that the trims should be interpolated by 3+ jumps in a row. And if the data comes from vp3 the trims are any stitch longer than 255. Some elements of this post-processing might even need to be more tightly coupled to the loader-type like the encoder is tied to the writers.

It's kind of an oversight in the mandate, but there's no guidance on how much work this thing should do.

[lexelby]

I'm not sure I fully understand what the stabilize function does. It sounds like the idea is for it to interpret a raw embroidery file into higher-level objects?

At the moment, I don't feel a compelling need to use this functionality in Ink/Stitch. I'm not planning to allow for round-tripping embroidery designs through a machine format, and I feel that Ink/Stitch's capability to read embroidery files isn't really one of its core features.

Maybe other pyembroidery users would feel differently though.

[tatarize]

Yeah, sortof, but some of it is to interpret the raw embroidery file into more consistent embroidery file. Sometimes how the embroidery was stored will influence the order and structure of the commands it issues and that stuff will artifact out on the load.

I'll leave this issue here in case somebody else integrates pyembroidery into another project and has a firm opinion on how they would like the loaded data to look. Some bits are perhaps low hanging fruit, like machines that read DST files often trim after a few jumps and as such, maybe interpolating a trim in that case is actually proper. Whereas maybe in some other format properly understands such things. Though it seems like some of this might be better off set by the user, and it's not really part of the mandate... so for now, have a bunch of raw stitches.