DEV Community: MossImage Studio

MOSS-Image in ComfyUI: which files go where (and the two settings to change)

MossImage Studio — Fri, 13 Nov 2026 13:33:00 +0000

MOSS-Image is OpenMOSS's 5B open-weights text-to-image model, released on October 16, 2026 under Apache-2.0. Two things make it unusual: it renders Chinese and English text inside the image, and it follows JSON layouts for where things go. ComfyUI merged native support the same day (pull request #17095), so there is no custom node pack to install and nothing to pip.

That means the only real work between you and a first image is getting four files into four folders, and changing two settings that the templates get wrong on purpose.

I keep the long version — all six official templates, the edit and color & depth LoRAs, the text encoder, LoRA training — in the MOSS Image ComfyUI workflow guide. This post is the short path.

Check your ComfyUI version first

The four text-to-image templates need ComfyUI 0.42.0 or later. The Image Edit and Color & Depth templates were added on October 26 and need 0.43.0 or later.

The v0.41.3 release did not include native support, so an older install does not fail loudly — it reports missing nodes or a template that is not in the library at all.

The fastest check: open a Load CLIP node and look at the type dropdown. If moss_image is not there, your install predates support and you should update before downloading anything.

The four files

All ComfyUI-format weights live in the Comfy-Org/MOSS-Image repository on Hugging Face. The text-to-image templates load exactly these:

File	Goes into	Size	What it is
`moss_image_sft_int8_convrot.safetensors`	`models/diffusion_models/`	5.41 GB	SFT checkpoint — use this one to make images
`moss_image_base_int8_convrot.safetensors`	`models/diffusion_models/`	5.41 GB	Base checkpoint — for training, not for output
`qwen3.5_9b_w4a8_gptq.safetensors`	`models/text_encoders/`	7.34 GB	Qwen3.5 9B text encoder
`flux2-vae_small.safetensors`	`models/vae/`	0.25 GB	FLUX.2 small VAE

Budget the disk before you start: about 13 GB for the SFT text-to-image templates, or 18.4 GB if you also want the Base checkpoint. The Image Edit template adds 0.30 GB. The Color & Depth template adds about 12.6 GB, because it pulls in the MoGe 3 depth estimator as well.

Note that the text encoder is the biggest file you load, not the checkpoint. 7.34 GB against 5.41 GB. If you are sizing against VRAM, that ordering matters.

If you have the VRAM, bf16 builds of both checkpoints are in the same repository at 10.16 GB each. Pick one by swapping the file in the UNET Loader; nothing else in the graph changes.

Restart or refresh ComfyUI after dropping the files in, otherwise the loaders will not see them.

Your first image

Open Template, search for MOSS-Image, and pick MOSS-Image: Text to Image.
Type your idea into the positive prompt and hit Queue.
Open the Preview Any node. It shows the caption the model actually received.

Step 3 is the one people skip. The text-to-image template runs your prompt through a prompt upsampler that rewrites a short request into a full scene caption before sampling — it runs on the Qwen3.5 encoder the graph already loads, so there is nothing extra to download. A one-line idea works, but you are not seeing the wording that produced the image unless you look at Preview Any.

This prompt is a full caption already, so the sampler sees it close to how it was written:

A wide conference banner with the title "AI 开发者大会 2026" and the subtitle "AI Developer Summit". A clean blue and violet gradient background, abstract circuit lines, and a bottom row reading "10月28日 · 深圳 · Oct 28 · Shenzhen".

When you want full control of the wording, set enable_prompt_enhancer to false on the subgraph node. Your prompt then goes to the model unchanged.

The two settings to change

The templates are tuned for speed, which is the right default for a first render and the wrong default for a final one. These are OpenMOSS's own recommendations, and what the official examples use:

Setting	Template default	Official recommendation
Steps	25	50 or more
CFG	2.5	3 — for short prompts, 3 to 6
Sampler	`er_sde`	Euler (flow matching)
Canvas	1 MP	1, 1.5 or 2 MP, sides in multiples of 16

So: if a result looks undercooked, go to 50 steps at CFG 3 before you touch anything else. Width and height must be multiples of 16; the model is trained for 1 to 2 megapixels and extrapolates from roughly 0.25 MP (512×512) up to 4 MP.

