- moss-image.com
- Troubleshooting
Fixing common MOSS-Image problems
Vertical stripes, pure noise, black images, missing nodes, Mac errors and out-of-memory crashes: what causes each one and the fix that is confirmed to work.
Most MOSS-Image problems come from a handful of causes: an old ComfyUI, the wrong shift node, SFT's stripe artifact, or too little memory. Find your symptom below. Each fix links to the issue or model card where it was confirmed, and we say when a fix is community-reported rather than official.
Just want an image? The online generator runs the same model with none of this setup.
Quick reference
| Symptom | Most likely cause | Fix |
|---|---|---|
| Faint vertical color stripes | SFT artifact | Destripe or DeBand LoRA, or use Base |
| Pure noise | ModelSamplingSD3 node | Use ModelSamplingAuraFlow or ModelSamplingFlux |
| Completely black image | --bf16-vae on some dev builds | Drop the flag or update ComfyUI |
| “Could not detect model type”, missing MOSS nodes | ComfyUI older than 0.42.0 | Update to 0.42.0 or later |
'NoneType' object has no attribute 'dtype' | Comfy-Org file in the old plugin loader | Use the native Load Diffusion Model node |
Cannot convert a MPS Tensor to float64 | Apple Silicon | CPU timestep patch |
| Out of memory | bf16 files on a small GPU | int8 model, w4a8 text encoder, or GGUF |
| Misspelled text | Unquoted text, low CFG, enhancer | Quote the words, CFG 3, 50 steps |
| Layout boxes ignored | Prompt enhancer on, canvas mismatch | Enhancer off, same width and height |
Vertical stripes on SFT
Symptom: faint vertical bands of color, easiest to see in skies, walls, fog and plain backdrops. At 1024 px wide they are about 21 px apart; at 768 px, about 16 px.
Cause: an artifact of the SFT checkpoint. Users report Base does not show it, whichever VAE they use. OpenMOSS has not replied in either discussion thread yet, so treat any explanation of why as unconfirmed.
Fixes (all community LoRAs for SFT only; load with LoraLoaderModelOnly):
- nynxz Destripe —
loras/moss_sft_destripe_top64_bf16.safetensors, only 1.9 MB. Strength 1.0 at 768 px and 1.5 at 1024 px; its author notes 1.0 leaves a faint trace in about half of 1024 px images. The gentlest option. - MATLOWAI DeBand — linked from the official README. Start with
moss_image_sft_banding_fix_L37-41_bf16.safetensorsat 1.0. For wide images or large skies, addmoss_image_sft_banding_fix_L32-36_extra_bf16.safetensorsat 1.0. A stronger full LoRA exists but changes the picture more. - Switch to Base. It avoids the artifact entirely, at the cost of SFT's cleaner text grouping. Raise CFG toward 4–5 for short prompts.
No sampler, step or CFG setting has been shown to remove the stripes on its own. Text has barely been tested with these LoRAs, so proofread lettering after enabling one.
Pure noise in ComfyUI
Symptom: the output is random static, or KSampler fails with a dtype error.
Cause: setting shift with the ModelSamplingSD3 node. A ComfyUI maintainer closed issue #17119 with exactly this answer.
Fix: replace it with ModelSamplingAuraFlow or ModelSamplingFlux (shift 5). The built-in MOSS-Image templates already do this, so starting from a template is the simplest fix.
Completely black images
Symptom: every render is solid black, sometimes with RuntimeWarning: invalid value encountered in cast in the console.
Cause: on ComfyUI development builds around commit d07dff45, the fused FLUX.2 VAE returned NaN when decoding in bf16 (issue #17317).
Fix: remove --bf16-vae from your launch flags, or update ComfyUI. The reporter confirmed commit fb3befd1 on master fixed it.
“Could not detect model type” and missing nodes
Symptom: RuntimeError: ERROR: Could not detect model type of: …moss_image_…safetensors, the CLIP loader rejects the moss_image type, or a workflow reports missing MOSS-Image nodes.
Cause: ComfyUI is older than 0.42.0, the first stable release with native MOSS-Image support (18 October 2026). Version 0.41.x does not have it.
Fix: update through ComfyUI Manager, or git pull and then pip install -r requirements.txt so the separate templates package updates too. Native workflows need no custom node. A missing MOSSImageHFLoader belongs to the older OpenMOSS plugin; use the native template instead. See the ComfyUI guide for the four files and where they go.
“'NoneType' object has no attribute 'dtype'”
Symptom: AttributeError: 'NoneType' object has no attribute 'dtype' when loading a model.
Cause: the Comfy-Org single-file checkpoints store attention weights fused, but the old OpenMOSS plugin's loader expects them split (OpenMOSS issue #10).
Fix: load Comfy-Org files with ComfyUI's native Load Diffusion Model node. Only use the plugin with the full Diffusers folder.
Out of memory and low VRAM
OpenMOSS has not published an official VRAM requirement. What you load is what counts. File sizes from Comfy-Org/MOSS-Image and unsloth's GGUF builds:
| Part | Smallest common option | Full precision |
|---|---|---|
| Diffusion model | int8 ConvRot, 5.41 GB (GGUF Q4: 3.2–3.4 GB) | bf16, 10.16 GB |
| Text encoder (Qwen3.5-9B) | w4a8 GPTQ, 7.34 GB | bf16, 19.31 GB |
| VAE | flux2-vae_small, 0.25 GB | flux2-vae, 0.34 GB |
ComfyUI does not hold everything on the GPU at once; it offloads what does not fit, which is slower but works. To fit a smaller card:
- Use
moss_image_sft_int8_convrotandqwen3.5_9b_w4a8_gptq, the pair the official templates load. - Generate at 1 MP (1024 × 1024) before going larger.
- GGUF is an option for very small cards, but ComfyUI's maintainers recommend int8 over GGUF for speed.
There is no verified per-GPU benchmark yet, so we do not quote seconds per image for specific cards.
Mac (Apple Silicon): “Cannot convert a MPS Tensor to float64”
Symptom: TypeError: Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64.
Cause: the Diffusers pipeline builds its timestep embedding in float64, which MPS does not support.
Fix (OpenMOSS issue #23, community patch, not merged yet): compute the sinusoid on the CPU, then move it back.
freq = 10000 ** (-torch.arange(half, device="cpu", dtype=torch.float64) / half)
phase = times.detach().cpu().double()[:, None] * freq
embedding = torch.cat((phase.cos(), phase.sin()), -1).float().to(times.device)
Use .cpu().double(); the reporter found .to("cpu", torch.float64) silently returns zeros on MPS, which produces noise. With this patch an M5 Pro with 64 GB rendered 1024 × 1024 at 25 steps and CFG 2.5 in 89 seconds. No working report exists for 16 GB Macs yet.
Misspelled or garbled text
From the official user guide and our own runs:
- Quote the exact words you want rendered.
- Break lines yourself with real line breaks inside the quotes.
- Use CFG 3 for long prompts (3–6 for short ones) and 50 steps. Very low CFG garbles text.
- Turn the prompt enhancer off when the wording must be exact; it rewrites your prompt.
- English is the safest language for the description; the rendered text can be Chinese or English.
- Few-step LoRAs trade text accuracy for speed. Use full steps for final lettering.
More patterns are in the prompt library.
Layout boxes ignored
- Keep the prompt enhancer off in layout workflows; it can drop the boxes.
- Generate at the same width and height the layout was written for, both multiples of 16.
- Coordinates are
[y_min, x_min, y_max, x_max]with the canvas center as origin and y pointing down. Our layout editor writes them for you; the layout guide explains the math.
Soft, blurry backgrounds
Several users report a strong default depth of field. There is no verified fix yet, and nobody from OpenMOSS has answered. Describing the scene as sharp throughout (“deep focus, everything in focus”) is worth trying, but we have not measured how much it helps.
Slow generation
The quality default is 50 steps. Community few-step LoRAs, such as lodestones' 8-step DMD, cut that to 4–8 steps with CFG 1, but they change the image noticeably and can misspell text. No official distilled model exists yet; OpenMOSS says it is working on one.
Editing an existing photo
The official models are text-to-image only. A community edit LoRA works on ComfyUI's development branch (support merged 22–23 October 2026, not yet in a stable release). Our online generator does not offer editing.
Where Hugging Face downloads go
The OpenMOSS scripts use the Hugging Face cache. To put the 27 GB Diffusers repo elsewhere, set HF_HUB_CACHE=/path/to/cache before launching, or download to a folder with hf download OpenMOSS-Team/MOSS-Image-SFT --local-dir /path and point the app at it.
How we checked this guide: every fix links to the issue, discussion or model card where it was reported, and we label community fixes as such. Last checked 27 October 2026. We have not reproduced these fixes on our own GPU.
Questions
Why does MOSS-Image SFT have vertical stripes?
It is a known SFT-only artifact: faint color stripes about 21 px apart at 1024 px wide. Base does not show it. OpenMOSS has not commented yet. A community Destripe LoRA (strength 1.0 at 768 px, 1.5 at 1024 px) removes it in most images, or switch to Base.
Why does MOSS-Image output pure noise in ComfyUI?
Usually because the workflow uses the ModelSamplingSD3 node to set shift. A ComfyUI maintainer confirmed this; use ModelSamplingAuraFlow or ModelSamplingFlux instead, or start from the built-in MOSS-Image template.
Why are my MOSS-Image results completely black?
On some ComfyUI development builds from late October 2026, the fused FLUX.2 VAE returned NaN in bf16. Remove the --bf16-vae launch flag, or update: the reporter confirmed a later master commit fixed it.
How much VRAM does MOSS-Image need?
OpenMOSS publishes no official figure. The int8 diffusion model is 5.41 GB and the smallest Comfy-Org text encoder is 7.34 GB, and ComfyUI offloads what does not fit. GGUF builds go down to about 3 GB for the diffusion model. Expect slower runs on 8 GB cards.
Does MOSS-Image run on a Mac?
Yes, through Diffusers on Apple Silicon with a small patch: the timestep embedding uses float64, which MPS does not support. A reported fix computes it on the CPU. One M5 Pro with 64 GB rendered 1024 × 1024 at 25 steps in 89 seconds.