-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
.HUS format is mangling data #124
Comments
The height and width issue within HUS sounds like a real problem but most likely straightforward fix. For the other issues mentioned could you also include the .CSV file that you used? As for the weird stitches, I will have to check. There are a few things that happen internally which may cause the stitches for legitimate reasons. For example the maximum stitch lengths are different per format which would require adding jump stitches. |
The CSV file is this one here: https://github.com/leesdolphin/Embroidermodder/blob/master/line.csv I'm quite happy to poke around with the code with a little bit of guidance as to what I should be poking. |
Well there is clearly a bug with husDecode. Initially the The error compounds a bit as the whole routine is: if((_203 = (short) husExpand_249()) <= byte_MAX)
{
_278[_200] = (unsigned char) _203;
if(++_200 >= _279)
{
_200 = 0;
memcpy(&outputArray[outputPosition], _278, _279);
outputPosition += _279;
}
} deobfuscated: if ((c = decode_c()) <= UCHAR_MAX) {
dec_text[r] = (unsigned char) c;
if (++r >= DICSIZ) {
r = 0;
memcpy(&outputArray[outputPosition], dec_text, static_cast<size_t>(DICSIZ));
outputPosition += DICSIZ;
}
} The extra returned char from decode_c() ticks up the r value which is constantly compared to DICSIZ the dictionary size. This r is always equal to r+1 and when the value gets above DICSIZ (1024, ( But, this means it always reads an extra 0 for the commands at the front, which gets called a stitch, which is exactly the proscribed behaviors here. It could also manage to eat jumps or whatever since all the commands will be off by 1.
|
G'day(and Happy New Year). I've been working with this program for a while trying to make a little pattern and noticed that for some formats my pattern is ... a bit mangled. I've uploaded a sample file and some scripts to try this stuff out in my fork(https://github.com/leesdolphin/Embroidermodder/blob/master/convert-roundabout.py#L109)
Basically converting a really simple 1cm box from CSV to HUS to CSV triples the height, doubles the width and all around messes with the way it should be.
Some formats are more susceptible than others, for example TAP handles the conversion fine; however PES decides that once it's done with a box-ish it'll drift off toward (40, 400).
The script expects to be placed in the root of the repo; and will do a build(
qmake
followed bymake
forlibembroidery
andlibembroidery-convert
) before runninglibembroidery-convert
on the input file for each supported format. It'll then create a TXT file from the converted format and compare it to the original's TXT file by runningdiff
in side-by-side mode.For Example:
CSV -> CSV(adds a flag stitch for every conversion):
CSV -> HUS(produces weird stitches with no apparent relation to the inputs)
The text was updated successfully, but these errors were encountered: