search

inkstitch / pyembroidery

libembroidery/EmbroideryFormats converted to python
MIT License
71 stars 28 forks source link

Improved vp3 file trim handling #73

Open MatsIBengtsson opened 4 years ago

MatsIBengtsson commented 4 years ago

This one starts to solve the pyembroidery side of the changes needed to handle trim in vp3 files. There are at least two issues known which will be part of this work:

lexelby commented 4 years ago

I'm a little confused by what's going on here. As far as I understand it, END is supposed to be the end of the entire design. If that's not what 0x03 actually means, then we shouldn't call end().

Have you actually seen 0x03 in the middle of a VP3 file? If so then maybe we should call trim() instead?

lexelby commented 4 years ago

Another issue is that, from what I can tell, once we see 0x80 0x01 we should keep reading "long" stitches (two bytes for x and two bytes for y) until we get 0x80 x02. Maybe there were several misunderstandings when this file was originally written...

MatsIBengtsson commented 4 years ago

I'm a little confused by what's going on here. As far as I understand it, END is supposed to be the end of the entire design. If that's not what 0x03 actually means, then we shouldn't call end().

Have you actually seen 0x03 in the middle of a VP3 file? If so then maybe we should call trim() instead?

Yes. The reason that the whole file, as uploaded here, was showing in Ink/Stitch as only a small part, followed by another small part, and then a third part, was that Ink/Stitch tried to interpret "END" as end. And it is. But not end of the colour block, that is decided by the separate byte length of color block. Rather End of this specific stitch block. Look at comparison picture in issue defined in #74.

Both Wilcom TrueSizer and Husqvarna/Pfaff Premier and my own machine Husqvarna Topaz 50 accept the file (which was created by TrueSizer). The file consists of a long colorblock, which has its length defined in the file. Within that length is a number of Trims happening. They have different patterns, one is "END", followed by a new stitch in a new group. So END does not mean "end of a colour block" it means "end of this stitch block within this color block" and is at the same time interpreted as some kind of TRIM. It does have Trim followed after it as well. Also, colorchange exist in the file. so patterns are "END" as well as "END-TRIM" as well as...

I have actually added some "previous command" and "previous stitch block" as well as "next" for them to the embroidery simulator. So it is very easy to see what a file contains after read by pyembroidery.

This is also the reason I added "END" to stitch, what is in the file cannot be interpreted by using trim only, or end only. I have actually created an interpretation in colorblock (on my way to get it to becomes stitchblocks) which works both in read_file and in input, to split the colorblock into stitchblocks only where "END" exist inside file, or "END-TRIM" exist after each other, or "END-TRIM-JUMP" exist after each other. I beleive it will only trigger in some specific files (like vp3).

The nice thing with that is that the vp3 file itself is read and interpreted stitch block by stitch block, thus editable or replacable using Ink/Stitch stitch block by stitch block.

My aim is to experiment a little more. Currently I can read and understand the files. Now I want to write them. When that is done, we get to know what a Topaz accepts in a vp3 format. Likely, there is some unneeded stuff. But END is not one of those.

lexelby commented 4 years ago

Does an END in the middle of a color block in a VP3 always mean to trim the thread and keep sewing?

MatsIBengtsson commented 4 years ago

Does an END in the middle of a color block in a VP3 always mean to trim the thread and keep sewing?

If I am to guess (and until I can produce output and test on a machine I have to guess): I believe not.

From the manual I know there is a number of alternatives (but nothing on file format), and nothing really detailed. My only way to experiment so far has been Wilcom TrueSizer:

So I intend to test and see what is the difference END vs END-TRIM vs END-TRIM-JUMP vs JUMP vs TRIM-JUMP. All combinations exist in the file I uploaded, I am just going to intentionally place them and see differences.

lexelby commented 4 years ago

Oh right! I forgot Husqvarna machines can trim the top thread only.

I still think we should not use END for this. If we have to introduce a TOP_TRIM command, then so be it. END marks the end of the design in all other formats though.

I think your concern is that you want Ink/Stitch to split to a new svg path when it sees the 0x03. We can definitely make that happen even without using END.

MatsIBengtsson commented 4 years ago

Oh right! I forgot Husqvarna machines can trim the top thread only.

I still think we should not use END for this. If we have to introduce a TOP_TRIM command, then so be it. END marks the end of the design in all other formats though.

That is simple, it is your project, your decision. Whatever you think is right is the way I will do it. I have been trying to achieve something similar by introducing sequences in read-file and input (END inside color block, END-TRIM inside color block, and END-TRIM-JUMP inside color block). Should work for vp3 and not confuse anything else. Translating husqvarna 0x03 to TOP-TRIM if that is what it is should be easy. I am already preparing for whatever is your decision by breaking out the simulator stitch block and placing besides stitch-plan so all handling of commands are easy to change.

I think your concern is that you want Ink/Stitch to split to a new svg path when it sees the 0x03. We can definitely make that happen even without using END.

We can, just tell me what you want to call the Husqvarna 0x03, and I will use that instead. I am already assuming an END within a color block is unique for Husqvarna, much better to have it named something unique.

lexelby commented 4 years ago

Great! Go ahead and do what you need to in order to create test files to run on your Husqvarna. Once you know how the file format really works, then we can figure out how to structure the code.

lexelby commented 3 years ago

Were you ever able to figure out what was needed to make trimming work on your machine?

MatsIBengtsson commented 3 years ago

Were you ever able to figure out what was needed to make trimming work on your machine?

Partly. I did lot of tests together with owner of the separate project for file translations. We found how to make it work to same level as all examples we could get our hands on. All of that he put into his code, and I put it into the code in your library as well. It means that it locks the thread before and after jumps. Even cuts the over-side thread, a feature Husqvarna has. All of that is in the branch on your side. Which also included to be able to read full other format input files and translate them back to husqvarna without losing cuts, and including automatically creating inkscape/inkstitch objects corresponding to all incoming parts from the read format.

lexelby commented 3 years ago

Awesome! I'll give this another review when I get a chance, and maybe we can finally get this merged. 2020 was a hell of a year...

lexelby commented 3 years ago

@MatsIBengtsson with this latest version, do we still need any changes in Ink/Stitch?

lexelby commented 3 years ago

I mean, aside from the obvious need to pull in the latest version of pyembroidery.

chrisyelf commented 1 year ago

Would be useful to have this fix merged

lexelby commented 1 year ago

@chrisyelf Would you be willing to test this on a machine that reads VP3 files?

chrisyelf commented 1 year ago

I don't have a machine, sorry :(