Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved vp3 file trim handling #73

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

MatsIBengtsson
Copy link
Collaborator

@MatsIBengtsson MatsIBengtsson commented Aug 8, 2019

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:

…rblock changes which are implemented within the colorblocks, using special sequences (END, END-TRIM-JUMP)
@MatsIBengtsson MatsIBengtsson self-assigned this Aug 8, 2019
@lexelby
Copy link
Member

lexelby commented Aug 9, 2019

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
Copy link
Member

lexelby commented Aug 9, 2019

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
Copy link
Collaborator Author

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
Copy link
Member

lexelby commented Aug 9, 2019

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

@MatsIBengtsson
Copy link
Collaborator Author

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:

  • Cut on primary side, but keep thread on bottom side
  • Trim fully, and cut bot sides
  • Allow jumps to handle cutting/trimming automatically (no translation compared to above two alternatives)

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
Copy link
Member

lexelby commented Aug 9, 2019

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
Copy link
Collaborator Author

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
Copy link
Member

lexelby commented Aug 9, 2019

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
Copy link
Member

lexelby commented Feb 6, 2021

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

@MatsIBengtsson
Copy link
Collaborator Author

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
Copy link
Member

lexelby commented Mar 5, 2021

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
Copy link
Member

lexelby commented Mar 6, 2021

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

@lexelby
Copy link
Member

lexelby commented Mar 6, 2021

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

lexelby pushed a commit that referenced this pull request Jul 4, 2022
Adds color file formats and JSON, addresses #73 and #71
@chrisyelf
Copy link

Would be useful to have this fix merged

@lexelby
Copy link
Member

lexelby commented Mar 11, 2023

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

@chrisyelf
Copy link

I don't have a machine, sorry :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants