Segmentation Mask Export QA: Verify Palette Colors and Label IDs
· Buyer Guides
A practical acceptance worksheet for annotation buyers checking whether exported mask pixels decode to the intended labels, including background and ignore values.
Decode exported mask values against the agreed label map before accepting an annotation delivery. A mask that looks correct in a color preview can still decode to the wrong class IDs. Keep the export encoding, label mapping, background and any ignore value explicit.
This guide is for annotation buyers and dataset reviewers. It describes an original export acceptance check, not a company hiring opportunity, worker evaluation, vendor ranking or guarantee of model performance. Data Annotation Companies is independent and is not affiliated with CVAT.
What does the export format actually encode?
CVAT's Segmentation Mask documentation describes PNG masks with one or three channels, colors corresponding to labels, and black as the default background color. It also describes labelmap.txt for interpreting non-default label mappings. Those are properties of that format; do not assume every exporter or training pipeline uses the same mapping.
Confirm the exact agreed export format and the consumer's decoding rule. A three-channel RGB color, a one-channel class index and an object-instance ID are different representations. A color displayed by a preview tool is not independent proof of the stored value or its label meaning.
Which fields belong in the buyer acceptance worksheet?
| Check | Evidence to obtain | Acceptance question |
|---|---|---|
| Format | Exporter, format and version | Which file representation was agreed? |
| Stored values | Actual channels and value type | RGB color, class index or another documented encoding? |
| Label mapping | Controlled color or value-to-label map | Does the consumer decode the same labels? |
| Background | Explicit agreed value and meaning | Is background distinct from an unlabeled or ignored pixel? |
| Ignore handling | Agreed value and consumer behaviour, if applicable | Does it remain separate from ordinary classes? |
| Unmapped values | Observed values absent from the map | Is every unexpected value investigated? |
| Round trip | Small known sample decoded by the intended consumer | Does decoded meaning match approved labels? |
Keep acceptance rules agreed before the delivery. A renamed class or revised mapping needs a controlled new version and a check of affected exports. Do not silently assign a convenient label to an unexpected pixel value to make validation pass.
How can a visually plausible mask decode incorrectly?
Illustrative example. The following palette and IDs are synthetic and explicitly agreed for a fictional buyer workflow. They are not CVAT defaults or a recommendation that every dataset reserve these values.
| Stored RGB color | Agreed semantic label | Buyer class ID |
|---|---|---|
| 0, 0, 0 | Background | 0 |
| 128, 0, 0 | Cable | 1 |
| 0, 128, 0 | Tray | 2 |
An exported pixel has RGB value 128, 0, 0. Under the stated mapping it means Cable, which the buyer represents as class ID 1. A loader that treats the first channel, 128, as the class ID would interpret a different value. A preview can still show the expected red region while the consumer receives the wrong class encoding.
The buyer checks stored values, the controlled mapping and the decoded result on a known sample. If the consumer expects a class-index mask, use an approved conversion based on that mapping and retain the original export. Do not use a screenshot or lossy image conversion as the label source.
How should background and ignored pixels be reviewed?
Background, not-yet-annotated and ignored pixels may have different meanings in the agreed dataset contract. Write those definitions down instead of relying on a black preview. CVAT's documented default background color is not proof that another workflow treats all black pixels the same way.
Illustrative example. A fictional buyer reserves class value 255 as ignored in a separate one-channel encoding. That is an explicit example assumption, not a universal rule. The acceptance worksheet checks that the consumer handles 255 under the agreed policy rather than treating it as an ordinary class or automatically mapping it to background.
What can an unmapped-color check reveal?
Compare observed stored values with the controlled map. If a file contains colors that are absent from the map, preserve the original file and record the affected sample and values. Investigate the actual export and preprocessing steps; a color count alone does not establish the cause.
Do not accept a nearest-color correction automatically. Any remapping needs an agreed method and a review of its effect on labels and boundaries. After an authorised correction, repeat the consumer decode check on the final delivered files.
Keep this encoding check separate from bounding-box coordinate validation and annotation accuracy assessment. A valid label map does not prove boundaries are accurate, every object is annotated or a model will perform well. Use the company directory to discuss actual provider services and request a representative export pilot before comparing delivery scope.
Frequently asked questions
Does a correct color preview prove correct class IDs?
No. Check the stored encoding, agreed map and decoded result in the intended consumer.
Is black always background in every format?
No. Confirm the actual exporter and agreed dataset meaning. CVAT documents a default for its specific mask format.
Is 255 always the ignore value?
No. It is an explicit synthetic example here; use the real agreed mapping.
Does passing this check prove annotation quality?
No. Encoding consistency and annotation accuracy are separate acceptance checks.