Two things you do not need to change: shift is 5 and built into the native model, and skip layer guidance is already on at layer 22, the layer OpenMOSS recommends. Turning SLG off makes images look very realistic but can collapse fine detail.

The templates also pre-fill a negative prompt — nsfw, worst quality, bad anatomy, watermark, jpeg artifact. That list is OpenMOSS's, and it is fine to leave it alone.

One expectation to drop

The same seed will not reproduce a Diffusers image exactly. ComfyUI's native scheduler does not use the training-grid snapping that the official Python pipeline does, so identical seed and settings give a different but equivalent image. This is expected, not a bug, and it is worth knowing before you spend an evening bisecting a seed.

Where to go next

Layout control. The two layout templates add a box-drawing node where each box gets its own caption, and text boxes render their text. This is the most reliable way to put a title or a product shot exactly where you want it.
Base vs SFT. SFT for making images, Base for training. Loading Base and wondering why output is worse is a common detour.
LoRA training. KohakuMossTrainer, DiffSynth-Studio and ai-toolkit all support it. Keep the text encoder frozen, and cache the encoded captions once instead of every step.

If you would rather see what the model does before installing 13 GB, the browser generator runs MOSS-Image-SFT at the official 50 steps and CFG 3.

Full guide: MOSS-Image ComfyUI workflow — models, templates and settings.

Google only saw question 1 of my 100-question quiz

MossImage Studio — Sat, 03 Oct 2026 16:03:04 +0000

My quiz site shows one question at a time: a big card, Yes and No buttons, a progress bar. It's a nicer experience on a phone than a wall of 100 checkboxes. It also hid 99% of the page from search engines, and I only noticed because of a ranking that made no sense.

The symptom

Search Console showed two of my pages competing for the site's main keyword:

the homepage, which is the quiz, at an average position of about 45;
a plain "all questions" page, just a list with short notes, at about 28.

The list page has no quiz on it at all. So why was Google preferring it for a query where people clearly want to take the test?

Look at what the crawler gets

The first thing a crawler receives is the HTML your server sends. I fetched my homepage's HTML, stripped scripts and styles, and checked whether a handful of question texts were in what was left:

import html, re, urllib.request

def visible_text(url):
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    raw = urllib.request.urlopen(req).read().decode("utf-8", "ignore")
    raw = re.sub(r"(?is)<(script|style|noscript|svg)[^>]*>.*?</\1>", " ", raw)
    return html.unescape(re.sub(r"<[^>]+>", " ", raw))

probes = ["Held hands romantically", "Been on a date", "Kissed a non-family member",
          "Been convicted of a felony"]  # 8 in total, spread across the test
text = visible_text("https://example.com/")
print(sum(p in text for p in probes), "of", len(probes))

My homepage: 1 of 8. Then I ran the same check against the pages ranking in the top four for that keyword: 8 of 8, every one of them. My own list page: also 8 of 8.

Word count wasn't the difference. The #1 result had about 700 words of visible text, and my homepage had more. The difference was that every page Google ranked above mine put the whole test in its HTML, and mine put one question.

Why it happens

The quiz is a client component. Its state is "which question are you on", restored from localStorage so a refresh doesn't lose your place. At build time (this is a static export) there's no saved progress, so the prerendered HTML contains the initial state: question 1. The other 99 questions exist only as data inside the JavaScript bundle.

"But Google runs JavaScript." It does, but rendering the page doesn't change anything here. Googlebot doesn't click Yes or No, so the rendered DOM still shows one question. Any UI where content is revealed by interaction has the same problem: a step-by-step wizard, a carousel, tabs that mount their panels lazily.

The fix: render the state space as content

I didn't want to change how the quiz works. Instead, below the FAQ, the page now renders every question as a plain numbered list, in a server component:

// components/content/QuestionList.tsx — a server component, no 'use client'
export function QuestionList({ id, heading, intro, questions }: {
  id: string;
  heading: string;
  intro: React.ReactNode;
  questions: readonly string[];
}) {
  return (
    <section id={id} className="mt-12">
      <h2>{heading}</h2>
      <p>{intro}</p>
      <ol className="list-decimal pl-8 sm:columns-2 sm:gap-10">
        {questions.map((q, i) => (
          <li key={i} className="break-inside-avoid">{q}</li>
        ))}
      </ol>
    </section>
  );
}

