EmptyChromaRadianceLatentImage
The pixel-space Chroma blank
- LATENT
EmptyChromaRadianceLatentImage creates the blank starting latent for Chroma Radiance - the pixel-space branch of Chroma. If you've used the mainstream Chroma checkpoints (Base, HD, Flash), those are ordinary latent-space models with a compressed, multi-channel latent. Radiance is the odd sibling: it generates in pixel space, like HiDream-O1, which means this node builds a [batch_size, 3, height, width] tensor at full resolution. Three channels. No downscale. The "latent" is the picture.
The three inputs are the usual size trio: width (default 1024, step 16, up to 16384), height (same defaults), and batch_size (default 1, up to 4096). Output is a LATENT that feeds the sampler. Nothing else to configure - this is the "how big is the canvas" node, and the interesting part is the whole architecture context around it.
Why Radiance exists
Radiance is LodestoneRock's answer to the thing latent-space Chroma can't fix. The core Chroma models are built on FLUX.1 Schnell's lineage, and they inherit its latent-space quirks - the stripe/line artifacts people chase with LoRAs, the resolution sensitivity. Radiance skips the latent entirely: no VAE to round-trip through, no compression loss to accumulate across edit passes. The community argument for pixel-space is essentially "VAE was always just a workaround for pixel-space inference being too slow," and Radiance is that workaround being re-examined. As of this writing Radiance is still officially a work-in-progress - Base/HD are the recommended Chroma checkpoints, and this node exists for the pixel-space line that's iterating alongside them.
The gotchas that matter
First: no VAE, and don't add one. A Radiance workflow has no VAE loader and no VAE decode; the sampler outputs pixels. Second: the full-resolution blank is expensive. Every denoising step runs on a 3-channel tensor at your chosen resolution, so a 2048² Radiance canvas costs dramatically more VRAM and time than the same output from a latent-space model - pixel-space compute scales with pixels, which is the exact trade Chroma Radiance accepts to get the artifact-free benefit. Third: it's the Radiance flavor. Loading this into a workflow with a Chroma HD checkpoint and wondering why dimensions don't line up is mixing two different generations of the same family - they don't share a latent space because one doesn't have one.
It ships with ComfyUI core - no install, no model files of its own; the Chroma Radiance checkpoint is the download that matters. If you're coming from Chroma HD, treat this as a different model, not an update to your existing workflow.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| width | INT | 102416–16384 | — |
| height | INT | 102416–16384 | — |
| batch_size | INT | 11–4096 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| LATENT | LATENT | — |