Painting data storage

Model painting data is stored in a PNG image, along with the UV coordinates of the model, which are stored in the mesh data itself.

However, an image represents colors, and what we store is some different kind of information:

• Seam placement data
• Support placement data
• Extruder to be used
• ...

As we have multiple types of information (a feature), and we want to store everything in a single image. However, not every feature will be used by every print, we might want to add/remove features, and we prefer an efficient representation of data. To that end, we need to insert a "manifest" in the image metadata, that will indicate how to interpret the pixels of the image. This manifest is written using JSON format, and is designed to be extensible and retro-compatible.

The format is the following:

{
  "_feature_": ["_bit_index_start_", "_bit_index_end_"]
}

A full example of this would be:

{
  "seam": [0, 1],
  "support": [2, 3],
  "extruder": [4, 7]
}

In this example, we will store:

• Seam painting information on 2 bits, thus up to 4 different values
• Support painting information on 2 bits, this up to 4 different values
• Extruder information on 4 bits, thus up to 16 different values (which is currently the maximum amount of extruders supported by the engine)

Each pixel can then be stored with only 8 bits, so we can optimize the storage of the image. If we ever add a new feature or need longer bits ranges, the image will be stored with 16, 24 or 32 bits per pixels as necessary. On the other hand, if then, say, the support painting data is cleared, the new image can be stored on less bits per pixel. (This too, can be done dynamically w.r.t. how many 'features' the user needs.)

Endian-ness and byte-ordering to be determined -- but should be the same across all OS's, since it's saved in an exchange format after all.