// app/(en)/page.tsx
<Quiz />
{/* …about, scoring, FAQ… */}
<QuestionList
  id="all-questions"
  heading="All 100 questions"
  intro={<>The full list in the original order. The quiz above asks them one at a time.</>}
  questions={QUESTIONS}
/>

It's the same array the quiz uses, so the two can't drift apart. The list is useful for people too: some visitors want to see what's coming before they start. And it doesn't duplicate the dedicated questions page, because that page groups the questions by theme and explains the confusing ones; the homepage list links there.

Two columns on desktop keep the section from becoming a 100-line scroll. break-inside-avoid stops a long question from splitting across the columns.

Lock it in with a test

This kind of regression is invisible in the browser, because the page looks fine. So there's a test that renders the page and checks the list:

it('lists all 100 questions in their original order below the quiz', () => {
  const { container } = render(<HomePage />);
  const section = container.querySelector<HTMLElement>('#all-questions')!;
  const items = within(section).getAllByRole('listitem').map((li) => li.textContent);
  expect(items).toEqual([...QUESTIONS]);
});

After deploying, I re-ran the probe against the live page: 8 of 8, and visible text went from about 860 words to about 1,520. Then I requested reindexing in Search Console. I applied the same fix to the French version and to the two shorter variants, which had the identical problem.

I don't have ranking results yet, as it's been a few days. What I'm confident about is the diagnosis: for a query whose intent is "take this test", every competitor that outranked the page served the test's content in HTML, and the page didn't.

The takeaway

If your page's main content is state, the questions of a quiz or the steps of a wizard, prerender the whole state space somewhere on the page as ordinary HTML. Then check it the boring way: fetch the HTML, strip the scripts, and search for your content. It takes five minutes and it would have saved me two weeks.

The site is ricepuritytestup.com. (It's my site. The quiz asks personal yes/no questions; your answers are scored in your browser and stay there.)

Adding a second language to a static Next.js site without changing a single URL

MossImage Studio — Wed, 30 Sep 2026 16:10:37 +0000

My small quiz site started English-only: a Next.js App Router project, output: 'export', deployed as static files. When I added a French version, I had three rules:

No English URL could change. They were already indexed.
Each page had to declare its real language in <html lang>.
No i18n middleware — a static export has no server to run it.

Here's the setup that satisfied all three, plus the one gotcha that cost me an afternoon.

Why a subdirectory, not a subdomain

/fr rather than fr.example.com or a separate domain. A subdirectory shares the domain's existing authority, so the French pages didn't start from zero in search. That turned out to matter: a few days after launch, the French pages were getting impressions faster than the English ones had.

Two route groups, two root layouts

The App Router lets a route group have its own root layout. Route groups (folders in parentheses) don't appear in the URL, so this moves nothing:

app/
  (en)/
    layout.tsx        ← <html lang="en">
    page.tsx          → /
    questions/page.tsx → /questions
  (fr)/
    layout.tsx        ← <html lang="fr">
    fr/page.tsx       → /fr
  not-found.tsx

Each root layout renders its own <html> and <body>, header and footer:

// app/(fr)/layout.tsx
export default function FrRootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="fr" className={`${fraunces.variable} ${sourceSerif.variable}`}>
      <body>
        <HeaderFr />
        <main>{children}</main>
        <FooterFr />
      </body>
    </html>
  );
}

Moving the existing English files into app/(en)/ was the whole migration. Every English URL stayed byte-for-byte the same.

The gotcha: your 404 page loses its layout

With a single root layout, app/not-found.tsx renders inside it and inherits your fonts, styles and header. With multiple root layouts, there is no single layout for the global 404 to sit in — Next renders it on its own. Mine silently fell back to an unstyled page with none of my CSS.

The fix is to make not-found.tsx a complete document itself:

// app/not-found.tsx
import './globals.css';

