Iris-3B Pixel-Space Generation: Local Setup and Image Quality Guide

Explore Iris-3B pixel-space generation, depth and restoration. Follow local setup, budget model memory and test image detail without inventing quality results.

Fan Chuanyu's profile

Written by Fan Chuanyu

•5 min read
Iris-3B Pixel-Space Generation: Local Setup and Image Quality Guide

Iris-3B generates images directly in pixel space and also provides fine-tuned checkpoints for depth estimation and image restoration. For a developer exploring open image models, its appeal is the ability to study these tasks through one model family. The useful evaluation starts by choosing a task and preserving its exact inference settings.

The official model card and reviewed code repository provide the release and setup details. Our cover is a concept illustration, not an output produced by Iris-3B.

What Iris-3B pixel-space generation changes

Many diffusion systems generate a compressed representation and use a separate decoder to turn it into pixels. Iris-3B uses a pixel-space backbone and does not require a VAE for that conversion. This is an architectural difference, not a universal quality ranking.

The project identifies a three-billion-parameter diffusion transformer. Its text-to-image pipeline also uses a frozen Qwen3-VL-4B-Instruct text encoder, so the image backbone's size alone does not describe the whole pipeline's storage and memory.

Released taskCheckpoint roleEvaluate against
Text-to-imageGenerates an image from a promptPrompt adherence and visible detail
Monocular depthEstimates relative depthAppropriate reference depth and ordering
Restoration and upscalingProduces a restored larger imageDetail preservation and unwanted changes

The depth and restoration versions are fine-tuned artifacts. Downloading the text-to-image checkpoint does not automatically make it the correct model for every downstream task.

Install the reviewed generation path

The repository specifies Python 3.11 or later and PyTorch 2.7.1 or later. Use a dedicated environment so that an experimental image pipeline does not replace libraries used by another application.

git clone https://github.com/speridlabs/iris-3b.git
cd iris-3b
git checkout a8d15239dea469aba042cfa56ca3bb4e450d5ebc
pip install -e .
hf download speridlabs/iris-3b \
  --revision 7445443349bc9abe3c96f01ff793e2098ca012b3 \
  --local-dir iris-3b
python scripts/sample.py --checkpoint iris-3b \
  --prompt 'A blue ceramic cup on a wooden table, soft daylight, plain background'

The sample script expects a release directory containing the checkpoint files and configuration, or a compatible training checkpoint. Do not substitute an unrelated image model file just because it uses the same extension.

The reviewed defaults are 1024 × 1024 output, 100 DPM-Solver++ steps and CFG 3. Record these alongside the seed and prompt. The repository exposes controls for steps, seed and negative prompt; changing several at once makes comparison harder.

These commands describe the published workflow. They are not evidence that the model has been run on the reader's GPU, nor a promise that a particular consumer card has enough memory.

Compare images with controlled prompts

Choose prompts that reveal the property you need. A product illustration might need a recognizable object shape, a consistent material and clean edges. An editorial scene might prioritize composition and a clear subject. A single attractive landscape cannot answer both questions.

Keep a small prompt set with fixed settings and seeds. Inspect each output at the intended display size and at a closer crop. Look for broken edges, repeated textures, missing objects and changes that conflict with the brief. Record failures rather than selecting only the strongest image.

When comparing against another model, preserve the same creative brief but respect each pipeline's documented setup. Equal sampling-step counts do not necessarily mean equal compute or comparable quality across architectures. Record total generation time and how many attempts produced an acceptable image.

Avoid assuming that direct pixel generation reproduces an object more faithfully in every case. Architecture suggests useful tests; the tests still need to establish whether those benefits appear in your subject matter.

Our Chinese image-model alternatives guide supplies another comparison context. Use it to choose alternatives for the same reader task rather than treating all image pipelines as identical products.

Keep depth and restoration tasks separate

The depth script returns relative log depth, not metric distance. A visually convincing colored depth map should not be interpreted as a calibrated measurement of meters. If your evaluation needs ground-truth comparison, use the scale and alignment procedure appropriate to the relative output.

The restoration checkpoint follows a different inference path from text-to-image generation. The repository provides a four-times upscaling workflow with tile handling for larger images. Inspect the restored output against the original for altered lettering, textures and small features.

A larger output can be sharper while adding details that were not in the source. Define which changes are acceptable for the job. For a creative background, plausible new texture may be useful; for a documentary image or product label, invented detail can defeat the purpose.

Keep separate records for each task: checkpoint, input, configuration and acceptance rule. That prevents a favorable text-to-image result from being used as evidence about depth accuracy or restoration fidelity.

Plan memory and recurring generation work

The repository's demo notes describe roughly 45GB of GPU memory when all three models are loaded together. Its offloading mode keeps models on the CPU and moves the requested one to the GPU, with a documented peak around 20GB in that setup. Those figures describe the demo configuration, not a universal minimum for every script and device.

Start with only the task you need. Measure model loading, generation and any transfers separately, then repeat at the same settings. Offloading can make a workflow fit while adding transfer delay; include that delay when deciding whether repeated local runs are practical.

Also budget disk space for the selected checkpoint and its dependencies. Maintain a revision record if you later update the code or weights, so that an output change has an identifiable cause.

The release lists Apache-2.0 for its code and model weights, while its dependency table identifies additional components. Preserve the relevant notices and review those components for the application you are building.

Conclusion: evaluate Iris-3B one task at a time

Iris-3B offers a useful pixel-space generation and vision research workflow when its memory requirements fit the environment. Begin with the documented sample, keep settings reproducible and judge results against the intended image task. Treat depth and restoration as separate evaluations with their own checkpoints and definitions of success.

Frequently asked questions

Does no VAE mean no additional model components?

No. The text-to-image pipeline still uses a text encoder and other runtime components. The backbone size does not represent the entire pipeline.

Does the depth output give real-world distance?

The reviewed repository describes relative log depth, not metric distance. Use an appropriate evaluation and alignment method.

Can a 3B image model always fit on a small GPU?

The parameter label alone cannot establish that. Include the text encoder, precision, buffers and request configuration in memory planning.

Share: