File corruption when viewing and saving slice file in Chitubox


I’m posting this in the General section because I don’t believe it’s a bug with Formware, per se.

This happens with any model I use to test. I’m using Formware version and I’ve tested with Chitubox 1.9 and 1.9.1.

To cause the issue,

  1. Slice a model in Formware using the .ctb extension.
  2. Open file in Chitubox to view layers, detect islands, optionally - delete islands.
  3. Save using Chitubox.

You will notice that the file size has increase by ~1 KB. This file is now corrupted. It can’t be viewed properly in Chitubox (appears as a block) and the printer will not recognize it. I had this issue when I took my slice file from Formware and loaded it into Chitubox in order to delete minute islands. I don’t recall having this issue in the past. Just curious if you can reproduce this issue and possible explain where the error comes from.


I can reproduce this behavior with files sliced in Formware and re-saved using Chitubox, the model ends up as a block. It happens with or without performing the island detection/removal in Chitubox.
Doing the same with files sliced in Chitubox seems to work fine.


Thank you for the confirmation. I hope there is an easy fix to this issue.

I like the automated ability in Chitubox to detect (ease of navigating to offending slice(s) with arrow keys) and delete islands. My current setup has been to support and slice in Formware, and then to load into Chitubox to delete any small islands that remain.


Hi both,

I will check it and get back to it.

Just some remarks in general, (why it will probably be hard to find the exact difference):

  • V1040 contains the CTB SDK. So this will probably require you to update your firmware in some cases. But this will (most likely) garantuee that the file will be similar.

  • I say ‘most likely’ because in the run-length encoding (RLE) schemes i got from CTB where some logic errors that I corrected in our current V1040 code (and were also correct in our V1039 own export). One of them was for example a wrong length count of a row of pixels. I have no idea how this is implemented in the CTB software.

  • Another thing to keep in mind is that the RLE used in CTB is 7 bits color value. So what this does is that if you have a white pixel (normally that is byte value 255, 11111111, 8 bits) and you encode it (write to file) it will become 7 bits, 1111111.
    When you read that back it will become 111111110 (you shift it). So depending on how the software reads it, you can add 1 again to get 255. Or stay with 254. This is not necessarily the cause of this issue, but just to show that there are cases where you are loosing a bit of info that can create small difference depending on how the application is programmed… of course reading back and writing again can multiply this sort of stuff.

kind regards


After some testing;

  • this behaviour (plate shows up) is confirmed using formware CTB export + chitubox 1.9.
  • when you do it with a file from chitubox it won’t happen.
  • when you put the slice format in Formware to CTB SDK it won’t happen either (so that fixes it, so at least we don’t have it with the SDK we paid for :wink: ).

It’s a bit low priority at the moment as we’ve shifted to using their SDK.
So unless it’s a show stopper to update the profile to using the CTB SDK export i will not investigate this further.

kind regards


the island function is interescting of course; i will check that :wink:

  • we currently have 3 island detection mechanisms in formware:
  1. live island detection
  2. print check command (run all checks when you are done supporting)
  3. island detection based on pixels -> re-import your .ctb file and run diagnosis on it.

should make some video’s about it…

kind regards


Thanks for the thorough explanation of where the variation might come from. I didn’t know there were truncations made at the bit level.

To expand on the island detection mechanisms:
If you were to use a XY tolerance value (eg -0.1 mm) at time of slicing, the live island detection algorithm would not necessarily work if the boundary subtraction (or addition) resulted in formation of island? My supported parts pass all checks before I slice, and only once I re-inport the .ctb file do I get detected islands. The resulting islands are only a few pixels in size, so maybe they passed the area threshold criteria. Anyway, it’s not a big issue. Just want to better understand the order of operations.

Unrelated note, I updated to and can’t seem if view/enable the part boundary line that was present when viewing a slice job. I like to view the red line and gauge how close the lit pixels were to the exact position of my model, and to see how the XY tolerance value changed this distance.


I would like to add onto my last post.

I did some more testing on this matter, and switching to the v4 SDK .ctb output seems to have resolved the issue. I can now slice my parts in Formware and load the print job into Chitubox. The slices now appear as they normally should. The only issue seems to be that the build volume and weight parameters are null. I haven’t actually attempted printing from a file that has been taken from Formware to Chitubox, so be cautious. It seems using the SDK has partly rectified some incompatibilities.


ok thx for the feedback. I’ll double check the weight and volume. They should have a value of course… but i don’t believe they are used other than display purposes.