DCI File
The node that actually builds your .dci archive
- DCI Binary Data
- DCI Image 1
- DCI Image 2
- DCI Image 3
- DCI Image 4
- DCI Binary Data
If DCI_Image is the brick, this is the mason. A single DCI_IMAGE_DATA from the image nodes is just one icon layer; a DCI file is the whole container - every size, state, tone, and scale variant packed into one binary archive that a Linux desktop can actually load. DCI File is the node that does that packing: it takes up to four DCI image layers and assembles them into a single BINARY_DATA blob in the DCI format.
Under the hood it builds the directory structure the DSG Combined Icons spec demands - <size>/<state>.<tone>/<scale>/<filename> - and writes the little-endian binary archive with the DCI magic header. One thing the source does that's easy to miss: for Universal tone images it doesn't just dump the file, it also creates a symlink in the matching dark directory pointing back to the light file (../../state.light/scale/filename). That's how one generated asset serves both light and dark themes without duplicating bytes, and it's exactly what the spec wants.
The inputs are all optional, which is the clever part:
- DCI Image 1 through DCI Image 4 - the
DCI_IMAGE_DATApackets from DCI Image / DCI Sample Image. Wire up to four layers (say, normal + hover + pressed + disabled) into one archive. - DCI Binary Data - an optional existing DCI blob. If you pass one in, the node merges the new images into it instead of starting fresh. New images with the same path overwrite what's already there, which makes building a multi-state file incrementally painless: run once for normal, feed the output back in, add hover.
Output is a single DCI Binary Data value - the complete archive in bytes form. From there it feeds naturally into the rest of the pack: DCI Preview to eyeball it, DCI Analysis to read its structure, DCI File Saver to write it to disk, or the Deb Packager to wrap it into an installable package. You never touch the filesystem here; everything stays in-memory until you pick a saver node.
Installing
Part of the comfyui-dci pack, which is just Pillow + numpy - no models, no heavy deps:
cd ComfyUI/custom_nodes
git clone https://github.com/zccrs/comfyui-dci
cd comfyui-dci && pip install -r requirements.txt
Or install "DCI Image Export Extension" via ComfyUI Manager and restart. Nodes show up under DCI.
Where people get burned
- Feed it nothing and you get an empty blob. If no image and no existing binary data arrives, the node returns empty bytes rather than erroring - and then the preview/analysis nodes complain loudly downstream. The error messages are detailed enough to tell you what happened; read them.
- It combines, not deduplicates. Four states at four different sizes is sixteen layers - you'll want a separate DCI File node per size, or you'll be wire-spaghett-ing.
- Order doesn't matter for correctness, but overlapping paths do. If two input images map to the same path, the later one wins silently. Keep your states distinct.
Real talk: this is the most "system-integration" node in a pack that's already niche. If your goal is a themeable Linux icon set, it's the hinge of the whole workflow. If you just wanted base64 utilities, you can skip straight to the Files category - but then you're missing the point of the pack.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| DCI Binary Dataopt | BINARY_DATA | — | |
| DCI Image 1opt | DCI_IMAGE_DATA | — | |
| DCI Image 2opt | DCI_IMAGE_DATA | — | |
| DCI Image 3opt | DCI_IMAGE_DATA | — | |
| DCI Image 4opt | DCI_IMAGE_DATA | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| DCI Binary Data | BINARY_DATA | — |