VOC Colormap→Label

PASCAL VOC segmentation masks don't store class numbers - they store colors. Each of the 21 classes has a fixed RGB, like (128, 0, 0) for aeroplane, and turning those colored pixels into class indices requires a lookup table. VOC Colormap→Label builds exactly that: a tensor of size 256³ where each RGB color is pre-indexed to its class number. It's the d2l voc_colormap2label() function as a zero-input node, and it's the key you need before you can read any VOC label image.

The idea is a classic speed trick. A naive approach would compare every pixel's RGB against 21 class colors - fine for one image, slow across a dataset. Instead, this builds one giant array of 16.7 million slots, one per possible RGB value, and pre-writes each VOC color's class index into its slot. Then converting a label image is a single indexing operation: look up each pixel's color in the array, done. It's a textbook example of "pay once, index forever," and it's why the node exists as a separate step - you build the table once and reuse it across every image.

Inputs

None. No widgets, no sockets. It's a pure constant-builder.

Output

One output: colormap2label, a cdlTensor of dtype long, size 256³. It's the intermediate you feed into VOC Label Indices, which does the actual pixel-to-class conversion. You won't read this tensor directly - it's a lookup structure, not a result - so its whole job is to sit between this node and the converter.

Installing it

Part of ComfyDL. ComfyUI Manager, search "ComfyDL". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Cynthia-lxx/ComfyDL
pip install -r ./ComfyDL/requirements.txt

Restart ComfyUI. Pack depends only on matplotlib; nothing to download.

Gotchas

The one practical thing: this node must feed VOC Label Indices - the table and the converter are a matched pair, and the table is useless on its own. Also be aware it's a 16-million-element tensor; that's a real but small allocation, and building it once and reusing it beats rebuilding it per image. There's a subtle dtype thing worth knowing: the table is long (integer) dtype, and the label converter indexes into it with the combined RGB value - keep them in the same workflow and the types line up; try to hand the table to some other node and you'll be fighting dtype mismatches. Niche pack, no community threads yet, but a constant table is hard to break - the whole challenge is remembering it's a prep node, not the result you're looking for.