PCS doesn't properly skip padded colors, or write 16 colors.

[tatarize]

We write accurate color counts, then pad up to 16.

    colorCount = (unsigned char)embThreadList_count(pattern->threadList);
 ...
    for(; i < 16; i++)
    {
        binaryWriteUInt(file, 0); /* write remaining colors to reach 16 */
    }

We read the written color count, then try to read stitches that could be zero.

The end result is that it produces what seems like correct files, but then cannot read them. I'm unsure whether the color count should always equal 16 with the padding or if the padding should be omitted. But, it's an issue either way. It cropped up in MobileViewer's transcoded version.

colorCount = binaryReadUInt16(file);

    for(i = 0; i < colorCount; i++)
    {
        ...
        embPattern_addThread(pattern, t);
        ..
    }
    ...
    st = binaryReadUInt16(file);
   ...

[tatarize]

Also, I note that Wilcom software rather than a 1:1 ratio for the numbers in 1/10mm actually uses a 5:3 ratio.

[robin-swift]

Also, I note that Wilcom software rather than a 1:1 ratio for the numbers in 1/10mm actually uses a 5:3 ratio.

This seems like it's own issue, does Wilcom do this with all formats for just PCS?

We need a set of reference files that are CC-BY-SA or equivalent so we can resolve issues like this. I'll make that a new issue before resolving this one.

[fabricocouto]

just ask me to send the files saved in wilcom and embird [email protected]

[tatarize]

Likely just PCS. It might actually be that PCS format is scaled like that natively. There's a few other formats with different coordinate systems that need to be correctly accounted for. I've not checked what the correct number of colors should be. But, the reading and writing didn't match up.

[fabricocouto]

there is an error in the file reader that you haven't seen yet, it keeps the jumps out of the drawing this changes the x y sizes of the files, at least files saved by wilcom. as wilcom I consider it to be still good for development, it would be good to take wilcom as valid files

[tatarize]

PCS as a file reader is absolute coordinate system. So I'd guess that that point is likely 0,0 and some 0,0 values are being fed in there.

[fabricocouto]

I did something for a quick little test on the pcs reader but still with x and y size error but less than it was of course it's wrong it was just a test, but it came pretty close to what it really had to be still generates a null color

while (st_count < stitches_count)
    {
        FileSystem.FileGet(file, ref b8);
        FileSystem.FileGet(file, ref b0);
        FileSystem.FileGet(file, ref b1);
        FileSystem.FileGet(file, ref b2);
        FileSystem.FileGet(file, ref b3);
        FileSystem.FileGet(file, ref b4);
        FileSystem.FileGet(file, ref b5);
        FileSystem.FileGet(file, ref b6);
        FileSystem.FileGet(file, ref b7);
        flags = StitchType.fNORMAL;
        if ((b8 & 0x01) == 0x01)
        {

        flags = StitchType.fSTOP;
        }
        else if (b8 == 4 | b5 == 240 | b5 == 104)
        {
             flags = StitchType.fTRIM;
        }
        x = uint32(b0, b1, b2, b3);
        y = uint32(b4, b5, b6, b7);
        if (b1 != 0x0)
        {
            curx = x / 128;
            cury = y / 128 * -1;
            pattern.AddPointAbs(ref curx, ref cury, ref flags);
        }
        st_count++;
    }
  

 internal static long uint32(byte b1, byte b2, byte b3, byte b4)
{
    int x = (b1 & 0xFF) | (b2 & 0xFF) << 8 | (b3 & 0xFF) << 16 | (b4 & 0xFF) << 24;
    if (x > 8388607)
    {
        x = -(short)((int)(~x & 8388607) - 1);
    }
    else
    {
    }
    return x;
}