Images and depth combined in the Iris-Z model

A single model generates images and estimates depth. Its reported gains over MoGe-3 rely on combining multiple predictions.

A photograph can become a depth map, which can then guide the generation of another image. These operations use the same weights in Iris-Z, Speridlabs’ model for scene appearance and geometry. Given a text prompt, it can also produce an image alone or an image accompanied by its depth map.

The resulting geometry describes relative distances. It helps distinguish nearby and distant elements within a view, but provides neither measurements in meters nor camera parameters. The evaluations cover individual images and their depth, without testing consistency across multiple viewpoints or video frames. A shared network for appearance and geometry

The architecture adapts an image generator from the FLUX.2 family. Depth is represented in normalized logarithmic form, then encoded using the same autoencoder as the image. Text, appearance, and depth enter a shared sequence processed by the diffusion transformer. The two visual representations can therefore condition each other during generation, without a separate network dedicated to depth estimation.

The two released variants have 9.1 billion and 32.2 billion parameters. According to the SDK’s estimates, running the full set of tasks requires approximately 33 GB of GPU memory for the smaller variant and 112 GB for the larger one. Depth estimation alone can load the network without the text encoder, since that operation requires no written instruction. Lower error requires more computation

The evaluation tables published alongside the weights compare results under two protocols. Across the five datasets used in Marigold V2’s evaluation, the larger variant achieves a mean absolute relative error of 2.92, compared with 3.12 for MoGe-3, after multiplication by 100. Lower values indicate better estimates. This number is not the percentage of images analyzed correctly.

Across seven of the nine datasets in MoGe-3’s protocol, the respective averages are 3.56 and 3.70. The larger variant leads on six of those seven datasets but trails on DIODE. The smaller variant scores 3.84 in the same table. The two protocols use different methods to align predictions with reference data, so their averages are not directly interchangeable.

These scores use ten predictions with different initializations, combined using a median. With four steps per prediction, the calculation requires forty passes through the network. In the technical report, the larger variant takes approximately fifteen seconds per 512 × 512 image on an H200 GPU, compared with approximately 0.4 seconds for MoGe-3 on the same hardware. The SDK lists 1.44 seconds using a single initialization for that variant and image size: this faster setting is not the one used for the highlighted scores. Apache 2.0 applies to the code

The SDK repository contains inference code and a demo under Apache 2.0. The launch post also presents the weights as covered by that license, but the distribution documents establish an important distinction.

The NOTICE file states that the weights derive from FLUX.2 and are distributed under the FLUX Non-Commercial License. The Hugging Face model card displays the same license. These are therefore open weights models with commercial-use restrictions separate from the rights granted for the code. Installation also requires accepting the access terms for the FLUX.2 autoencoder used by the SDK. Image generation retains its own trade-offs

Fine-tuning changes the original model’s output. In the report’s internal measurements, the larger variant’s HPSv2.1 score, a learned measure intended to estimate human preference, falls from 26.71 to 24.30. Text-to-image alignment declines slightly, while the photorealism indicator increases. Better depth estimation therefore does not translate into uniform improvements across image-generation criteria.