Support Wilcom's .emb native format

[robin-swift]

No description provided.

[robin-swift]

Seems we already have some binaries to pull apart in the samples/ folder (e.g. this one). I'll post some interpretation here if I get anywhere.

[tatarize]

https://stackoverflow.com/questions/3488544/embroidery-file-formats

Has some of my edited results over the last few years. It might be possible to read most of the .emb file. It's Compound Binary File Format, with an Contents file that you can read as it's 4 bytes of size and then a zlib stream. This gives you a bunch of uncompressed proper data and then it appears to be a triplet system within that.

The more important stuff the Design stuff which is apparently encrypted since I can't find a stream in it but the values of the binary are equally distributed.

[robin-swift]

Huh, that sounds challenging, I'll have to tag this as "version 1.1 or later".

Encrypted files without any official file format description should generally be done after we get the Python bindings working and simpler file formats working to some level.

[JohnMPC]

Hi Guys, Thanks for taking a look at this. I have PLENTY of .EMB files that i can provide if you need.
The idea behind what i am working on came from https://embtrak.com/. If you haven't already seen this, could be worth a look for some ideas.

[robin-swift]

@JohnMPC The best way to add a new format is to have a complex example of that format along with a rendering of what that format looks like preferably showing the individual stitches. Here's a little primer so I can paste the advice into the docs.

How to Help Develop A Specific Format

For example, if I wanted to test/add a feature to our PES parser I'd open up another program that supports PES, create a non-trivial example like the ones in our Embroidermodder/samples/ folder then export 3 copies:

1. The .pes file example.pes
2. A simpler format version so we can check that our interpretation matches: example.csv. (Chosen because it's both machine and human readable.)
3. A render in a common image format example-render.bmp.

If you could do this for any your files you're comfortable sharing for this purpose, preferably about 5 examples showing different features (like automated fills or other weird features that may be supported), then that would help us improve your format.

We're not starting from scratch because @tatarize has compiled notes above and here but I'd definitely do more to make this happen with these examples to hand.

[tatarize]

I think Wilcom's stitch data is actually stored in the DesignDocument data even for straight stitches data. I asked an expert and it looks like the format might be encrypted with something that looks a bit like AES (but different somehow, he wasn't clear) or so with a couple potential keys:

"1d43f2ae6e7602675653ac80bbd0d184"
"jfskldfji642784284y223490234"
"mvkld780 rfsaus 0s8u4958762 08y345897307 20948290 y47hr427i462844"
"hsuwbc ;rowhsabc cvkfowy6abd fld9273gd d;24723gqw dmdle9037wqb2a"

And while it might be doable. I see that the .csd files have a bit of encryption too, and might fall on a less helpful side of American law. Also, I think there's some programs that say they work up to version 4 or .EMB or .ART or something so it's not exactly clear if they changed something there or if it's to do with licensing or something. I am much less optimistic than I previously was on the format and that's with being told the cypher keys. Since requiring cypher keys puts it in a category more like .PEN files (which are Disney .PES files).

I was thinking the data was in .Contents but it's apparently in a .Design file. Also, this could mean its run through their engine too since those are supposed to be able to resize. And then you have an even more weird situation where it's like some of those embroidery fonts. Where it's certainly readable but you need to implement your own embroidery engine to make it entirely workable. However, since the .EMB files are supposed to be directly readable by some machines it would seem like it should have the stitch data, but also those machines would be required to decrypt the encryption too so they can't just be super simple integrated circuits so they might have enough oomph to support some rather basic implementations of more problematic things.

[fabricocouto]

CATORES.zip
Wilcom itself, when we are programming the matrix for the machine, shows us the coordinates and also the functions with trim jump etc.
It's difficult to get this information in binary

[fabricocouto]

Wilcom itself wrote a dll capable of reading its native emb files in trueview.
I was able to read the emb files using their own dll,