1. moss-image.com
  2. 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

SymptomMost likely causeFix
Faint vertical color stripesSFT artifactDestripe or DeBand LoRA, or use Base
Pure noiseModelSamplingSD3 nodeUse ModelSamplingAuraFlow or ModelSamplingFlux
Completely black image--bf16-vae on some dev buildsDrop the flag or update ComfyUI
“Could not detect model type”, missing MOSS nodesComfyUI older than 0.42.0Update to 0.42.0 or later
'NoneType' object has no attribute 'dtype'Comfy-Org file in the old plugin loaderUse the native Load Diffusion Model node
Cannot convert a MPS Tensor to float64Apple SiliconCPU timestep patch
Out of memorybf16 files on a small GPUint8 model, w4a8 text encoder, or GGUF
Misspelled textUnquoted text, low CFG, enhancerQuote the words, CFG 3, 50 steps
Layout boxes ignoredPrompt enhancer on, canvas mismatchEnhancer 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):

  1. 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.
  2. MATLOWAI DeBand — linked from the official README. Start with moss_image_sft_banding_fix_L37-41_bf16.safetensors at 1.0. For wide images or large skies, add moss_image_sft_banding_fix_L32-36_extra_bf16.safetensors at 1.0. A stronger full LoRA exists but changes the picture more.
  3. 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:

PartSmallest common optionFull precision
Diffusion modelint8 ConvRot, 5.41 GB (GGUF Q4: 3.2–3.4 GB)bf16, 10.16 GB
Text encoder (Qwen3.5-9B)w4a8 GPTQ, 7.34 GBbf16, 19.31 GB
VAEflux2-vae_small, 0.25 GBflux2-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_convrot and qwen3.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.

Sources