OpenMOSS has published code and weights for MOSS-Image-Base and MOSS-Image-SFT, giving developers a 5B-parameter DiT text-to-image model with a documented JSON layout-prompt format. The practical consequence is that text placement and composition can be expressed as structured input rather than left entirely to a natural-language prompt. The project repository describes the model as targeting text rendering, layout generation and efficient fine-tuning.
Two published variants and conventional entry points
The repository lists MOSS-Image-Base as its base text-to-image model and MOSS-Image-SFT as a version fine-tuned from the base on curated data. It provides a Python example built around diffusers.DiffusionPipeline, and documents a Gradio application for local use. The same repository also says MOSS-Image is supported natively in ComfyUI, with built-in loaders for ComfyUI-format weights.
For inference, the documented defaults are Flow-matching Euler sampling, 50 steps, CFG 3, shift 5, and negative-branch skipping at layer 22. These are project recommendations, not independent performance measurements. The repository's sampling table also documents GPU-resident, component offload and sequential memory modes, with sequential mode trading inference speed for lower memory use.
Layout is part of the prompt interface
MOSS-Image's most concrete control mechanism is a JSON input format containing a scene summary and an items array. Each item can include a label, description, optional text to render and a bounding box; the documented example uses centralized pixel coordinates and a yxyx box format. The layout guide in the repository instructs users to match those coordinates to the requested output dimensions and to pass the JSON as the prompt string in the Python API.
That makes the interface suitable for tooling that already has deterministic scene metadata—for example, an editor that knows where a headline or illustration should sit. It does not establish that a generated image will exactly obey every coordinate or render every string correctly; the repository presents examples and capability claims, but no evaluation methodology or benchmark results in the supplied documentation. The project page characterizes text rendering and layout control as key highlights.
Analysis: The useful distinction here is between a model that can be asked for a layout and one whose layout can be represented, stored and edited as data. MOSS-Image documents the latter interface, which could make generation pipelines easier to integrate with design tools. The unresolved trade-off is reliability: developers will still need their own validation loop for text accuracy, box adherence and composition quality because the repository does not supply quantitative evidence for those properties. The documented JSON workflow supports structured authoring, while the page's stated capabilities remain project claims.
Fine-tuning and licensing boundaries
The repository says community tooling includes full fine-tuning and LyCORIS training, including LoRA, for both model variants. It specifically points to KohakuMossTrainer, which the project says supports several precision modes, multi-GPU approaches and adapter training with as little as 6GB of VRAM. Those details appear in the repository's release notes, so teams should verify the linked trainer and its hardware assumptions before treating that memory figure as a deployment requirement.
The standalone pipeline code is released under the Apache License 2.0. The repository license section does not, in the supplied page text, separately spell out the terms governing every published model weight or every third-party community artifact. Developers planning redistribution or commercial deployment should therefore check the relevant weight and dependency terms rather than infer them from the pipeline-code license alone.
Top comments (0)