export default function NotFound() {
  return (
    <html lang="en" className={`${fraunces.variable} ${sourceSerif.variable}`}>
      <body>
        <main>
          <h1>Page not found</h1>
          <Link href="/">← Take the test</Link>
          <Link href="/fr">Version française →</Link>
        </main>
      </body>
    </html>
  );
}

It imports the stylesheet and sets up the fonts itself. On a static export this becomes 404.html, which the host serves for any unknown path in either language, so it links to both homepages.

A related trap caught me later: every page embeds the 404's React Server Components payload. When I verified deploys by grepping the HTML for a phrase like "Version française", every page "contained" it — it came from the 404 payload, not the page. Check something unique to the page, or the build status, instead.

hreflang only where a real twin exists

Only the two homepages are true translations of each other, so only they declare alternates, with a small helper:

export function alternateLanguages(paths: { en: string; fr: string }) {
  return {
    languages: { en: paths.en, fr: paths.fr, 'x-default': paths.en },
  };
}

// app/(en)/page.tsx and app/(fr)/fr/page.tsx
export const metadata = {
  alternates: { canonical: '/', ...alternateLanguages({ en: '/', fr: '/fr' }) },
};

The French-only pages (a teen version, a quick 30-question version) declare no hreflang at all. Pointing hreflang at an English page that isn't really the same content does more harm than good. The French metadata helper leaves languages out on purpose, and a test asserts it stays that way.

The language switch is just a plain <a href="/fr" hrefLang="fr"> in the header and footer. No JavaScript, no cookie, no redirect based on Accept-Language, so crawlers and users both see a stable page at every URL.

Ship only the language you need

The quiz is a client component. If it imported both question sets, every French visitor would download the English list too. Instead each server page passes a plain-data "variant" to it:

interface QuizVariant {        // trimmed to the relevant fields
  storageKey: string;          // 'rpt:progress:fr' — progress never collides across versions
  questions: readonly string[];
  bands: readonly ScoreBand[];
  ui: QuizUiStrings;           // every UI string, no functions (must serialise)
  sharePath: string;
}

// app/(fr)/fr/page.tsx (a server component)
<Quiz variant={FR_VARIANT} />

Because the variant crosses the server/client boundary as props, it has to be serialisable. That means no formatter functions, so strings use {score} placeholders filled on the client. The English variant lives in its own module so importing it never drags the French data into the English bundle.

French typography needs no-break spaces

French puts a space before ? ! : ;, and it must not wrap onto the next line. Source strings are written with ordinary spaces for readability, then converted once:

export const frenchSpacing = (text: string) => text.replace(/ ([?!:;])/g, '\u00a0$1');

One side effect showed up in tests. Testing Library's default text normalizer collapses whitespace, and \s includes the no-break space, so getByText(frenchString) failed even though the text was on the page. Passing { normalizer: (t) => t } for those assertions fixed it.

