Closed MatsIBengtsson closed 5 years ago
tatarize
commented
5 years ago I couldn't make the files with the trims in them before. I'm not sure that I could produce them. I'll check through the file. Odds are good it's just something I didn't see during initial testing.
MatsIBengtsson
commented
5 years ago I couldn't make the files with the trims in them before. I'm not sure that I could produce them. I'll check through the file. Odds are good it's just something I didn't see during initial testing.
Thank you. Did check through the file using your version of pyembroidery. It can read them fine, just do not return after first end, keep iterating until length of files.
tatarize
commented
5 years ago elif y == 0x02:
pass # ends long stitch mode.
elif y == 0x03:
out.end()
return
out.trim()
out.color_change()Should be:
elif y == 0x02:
pass # ends long stitch mode.
elif y == 0x03:
out.trim()
out.color_change()Without having seen a trim command, I took some guesses. I figured the 0x03 was end since I only ever saw it as the last command. Rather 0x80 0x03 is an overt trim command it just often did it at the very end of the document. Since I took that to be an END I wrote out a end and stopped processing the block. So it read the first color block from each section and stopped. But since it ended it also didn't have the color change in it, so it all stayed the same color throughout. It's a pretty easy modification and it'll both accept and use real trims.
Sorry for the delay. I've been on a genealogy binge. It's as stupid as it sounds. And a detour from my compression work to try to get HUS files working (white whale kind of thing, but requires recoding a primitive kind of ARJ compression, which requires understanding what it's doing through obfuscated source code).
tatarize
commented
5 years ago Okay, MatsIBengtsson, that should be sorted out. I seem to recall that VP3 might have also had a real stop command in it as well. Is that true, and if true can files be made with those? I'm sure they could be faked with same color color_change, but I seem to recall some sales or features copy saying it had something like that.
Also, do you find the multiple designs feature of the file format useful? I know it exists and mapped it out when I worked with the format. I short handed the first time and didn't implement it but it wouldn't be too hard to implement. It just doesn't seem like any other format has that feature or would care much. I knew it existed so I made sure to permit multiple END commands as such. At a minimum I think I should read the designs. Most of the patterns will just stop caring at the first END command. See #70 for the trim command fixes.
MatsIBengtsson
commented
5 years ago Okay, MatsIBengtsson, that should be sorted out. I seem to recall that VP3 might have also had a real stop command in it as well. Is that true, and if true can files be made with those? I'm sure they could be faked with same color color_change, but I seem to recall some sales or features copy saying it had something like that.
Yes, it is sorted. I tested your output today, and it worked. I do not have a manual on what commands vp3 contains, there is quite little from Husqvarna on it. Maybe Pfaff is revealing more. But the machine has slower/faster, stop, trim, cut, so I guess the format may have as well.
Also, do you find the multiple designs feature of the file format useful? I know it exists and mapped it out when I worked with the format. I short handed the first time and didn't implement it but it wouldn't be too hard to implement. It just doesn't seem like any other format has that feature or would care much. I knew it existed so I made sure to permit multiple END commands as such. At a minimum I think I should read the designs. Most of the patterns will just stop caring at the first END command. See #70 for the trim command fixes.
The multiple feature of the file format seen as format has not been useful for me so far. What it does is to allow me to take a large hoop, insert and move around a number of different designs, so they all become a new ready made design, directly on the machine. If I wanted to save that, then the file format would be useful. But if I can start from Ink/Stitch instead, I do not think the machine would become my favorite editor... :) So thank you for a great work.
tatarize
commented
5 years ago Okay, I'll table it some more. It is a thing the format can do and I should eventually add it. I have it mapped out and it's not that hard to do, I think I even coded the writer with that in mind. And things like inkstitch would likely not care much or want to cater heavily to a rather poorly supported (in that most readers won't read them) feature of one file format. And it always seemed to me loading a different file would be the most logical element.
I'll close this down since there's no question reads work fine with this correction.
When reading a vp3 file which contains true trims (trims which are not only a colour change), pyembroidery reads it wrong. This is also mentioned in Ink/Stitch (https://github.com/inkstitch/inkstitch/issues/516)
As can be seen in below picture, a lot is missing. Both stitches and colours. To the left is Premier, to the right is the interpretation by Ink/Stitch (pyembroidery):
Enclosed are the files behind above views, containing the example, of a vp3 file which is fully readable in both Wilcom TrueSizer and Premier. But not in Ink/Stitch. It is collected as a zip (vp3 with trim.zip):
The example above is linked to the issue previously mentioned, #68 so the main stitch file is the same. One reason for this seem to be pyembroidery Vp3Reader. It assumes that all end points in a vp3-file is the end of the color_block, even if it is stated that there are more stitches in that colour block. A simple remedy is to remove that assumption (in vp3_read_colorblock remove the return following after the out command in "elif y == 0x03:". Doing that reads all the trimmed stitches into pyembroidery. Unfortunately, now the trims are missing (ignore the colour difference, my mistake):