The site is ricepuritytestup.com, with the French version at /fr. (It's my site. The quiz asks personal yes/no questions, but your answers are scored in your browser and never sent anywhere.)

Sharing a canvas-generated image on iOS with the Web Share API

MossImage Studio — Sat, 26 Sep 2026 16:25:46 +0000

I run a small quiz site (a Rice Purity Test), and people mostly share their result as a screenshot in an Instagram or Snapchat story. So I added a "certificate": after the quiz, the browser draws a 1080×1920 PNG with the score on it, and a Share button hands it to the phone's share sheet.

Drawing the image was the easy part. Getting the share sheet to behave on iOS took more care. Here's what mattered, in case you're building something similar.

1. Generate the image before the tap, not after

The tempting flow is: user taps Share → draw the canvas → toBlob() → navigator.share(). On iOS Safari that's a trap. navigator.share() only works while the tap's user activation is still valid, and awaiting a canvas render (plus web fonts, see below) can use that up.

So the image is rendered as soon as the result appears:

useEffect(() => {
  let cancelled = false;
  let url: string | null = null;
  renderCertificate(cert)
    .then((blob) => {
      if (cancelled) return;
      url = URL.createObjectURL(blob);
      setState({ status: 'ready', cert, blob, url });
    })
    .catch(() => {
      if (!cancelled) setState({ status: 'failed', cert });
    });
  return () => {
    cancelled = true;
    if (url) URL.revokeObjectURL(url);
  };
}, [cert]);

The File is built ahead of time too, so the click handler reaches navigator.share() without awaiting anything:

const file = useMemo(
  () => (blob ? new File([blob], fileName, { type: 'image/png' }) : null),
  [blob, fileName],
);

A side benefit: the object URL doubles as the src of a small thumbnail <img>, so iPhone users can also long-press it and save it without touching the button.

2. Share the file on its own

The obvious call is navigator.share({ files: [file], text, url }). On iOS, some share targets then take the link instead of the picture, and "Save Image" disappears from the sheet. Sharing only the file fixed it:

navigator.share({ files: [file] }).catch((error) => {
  if (!isHarmless(error)) downloadFile(url, fileName);
});

The site address is printed at the bottom of the certificate instead, so the image still points back to the site wherever it ends up.

3. Feature-detect with canShare, fall back to a download

Most desktop browsers can't share files. navigator.canShare({ files: [file] }) tells you up front, and the button label switches between "Share" and "Save image":

const canShareFiles =
  typeof navigator.share === 'function' &&
  typeof navigator.canShare === 'function' &&
  navigator.canShare({ files: [file] });

The download fallback is the classic temporary anchor:

function downloadFile(url: string, fileName: string) {
  const a = document.createElement('a');
  a.href = url;
  a.download = fileName;
  document.body.appendChild(a);
  a.click();
  a.remove();
}

4. Not every rejection is an error

navigator.share() rejects when the user simply closes the sheet (AbortError), and also when they tap Share again while the sheet is still open (InvalidStateError). Neither should trigger a download, so both are ignored:

function isHarmless(error: unknown): boolean {
  const name = (error as { name?: unknown } | null)?.name;
  return name === 'AbortError' || name === 'InvalidStateError';
}

Anything else falls back to downloading the image.

5. Canvas doesn't wait for your web fonts

Canvas draws with whatever font is available at that moment. If the web font hasn't loaded yet, you silently get the fallback. Two things made this work with Next.js:

next/font gives each font a hashed family name. The layout exposes it as a CSS variable on <html>, so the canvas code reads that variable instead of hard-coding a family name.
Before drawing, it waits for document.fonts.load() for each face, capped at 3 seconds. After that it draws anyway, because a certificate in Georgia is better than no certificate.

function siteFonts() {
  const style = getComputedStyle(document.documentElement);
  const family = (variable: string, fallback: string) => {
    const value = style.getPropertyValue(variable).trim();
    return value ? `${value}, ${fallback}` : fallback;
  };
  const display = family('--font-fraunces', 'Georgia, serif');
  // …the body and mono faces are read the same way
  return { display: (px: number) => `600 ${px}px ${display}` /* , body, mono */ };
}

async function waitForFonts(fonts) {
  if (typeof document.fonts?.load !== 'function') return;
  const loads = [fonts.display, fonts.body, fonts.mono].map((at) =>
    document.fonts.load(at(48)).catch(() => []),
  );
  await Promise.race([
    Promise.all(loads),
    new Promise((resolve) => setTimeout(resolve, 3000)),
  ]);
}

6. Fitting text without a loop

Some lines are long (the site also has a French version, and labels like "Très expérimenté" run wider), so each line shrinks to fit the frame. Text width grows linearly with font size, so there's no need to step the size down in a loop. One measurement is enough:

export function fitFontSize(measure, text, maxWidth, startPx, minPx) {
  const width = measure(text, startPx);
  if (width <= maxWidth) return startPx;
  return Math.max(minPx, Math.floor((startPx * maxWidth) / width));
}

measure is passed in instead of calling the canvas directly, so the layout maths can be unit-tested in jsdom, which has no canvas.

If drawing fails, nothing breaks

If there's no canvas, toBlob() returns null, or anything throws, the certificate block isn't rendered at all and the result card falls back to the old text-and-link share button. Nobody sees a broken image.

You can try it at ricepuritytestup.com: finish the quiz and the certificate appears under your score. (It's my site. The questions are personal yes/no ones, but everything is scored in your browser and nothing you answer is sent anywhere.)