MOSS-Image Restoration + FLUX 3 Klein 4K in ComfyUI: One Complete AI-KSK Workflow
MOSS-Image Restoration + FLUX 3 Klein 4K in ComfyUI: An AI-KSK Workflow Walkthrough
An AI image-restoration workflow can do more than feed a photograph into a generic upscaler. Sometimes the goal is to reconstruct a reference image's composition and style—its people, typography, lighting, and spatial arrangement—using a new generative pass, and only then create a higher-resolution version. That is the design behind AI-KSK's video 325 workflow: MOSS-Image-SFT → optional FLUX 3 Image Klein reconstruction at a 3840-pixel longest side, with Gemini-powered visual description in both stages.
This tutorial is based on the creator's subtitle transcript and an inspection of the actual supplied ComfyUI graph (洗图最终 (4).json: 35 nodes, 43 serialized links), not an independent execution, benchmark, or review of the original video stream. The promotional cover is illustrative; it is not a verified before/after measurement. You receive one workflow, not separate MOSS and FLUX workflow files.
Start here: the workflow and the complete video
Run or inspect the creator's online workflow on RunningHub: MOSS-Image Wash/Rebuild — AI-KSK. The URL includes the creator's invitation code and may support the creator. RunningHub access, included nodes, charges, and current runtime availability are subject to the platform.
Full video lesson: AI-KSK video 325 on YouTube. Bilibili lesson is also available. The downloadable project contains the unmodified workflow JSON and its original 3:4 promotional cover; it does not contain the source reference image, generated results, model weights, or hosted-service credentials.
1. What “image washing” means here—and what it does not
In this workflow, “washing” describes image-to-image reconstruction driven by image analysis, not lossless repair. Gemini 3.1 Flash-Lite receives a preprocessed source image and produces a caption or a coordinate-based MOSS JSON Layout. The resulting text conditions MOSS-Image-SFT. The input image is also encoded into the MOSS latent space, but the MOSS sampler uses denoise=1.0: this is a complete generative denoising pass rather than a conservative pixel-perfect restoration. Treat it as reference-led regeneration, not an exact photographic clone.
MOSS-Image-SFT is the supervised fine-tuned MOSS-Image model, based on a 5-billion-parameter image-generation backbone. The OpenMOSS documentation describes natural-language prompting and structured layouts for spatial and text placement. In this project the input dimensions are read after preprocessing so the LLM can work with the relevant coordinate canvas, reducing—not eliminating—layout mismatch. <huggingface.co>
The second pass is a different task: RealESRGAN first scales the MOSS result; ImageScaleToMaxDimension sets the longest edge to 3840, and FLUX 3 Image Klein then reconstructs the upscaled reference using another visual caption. 3840 on the longest side is not a promise of exactly 3840×2160, nor evidence of recovered lost real-world details. The final image is generative and may change tiny text, faces, objects, or logos.
2. The actual pipeline, node by node
The uploaded graph has 35 nodes and five functional stages:
LoadImage (source JPG not included)
-> ImageScaleToTotalPixels (lanczos, 1 MP, resolution_steps=16)
-> GetImageSize -> StringFormat (width, height, mode)
-> RHLLMChatNode (Gemini 3.1 Flash-Lite preview)
-> CLIPTextEncode (MOSS positive condition)
-> MOSS-SFT KSampler -> VAEDecode -> SaveImage (MOSS output)
| ^
+-> VAEEncode -----+ (source image encoded; denoise=1.0)
|
+-> second RHLLMChatNode (caption of MOSS output)
+-> RealESRGAN_x4plus -> longest edge 3840
-> ReferenceMultiLatent + FLUX 3 Klein conditioning
-> FLUX KSampler -> VAEDecode -> SaveImage (4K-labeled output)
The graph also contains preview nodes, an easy showAnything text viewer, and a rgthree Image Comparer comparing the MOSS-stage and FLUX-stage images. The creator's video introduces an updated Midjourney-style MOSS LoRA as an optional idea; this particular supplied JSON contains no LoRA loader or LoRA application node. Do not advertise that LoRA as active in the downloadable graph.
Stage A — input normalization
Load your own image into LoadImage (node 272). The saved node points to a machine-specific JPG filename that is not included in the project. ImageScaleToTotalPixels (node 244) uses lanczos, megapixels=1 and resolution_steps=16. The preprocessed image is used for the reconstruction input, the vision call, and the measured dimensions. GetImageSize (254) provides the current width and height to StringFormat (255); these values are not manually locked to a fixed portrait/landscape shape.
The prompt asks Gemini to preserve observable subject count, spatial relationships, original visual medium, lighting and legible words. It expressly requests no user-side modification. This is a helpful default for rebuilding an existing composition; it is not a guarantee that text or faces will be exact.
Stage B — Gemini caption or MOSS JSON Layout
PrimitiveBoolean (271) controls format. In the actual supplied file, it is True: JSON Layout is enabled. This contradicts an older embedded Markdown note claiming the default is off. False requests an English scene caption; True requests JSON with summary, items, bbox_coord_space="abs_centralized" and bbox_format="yxyx". Item boxes are center-origin pixel coordinates [y_min, x_min, y_max, x_max], calculated against the measured target width/height. A structured prompt helps reason about placement, but the graph does not show a separate programmatic JSON validator.
The node is RHLLMChatNode (276), with model identifier google/gemini-3.1-flash-lite-preview, temperature 0.2, maximum tokens 4096, top-p 0.9, and fixed seed 9527. Its response goes to the MOSS text encoder and the easy showAnything viewer. The model identifier and service integration are as serialized, not a promise that the same endpoint is accessible through arbitrary local Gemini credentials. Image content is treated as data rather than instructions in its built-in system prompt.
Stage C — MOSS-Image-SFT regeneration
The actual loaders and sampler settings are:
| Component | Saved value |
| --- | --- |
| Diffusion model | moss_image_sft_int8_convrot.safetensors |
| Text encoder | qwen3.5_9b_bf16.safetensors, CLIP type moss_image |
| VAE | flux2-vae.safetensors |
| Skip-layer guidance | SkipLayerGuidanceDiTSimple, single layer 22, start 0, end 1 |
| Sampling | KSampler, seed 9527 fixed, 20 steps, CFG 3, euler, sgm_uniform, denoise 1.0 |
| Negative text | nsfw, worst quality, bad anatomy, watermark, jpeg artifact |
| Original-size-stage output prefix | AIKSK_MOSS_03_SINGLE |
The source image reaches VAEEncode, providing the latent input. The text/JSON response supplies positive conditioning; the encoded source is not the same as adding a separate MOSS image-vision conditioning node. The embedded project note mentions a “Vision route,” but TextEncodeMOSSImageVision does not exist in this actual 35-node graph. This is the standard-VAE version, not a separate vision-conditioned workflow.
The OpenMOSS model card documents a 50-step / CFG 3 reference example with layer-22 skipping. Twenty steps is this creator's saved configuration, not an official guarantee of equivalent fidelity. The creator describes personal experiments down to 20 steps in the supplied subtitles; the package provides no reproduced performance numbers. <huggingface.co>
Stage D — optional RealESRGAN → FLUX 3 Image Klein reconstruction
The MOSS decoded result is reused, not a new upload. ImageUpscaleWithModel uses RealESRGAN_x4plus.pth; ImageScaleToMaxDimension (264) then sets lanczos, largest_size=3840. A second RHLLMChatNode (268) looks at the MOSS output, not the initial input image, and writes a grounded full-scene caption emphasizing plausible material and detail improvements without deliberate composition changes. Saved settings: google/gemini-3.1-flash-lite-preview, temperature 0.1, max tokens 3200, top-p 1, seed 9527.
The FLUX stage is:
| Component | Saved value |
| --- | --- |
| Diffusion model | flux3_image_klein_sd_int8_convrot.safetensors |
| Text encoder | qwen3vl_4b_int8_convrot.safetensors, CLIP type flux3 |
| VAE | flux2-vae.safetensors |
| Reference composition | ReferenceMultiLatent, resolution="keep resolution", one input image |
| Sampling | KSampler, seed 9527 fixed, 16 steps, CFG 1, euler, simple scheduler, denoise 1.0 |
| High-resolution output prefix | AIKSK_MOSS_03_4K |
Black Forest Labs identifies the 16-step distilled FLUX 3 Image Klein as a text/image editing and multi-reference model; the vendor's license terms are distinct from MOSS-Image's terms. <bfl.ai> The subtitle says “Euler + Beta” for this stage; the actual saved JSON is Euler + simple, which is what this tutorial reports. The saved graph has the right-hand FLUX section enabled; it is optional by selectively disabling that stage, not because it ships switched off.
3. Run it on RunningHub
1. Open the AI-KSK RunningHub workflow. The link points to the creator's published workflow; check available execution permissions and any applicable charges on the service.
2. Supply an image you own or have permission to transform. Start with an image where subject count and text are easy to inspect. Do not rely on the JPG path embedded in the author's JSON.
3. Locate PrimitiveBoolean. Keep True if you want Gemini to return a spatial JSON Layout; switch to False for a prose caption. Both settings still invoke an LLM; the switch does not bypass the vision-model call.
4. Check the loaded MOSS checkpoint, Qwen text encoder, VAE and two Gemini nodes. If you want only the first-stage result, disable the entire FLUX reconstruction group, including its LLM and output nodes; do not indiscriminately bypass model loaders.
5. Queue the graph. The MOSS stage saves AIKSK_MOSS_03_SINGLE; the optional FLUX stage saves AIKSK_MOSS_03_4K. Use Image Comparer to inspect differences, including changed lettering, face structure, edges, and objects.
The accompanying subtitles show the creator using RunningHub and describe the workflow as published there. This write-up did not run a new job on that service, so current job availability, API credits and completion behavior should be checked by the operator.
4. Install locally: file locations and portability
ComfyUI can load the unmodified JSON through its workflow import function, but local execution is not simply a matter of copying a 54-KB JSON. The saved graph references third-party model files and two RHLLMChatNode calls. These require a compatible runtime, available checkpoints and an authorized LLM backend.
Install compatible model files under the normal ComfyUI model directories (model availability and compatibility must be checked in each installation):
ComfyUI/models/diffusion_models/
moss_image_sft_int8_convrot.safetensors
flux3_image_klein_sd_int8_convrot.safetensors
ComfyUI/models/text_encoders/
qwen3.5_9b_bf16.safetensors
qwen3vl_4b_int8_convrot.safetensors
ComfyUI/models/vae/
flux2-vae.safetensors
ComfyUI/models/upscale_models/
RealESRGAN_x4plus.pth
These are required filenames from the JSON, not embedded files, verified download links, or a universal recommendation for memory capacity. For official upstream information, see MOSS-Image, MOSS SFT weights, and FLUX 3 Image Klein. The submitted file requires RHLLMChatNode, the easy showAnything display node (Easy-Use) and Image Comparer (rgthree) (rgthree); also confirm the availability of GetImageSize, PrimitiveBoolean, StringFormat, ImageScaleToMaxDimension, ReferenceMultiLatent, and MOSS/FLUX loader choices in your exact ComfyUI build. Do not substitute arbitrary “similar” node implementations without testing the graph.
The RunningHub-specific Gemini node may be unavailable outside that service. Replacing it with a local/API LLM requires rewiring the workflow, verifying image input/output text interfaces, and checking the JSON layout schema. Such a conversion is not included in the distributed original JSON. The workflow also contains a serialized input JPG name absent from this package; re-upload your own image. Each LLM stage may incur provider costs when activated.
5. A sensible comparison and quality-control procedure
Keep the original image, the MOSS stage and the FLUX stage side by side. Look at (a) main subjects and counts, (b) framing and cropping, (c) readable Chinese/English text, (d) small accessories, (e) visual style, (f) watermarks and marks, and (g) hallucinated detail. Compare MOSS-only against FLUX-enabled before deciding whether the more expensive second stage is worthwhile for your subject. A larger output is not necessarily a more faithful output.
The workflow prompt requests reproduction of clearly visible text, which can include watermark-like markings. Do not treat reproducing or obscuring another person's watermark as proof of ownership or authorize use of protected materials. Use sources you may legally edit and publish. If exact text is mission-critical, verify it manually or use a layout/typography stage after generation.
Known limitations and evidence boundary: The uploaded ZIP contains one ComfyUI JSON and one promotional cover only. It contains no sample JPG, no model weights, no generated image exports, no GPU logs, no latency tables, and no complete local/GPU acceptance report. The serialized metadata itself says static_only_no_GPU_or_target_object_info_validation; static inspection is not successful execution. No measured speed, VRAM requirement, quality ranking, or guaranteed 4K outcome is claimed here.
6. Which part should you use?
Use MOSS only when you need a new image built around the reference's content, text arrangement and visual style, and you are willing to inspect changes. Enable FLUX reconstruction when you also want a large-edge output with a second generative refinement pass, accepting extra model loads, a second LLM call, processing time, and fidelity risk. Set JSON Layout when spatial structure matters; choose caption mode when the source does not need rigid region descriptions or the JSON parser behavior becomes fragile.
This is a practical example of composing a vision-capable description service, a generative image model and a reference-guided enhancer in one graph. The most important operator skill is not a secret sampling preset: it is checking what was actually preserved after each stage.
Resources and credits
- Main workflow/experience (creator invitation URL): <runninghub.ai>
- Entire YouTube video: <youtu.be>
- Bilibili video: <bilibili.com>
- Related model-files link supplied by AI-KSK (contents and terms have not been independently audited): <pan.quark.cn>
- Creator's broader image index (secondary resource): <notion.so>
- Upstream MOSS repository and SFT model: <OpenMOSS/MOSS-Image> · <huggingface.co>
- Upstream FLUX 3 Klein overview: <bfl.ai>
AI-KSK distributes the supplied workflow configuration and cover, not the model weights. MOSS SFT and FLUX 3 Klein have different upstream license terms; the workflow package does not override either model's license. Credit: AI-KSK / KSK, video 325.
Workflow access and downloads
| Workflow | RunningHub | Civitai |
|---|---|---|
| MOSS-Image Wash + FLUX 3 Klein 4K | RunningHub | Workflow |
Collection downloads: Hugging Face · ModelScope.
We’re MOSS, the team behind MOSS-Image, MOSS-TTS, and more — Ask Us Anything!
preview.redd.it
Hi r/LocalLLaMA!
We’re MOSS, the team behind the MOSS family of models for speech, audio, images, and video. Some of you may know us through MOSS-TTS, or have come across our recent MOSS-Image release.
Today, we took the “anything” in “Ask Us Anything” pretty literally. Speech, sound, music, images, video—we brought the whole MOSS model family!
We’re based in Shanghai, with roots in the OpenMOSS research team at Fudan University and the Shanghai Innovation Institute. You can explore our models, research, and tools on our website.
Our broader research goal is to build AI that can follow what’s happening around it: what people are saying, what they’re seeing, and how the situation changes over time. That takes us across speech generation, audio and visual understanding, and synchronized audio-video generation.
🎨 MOSS-Image
MOSS-Image is our text-to-image model with a 5B DiT backbone, Chinese and English text rendering, and JSON layout control. Base and SFT weights and the bundled inference code are available under Apache 2.0.
MOSS-Image has remained among the top trending text-to-image models on Hugging Face. Its ComfyUI version has already recorded 3,702,490 downloads.
🎙️ Speech and sound generation
- MOSS-TTS — Speech synthesis and voice cloning.
- MOSS-TTSD — Multi-speaker conversations, long-form dialogue, and podcasts.
- MOSS-TTS-Realtime — Streaming speech generation for conversational applications.
- MOSS-TTS-Nano — Lightweight 100M-parameter speech generation with CPU-friendly streaming inference.
- MOSS-VoiceGenerator — Design voices from text descriptions, without reference audio.
- MOSS-SoundEffect — Generate sound effects from text.
🎧 Audio understanding
- MOSS-Transcribe-Diarize — Transcription with speaker labels and timestamps.
- MOSS-Audio — Understanding and reasoning about speech, environmental sounds, and music.
- MOSS-Music — Music understanding, from lyrics and instrumentation to structure.
🎬 Visual understanding and video generation
- MOSS-VL — Image and video understanding, including long videos.
- MOSS-VL-Realtime — Understand streaming video as it unfolds.
- MOVA — Generate video and audio together, in sync.
🛠️ Other resources
- MOSS API & Playground
- Hugging Face
- GitHub
Joining the AMA:
- u/garybryant
- u/FarAdhesiveness9577
- u/Phospheneser
- u/TimeEnvironmental219
- u/Aggressive-Sign-8167
- u/Professional-Milk422
- Other MOSS team members — answering through the accounts above.
We'll be answering questions on October 30, from 8–11 AM PT, and will continue checking the thread for 48 hours afterward.
Ask us anything!
243 points · 212 comments
MOSS-Image Publishes 5B DiT Weights and Layout JSON Workflow
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.
MossAD Demo - MOSS Image Danbooru/E621 57 Artist Style Finetune
Hello there. Some of you may vaguely recognize me as that guy that train the weird Danbooru/E621 toy model based on Microsoft's MageFlow 4B recently.
Well uh, AI tech move fast. Really fast. And I can't predict the future. And MOSS is also the model of my dream, I legit shed a tear irl after trying the model out and realizing the potential. So yes MOSS Image have completely mog MageFlow and any potential mid size arch that came before it (barring Krea 2 still being a beast). So both me and my direct sponsor, KblueLeaf, and literally everyone else who have eyes, have decided to focus on MOSS.
MossAD-Demo (Moss Anime Diffusion) is a Danbooru/Gelbooru/E621 proof of concept Full-Finetune of OpenMOSS's MOSS-Image Base 5B T2I model, trained on a small curated 3,685 images dataset of 57 artists, as a way to test how fast and how well MOSS-Image learns artist styles, booru tags prompting and layout (bounding box) prompting before committing to a much bigger run.
Why MOSS Image? Why is everybody noticing it and hyping it up suddenly (with some pushback of course), what makes it special?
1. 3.2 Billion Images pretrained model - this means the model have an impressive amount of knowledge to pull from, similer feel to sdxl back in the day, on just a 5B model.
2. Flux2VAE and a good 9B TE, can't go wrong with that.
preview.redd.it
1. People, READ THE OFFICIAL USERGUIDE AND EXPLORE THE MODEL BBOX CAPABILITIES MOSS-Image/USERGUIDE.md , that is WHAT BOUNDING BOX CAN DO, the model does it better than Ideogram 4 before, this changes everything, it's regional prompting on crack, the feature legit elevate the model to potentially compete with corpo based model like Qwen/Flux/NovelAI V5, you're missing out on 50% of the model potential by not trying it/not knowing it exist.
2. As far as I can tell right now, no major arch flaw discovered yet, only downsize being the model is versatile but a bit unstable sometimes. The model is giving people some difficulty on character LoRA training, but it's still early days, and I've seen lots of decent success as well for both characters and style training.
3. 5B is a pretty good model size to me compared to the chonk of Krea 2 13B or even the 9B class models, people with 16GB VRAM and above can use it semi comfortably, and if below that then model can fit on 12GB with int8 convrot.
And for the actual model training itself, the test is a big success:
After only ~39 hours on a single AMD MI300X (ok I know it's alot for just 3k image on this kind of gpu, but i received the compute very suddenly under a 4 day deadline and didn't have the luxury to optimize training), the styles land at around 90% accuracy, they carry over to subjects the artist never drew (a furry artist's style on anime girls, and the other way around), and hands are solid enough barring some exceptions here and there. The model really is the dream for us finetuners.
~ What the pilot found, and what the next big run will use:
- MOSS-Image learns styles fast: ~4.5k views per artist at 512px already gives 70-75% style accuracy, ~7k views gives 85-90% with the style carrying over to other subjects, while ~4k views only shows the style in the artist's own domain (furry artist styles only on furry gens)
- Most of the training can stay at cheap 512px, with shorter 768px and 1024px stages for hands, details and texture
- The learning rate needs to be halved at every higher resolution stage (4e-5 → 2e-5 → 1e-5), carrying the 512px LR into 768px made it unstable within 5 epochs and the stage had to be restarted (this is pretty basic stuff for finetuning, I just forgot...)
- The base model already understands panels and boxes from ComfyUI's default bbox node, and the finetune keeps that working with the trained styles
- Watermarks REALLY stick: if most of an artist's images share the same watermark, no tagging, captioning or negative prompt removes it. I will test masked training in the future to keep watermarks and signatures out of the loss if deemed viable and not too much of a hassle.
Known issues
- Watermarks and signatures that most of an artist's images share can show up in gens
- The model is still a bit unstable and have slightly degraded text performance in general compared to base model
- Hands are kinda bad in some exceptions here and there
Any donation will help with funding the full run, which will begin in a few months time when the OpenMOSS devs release their official anime tune, and I finish my 6k artist style dataset, you can do so through:
Crypto (Preferred, cause Kofi/Paypal money transfer time is ass and they take a big cut)
0x6a4bc748cd0bb9ced9a360eb0eb79f4f106614f8 (USDT - BEP20 Network - Custodial wallet)
12PPVYUeS1MerNp38Tpns5qXR6cmhu9tws (Bitcoin - BTC Network - Custodial wallet)
0x6a4bc748cd0bb9ced9a360eb0eb79f4f106614f8 (Ethereum - ERC20 Network - Custodial wallet)
GKjLvD9XGAhyEpsZvEUNH5je9PFbrivoV5yBfYKGYskq (Solana - SOL network - Non Custodial wallet)
Please handle your money carefully and make sure the address you're sending to is correct.
Please contact me through discord (user: talannnn) if you're donating with crypto, to make sure it goes through and you're not losing money.
Ko-fi
https://ko-fi.com/talanartvn
Acknowledgments
Beeg thanks to:
- Disty0 — The free MI300X compute that made this whole test possible, the biggest thanks to them
- OpenMOSS — Creators of MOSS-Image, absolute fuckin legends for providing open source with this amazing base model
- Bluvoll — Creator of mage-flow-trainer that my fork is derived from, and general training advice
- Motimalu — Inspiration behind finetuning practices and configs, like lowering the LR at every resolution stage (should be obvious but I didn't remember first time)
- KBlueLeaf — Future sponsor for MossAD
- Anzhc — Detection models used for the bounding box captions, and general training advice
- Format inspired by Motimalu's Kirazuri diary
121 points · 37 comments
MOSS-Imageの出力仕様メモ：1K/2Kと7比率、参照画像なし
MOSS-Image を実際の制作フローに組み込む前に、「何が出せて、何が出せないか」を一枚にまとめておきたくなったので、その整理メモです。プロンプトのコツではなく、解像度・比率・枚数・できないことといった出力仕様の話に絞ります。
先にお断りしておくと、この記事は AI の支援を受けて下書きし、私が手で確認・編集しました。掲載画像はすべて AI 生成で、MixVio のモデルページのギャラリーにある MOSS-Image の実際の出力を、拡大せず元サイズのまま載せています。
モデル側の仕様（OpenMOSS 公式）
モデルファミリーは MOSS-Image-Base と MOSS-Image-SFT の 2 つ。SFT は Base を厳選データで微調整したもので、同じアーキテクチャとサンプリング設定を共有します。
5B のバックボーン、最大 4K トークンのプロンプト、JSON によるネイティブなレイアウト指定。
重みは Apache-2.0。
推奨サンプリングは Flow-matching Euler、50 ステップ、CFG 3。
ローカル実行は Python 3.10 以上と NVIDIA GPU が前提です。README には推論に必要な VRAM の下限は書かれておらず、GPU メモリが足りない場合は Gradio の Sequential モードか、画像サイズを下げるよう案内されています。
そして一番大事な点として、これは文生図専用のモデルです。既存画像の編集はできず、参照画像も入力できません。
参照画像がない、ということの意味
画像編集系のモデルに慣れていると、「この写真の看板の文字だけ差し替えたい」と考えがちですが、MOSS-Image ではそれができません。私がフローを組むうえで決めたルールは次の 3 つです。
文言は生成前に確定させる。生成後の 1 語修正は、全体の再生成になる。
同じ構図を何度も出したい場合は、プロンプトを文章で固定し、位置が重要なら JSON レイアウトで bbox を固定する。
ブランドロゴや既存キャラクターを「参照で寄せる」ことはできないので、そもそも権利のあるものだけをプロンプトに書く。
MixVio で使う場合の出力仕様
ホスト型で使う場合の例として、MixVio のモデルページに載っている仕様を表にしました。
項目
内容
入力
英語・中国語のプロンプト、または items 配列を持つ JSON レイアウト
プロンプト拡張
JSON レイアウトはそのまま送信、それ以外は拡張あり
出力形式
PNG
解像度
1K / 2K
比率
1:1、4:3、3:4、3:2、2:3、16:9、9:16 の 7 種類
枚数
1 回 1〜4 枚
ないもの
4K、21:9、seed、品質メニュー、ネガティブプロンプト
サンプリング
50 ステップ、guidance 3 で固定
seed がないので、同じプロンプトでも再実行の結果は再現できません。ローカルの Python パイプラインでは generator に seed を渡せるので、再現性が必要な検証はローカル、と使い分けるのが現実的です。
クレジットの見積もりを関数にしておく
MixVio のページで確認できるのは、1 枚あたり 2〜14 クレジットという幅と、次の 3 点の具体値です。
1K・16:9：2 クレジット
1K・1:1（デフォルト）：4 クレジット
2K・1:1：14 クレジット
枚数を増やすとその分掛け算になり、失敗した生成はクレジットを消費しません。私はバッチを組む前にこれをコードに落としておきました。分かっていない組み合わせは推測せず None を返すようにしています。
KNOWN = {("1K", "16:9"): 2, ("1K", "1:1"): 4, ("2K", "1:1"): 14}
RATIOS = {"1:1", "4:3", "3:4", "3:2", "2:3", "16:9", "9:16"}
def quote(res, ratio, n=1):
if res not in ("1K", "2K") or ratio not in RATIOS:
raise ValueError(f"unsupported: {res} {ratio}")
if not 1 <= n <= 4:
raise ValueError("1-4 images per request")
per = KNOWN.get((res, ratio))
return None if per is None else per * n
print(quote("1K", "16:9", 4)) # 8
print(quote("2K", "1:1", 2)) # 28
print(quote("2K", "9:16")) # None -> ページの表示を見る
実行すると 8、28、None が出ます。None になったものは、生成ボタンに表示される見積もりを見てから決めます。21:9 や 5 枚を渡すと ValueError になるので、存在しない設定をバッチに混ぜる事故も防げます。
ギャラリー出力の実寸を測ってみた
比率ごとの見え方を確認するため、ギャラリーの出力ファイルの実寸を私が一枚ずつ測りました。下の 4 枚は横長・縦長・文書ページと、形の違うものを選んでいます。
MixVio ギャラリーの MOSS-Image 実出力（AI 生成、1680×944）。横長の写真風シーン。
MixVio ギャラリーの MOSS-Image 実出力（AI 生成、944×1680）。縦長で、UI の小さな文字が多い例。
MixVio ギャラリーの MOSS-Image 実出力（AI 生成、1056×1488）。
MixVio ギャラリーの MOSS-Image 実出力（AI 生成、1088×1456）。
測った値は 1680×944、944×1680、1056×1488、1088×1456 でした。ファイル名や表示からはどの解像度設定で出したかまでは分からないので、ここでは「実寸はこうだった」という記録にとどめます。自分の用途で必要なピクセル数がある場合は、1K と 2K の両方で一度出して実寸を確かめるのが確実です。
文書ページ系の 2 枚は、ぱっと見では整っていますが、よく読むと崩れた字や式が混じっています。模試用紙や教科書のような「読まれる前提」のものは、モックアップや雰囲気づくりまでに使うのが安全です。
ローカル実行とホスト型の使い分け
仕様を並べてみると、ローカル実行とホスト型では向いている用途がはっきり分かれます。
ローカル（公式パイプライン）が向いているケース
再現性が必要な検証。Python パイプラインは generator に seed を渡せるので、同じ条件で結果を比べられます。
サンプリング設定を変えて試したいとき。公式の推奨値は 50 ステップ・CFG 3 ですが、ローカルなら自分で調整できます。
Base と SFT を両方試したいとき。公式ページには、同じプロンプトで SFT のほうが文字のまとまりやホワイトボードの配置が整理された例が載っています。
ホスト型が向いているケース
GPU を用意せずに、まず出力の傾向を見たいとき。
比率や枚数を切り替えながら、構図の当たりを付けたいとき。
一方で、ホスト型には seed もネガティブプロンプトもないので、「前回とまったく同じ画像をもう一度」という使い方はできません。私は、当たりを付ける段階とレイアウトを詰める段階を分けて考えるようにしています。
比率の選び方
7 つの比率は、用途から逆算すると選びやすくなります。
16:9：ブログのアイキャッチ、横長のバナー、スライドの背景。
9:16：スマホの縦画面、ショート動画のサムネイル、配信画面の模型。
3:4・2:3：ポスター、チラシ、文書ページの模型。
1:1：SNS の正方形投稿、アイコン周りの素材。
4:3・3:2：写真らしい横構図、商品写真風のシーン。
21:9 のような超横長はないので、横長バナーが必要な場合は 16:9 で出して、後から上下を切る前提で構図を組みます。そのときは文字を画面の中央寄りに置いておくと、切り取りで文字が欠ける事故を避けられます。JSON レイアウトを使う場合は、bbox の座標を要求する幅と高さに合わせる必要がある点にも注意してください。
まとめ
文生図専用。編集・参照画像はない。文言は生成前に確定させる。
MixVio 経由なら 1K/2K、7 比率、1〜4 枚、PNG。seed とネガティブプロンプトはない。
クレジットは分かっている値だけをコードにし、不明な組み合わせは画面の見積もりで確認する。
小さく密な文字は必ず校正する。
参考
MOSS-Image 公式リポジトリ（README・ユーザーガイド）
OpenMOSS 公式プロジェクトページ
ブラウザから試す場合：MOSS-Image を試す
10 New GitHub Repos You Should Know (An AI Uses a Real iPhone & More)
Ten of the most interesting new open source projects on GitHub: an AI that uses a real iPhone with a $7 chip, a project rebuilding the world's software for free, code that becomes a neural net, a fix for smart TV ads and more. Every pick explained in about a minute, from its README.
Chapters
0:00 Intro
0:21 #10 datalab-to/indra – OCR at 49 pages per second
0:51 #9 shaongitbd/doory – A Canva alternative with no paid plan
1:18 #8 OpenMOSS/MOSS-Image – An open image model that writes text
1:42 #7 ahwootech/BRUTAL – The framework under RimWorld's new engine
2:16 #6 SubmitGame/awesome-decomp-games – 1,800 classic games rebuilt for PC
2:46 #5 rohit267/net-merge – Combine every internet connection
3:17 #4 Gathin23/tv-vibehack – Your smart TV, minus the ads
3:45 #3 chenglou/handwired – Normal code as a neural network
4:13 #2 HeyPuter/everything – Rebuilding the world's software for free
4:44 #1 onehumanbeing/esp32-iphone-agent – An AI uses a real iPhone
5:13 Outro
Repos
#10 datalab-to/indra: datalab-to/indra
#9 shaongitbd/doory: shaongitbd/doory
#8 OpenMOSS/MOSS-Image: OpenMOSS/MOSS-Image
#7 ahwootech/BRUTAL: ahwootech/BRUTAL
#6 SubmitGame/awesome-decomp-games: SubmitGame/awesome-decomp-games
#5 rohit267/net-merge: rohit267/net-merge
#4 Gathin23/tv-vibehack: Gathin23/tv-vibehack
#3 chenglou/handwired: chenglou/handwired
#2 HeyPuter/everything: HeyPuter/everything
#1 onehumanbeing/esp32-iphone-agent: onehumanbeing/esp32-iphone-agent
Scripts written from each project's README; check the repos for details.
Music: "Ouroboros" by Kevin MacLeod (incompetech.com), licensed under Creative Commons: By Attribution 4.0 License creativecommons.org
33 views
MOSS-Image: a new free AI image model that writes long, clear text
MOSS-Image is an open text-to-image model family from the OpenMOSS team, released on 16 Oct 2026 in Base and SFT versions. Its model weights are licensed under Apache 2.0. It is built to render long, clear text inside images, in English and Chinese, and a JSON layout prompt lets you set where each object and line of text goes using bounding boxes. In OpenMOSS's own Base vs SFT example, the SFT version groups the text more clearly. To run it yourself, the official quick start loads the model onto a CUDA (NVIDIA) GPU.
Sources:
- Project page: openmoss.ai
- GitHub (README, quick start, Apache-2.0 licence): OpenMOSS/MOSS-Image
- Hugging Face model card: huggingface.co
- Technical report: openmoss.ai
Media credits: images by OpenMOSS from the official MOSS-Image GitHub repository (Apache License 2.0): teaser, Base vs SFT comparison, layout-control diagram, and cropped showcase panels. The people and scenes in these images are the model's own AI-generated examples, not real photos. Not sponsored; not affiliated with OpenMOSS.
Like it? Subscribe to Myth & Machine, and tap the bell.
#Shorts #AI #AIImage #OpenSource
412 views
moss image 上线了！ AI 生图不只拼画质，连文字排版和元素布局都能控制了
moss image 开源了！：
[OpenMOSS/MOSS-Image]( OpenMOSS/MOSS-Image)
平时用 AI 生图，应该不少人都遇到过类似的问题：画面看着不错，但图片里的文字经常出错；想做一张有明确布局的海报，生成结果却总和预期有差距。
MOSS-Image 的一个主要方向，就是让图片里的文字和布局更容易控制。
这个项目公开了代码和模型权重，模型规模约为 5B 参数。除了图片生成，它还关注文字渲染、布局控制和后续微调。
我感觉这类方向挺实用的。毕竟很多时候，我们需要的不是一张单纯好看的图片，而是能用来做海报、广告或者其他设计工作的素材。
当然，具体效果怎么样，还是得自己跑一跑，尤其是中文文字、复杂排版这些场景，值得单独测试。
这里推荐一个测试的站点：
mossimage.art
【开源图像模型又多一个能玩的】MOSS-Image 有动漫、插画到写实风格，提示词空间也够大，想试不同视觉效果的可以点链接：OpenMOSS/MOSS-Image huggingface.co
6 likes · 267 views
Explore MOSS-Image ↓
🎨 Live Demo: huggingface.co
💻 GitHub: OpenMOSS/MOSS-Image
🤗 Hugging Face:
Base: huggingface.co
SFT: huggingface.co
🖥️ Comfy-Org Model Repo: huggingface.co
Try it out, and show us what you're creating!
6 likes · 1 repost · 223 views
Mentions
MOSS-Image Restoration + FLUX 3 Klein 4K in ComfyUI: One Complete AI-KSK Workflow MOSS-Image Restoration + FLUX 3 Klein 4K in ComfyUI: An AI-KSK Workflow Walkthrough An AI image-restoration workflow can do more than feed a photograph into a generic upscaler. Sometimes the goal is to reconstruct a reference image's composition and style—its people, typography, lighting, and spatial arrangement—using a new generative pass, and only then create a higher-resolution version. That is the design behind AI-KSK's video 325 workflow: MOSS-Image-SFT → optional FLUX 3 Image Klein reconstruction at a 3840-pixel longest side, with Gemini-powered visual description in both stages. This tutorial is based on the creator's subtitle transcript and an inspection of the actual supplied ComfyUI graph (洗图最终 (4).json: 35 nodes, 43 serialized links), not an independent execution, benchmark, or review of the original video stream. The promotional cover is illustrative; it is not a verified before/after measurement. You receive one workflow, not separate MOSS and FLUX workflow files. Start here: the workflow and the complete video Run or inspect the creator's online workflow on RunningHub: MOSS-Image Wash/Rebuild — AI-KSK. The URL includes the creator's invitation code and may support the creator. RunningHub access, included nodes, charges, and current runtime availability are subject to the platform. Full video lesson: AI-KSK video 325 on YouTube. Bilibili lesson is also available. The downloadable project contains the unmodified workflow JSON and its original 3:4 promotional cover; it does not contain the source reference image, generated results, model weights, or hosted-service credentials. 1. What “image washing” means here—and what it does not In this workflow, “washing” describes image-to-image reconstruction driven by image analysis, not lossless repair. Gemini 3.1 Flash-Lite receives a preprocessed source image and produces a caption or a coordinate-based MOSS JSON Layout. The resulting text conditions MOSS-Image-SFT. The input image is also encoded into the MOSS latent space, but the MOSS sampler uses denoise=1.0: this is a complete generative denoising pass rather than a conservative pixel-perfect restoration. Treat it as reference-led regeneration, not an exact photographic clone. MOSS-Image-SFT is the supervised fine-tuned MOSS-Image model, based on a 5-billion-parameter image-generation backbone. The OpenMOSS documentation describes natural-language prompting and structured layouts for spatial and text placement. In this project the input dimensions are read after preprocessing so the LLM can work with the relevant coordinate canvas, reducing—not eliminating—layout mismatch. <huggingface.co> The second pass is a different task: RealESRGAN first scales the MOSS result; ImageScaleToMaxDimension sets the longest edge to 3840, and FLUX 3 Image Klein then reconstructs the upscaled reference using another visual caption. 3840 on the longest side is not a promise of exactly 3840×2160, nor evidence of recovered lost real-world details. The final image is generative and may change tiny text, faces, objects, or logos. 2. The actual pipeline, node by node The uploaded graph has 35 nodes and five functional stages: LoadImage (source JPG not included) -> ImageScaleToTotalPixels (lanczos, 1 MP, resolution_steps=16) -> GetImageSize -> StringFormat (width, height, mode) -> RHLLMChatNode (Gemini 3.1 Flash-Lite preview) -> CLIPTextEncode (MOSS positive condition) -> MOSS-SFT KSampler -> VAEDecode -> SaveImage (MOSS output) | ^ +-> VAEEncode -----+ (source image encoded; denoise=1.0) | +-> second RHLLMChatNode (caption of MOSS output) +-> RealESRGAN_x4plus -> longest edge 3840 -> ReferenceMultiLatent + FLUX 3 Klein conditioning -> FLUX KSampler -> VAEDecode -> SaveImage (4K-labeled output) The graph also contains preview nodes, an easy showAnything text viewer, and a rgthree Image Comparer comparing the MOSS-stage and FLUX-stage images. The creator's video introduces an updated Midjourney-style MOSS LoRA as an optional idea; this particular supplied JSON contains no LoRA loader or LoRA application node. Do not advertise that LoRA as active in the downloadable graph. Stage A — input normalization Load your own image into LoadImage (node 272). The saved node points to a machine-specific JPG filename that is not included in the project. ImageScaleToTotalPixels (node 244) uses lanczos, megapixels=1 and resolution_steps=16. The preprocessed image is used for the reconstruction input, the vision call, and the measured dimensions. GetImageSize (254) provides the current width and height to StringFormat (255); these values are not manually locked to a fixed portrait/landscape shape. The prompt asks Gemini to preserve observable subject count, spatial relationships, original visual medium, lighting and legible words. It expressly requests no user-side modification. This is a helpful default for rebuilding an existing composition; it is not a guarantee that text or faces will be exact. Stage B — Gemini caption or MOSS JSON Layout PrimitiveBoolean (271) controls format. In the actual supplied file, it is True: JSON Layout is enabled. This contradicts an older embedded Markdown note claiming the default is off. False requests an English scene caption; True requests JSON with summary, items, bbox_coord_space="abs_centralized" and bbox_format="yxyx". Item boxes are center-origin pixel coordinates [y_min, x_min, y_max, x_max], calculated against the measured target width/height. A structured prompt helps reason about placement, but the graph does not show a separate programmatic JSON validator. The node is RHLLMChatNode (276), with model identifier google/gemini-3.1-flash-lite-preview, temperature 0.2, maximum tokens 4096, top-p 0.9, and fixed seed 9527. Its response goes to the MOSS text encoder and the easy showAnything viewer. The model identifier and service integration are as serialized, not a promise that the same endpoint is accessible through arbitrary local Gemini credentials. Image content is treated as data rather than instructions in its built-in system prompt. Stage C — MOSS-Image-SFT regeneration The actual loaders and sampler settings are: | Component | Saved value | | --- | --- | | Diffusion model | moss_image_sft_int8_convrot.safetensors | | Text encoder | qwen3.5_9b_bf16.safetensors, CLIP type moss_image | | VAE | flux2-vae.safetensors | | Skip-layer guidance | SkipLayerGuidanceDiTSimple, single layer 22, start 0, end 1 | | Sampling | KSampler, seed 9527 fixed, 20 steps, CFG 3, euler, sgm_uniform, denoise 1.0 | | Negative text | nsfw, worst quality, bad anatomy, watermark, jpeg artifact | | Original-size-stage output prefix | AIKSK_MOSS_03_SINGLE | The source image reaches VAEEncode, providing the latent input. The text/JSON response supplies positive conditioning; the encoded source is not the same as adding a separate MOSS image-vision conditioning node. The embedded project note mentions a “Vision route,” but TextEncodeMOSSImageVision does not exist in this actual 35-node graph. This is the standard-VAE version, not a separate vision-conditioned workflow. The OpenMOSS model card documents a 50-step / CFG 3 reference example with layer-22 skipping. Twenty steps is this creator's saved configuration, not an official guarantee of equivalent fidelity. The creator describes personal experiments down to 20 steps in the supplied subtitles; the package provides no reproduced performance numbers. <huggingface.co> Stage D — optional RealESRGAN → FLUX 3 Image Klein reconstruction The MOSS decoded result is reused, not a new upload. ImageUpscaleWithModel uses RealESRGAN_x4plus.pth; ImageScaleToMaxDimension (264) then sets lanczos, largest_size=3840. A second RHLLMChatNode (268) looks at the MOSS output, not the initial input image, and writes a grounded full-scene caption emphasizing plausible material and detail improvements without deliberate composition changes. Saved settings: google/gemini-3.1-flash-lite-preview, temperature 0.1, max tokens 3200, top-p 1, seed 9527. The FLUX stage is: | Component | Saved value | | --- | --- | | Diffusion model | flux3_image_klein_sd_int8_convrot.safetensors | | Text encoder | qwen3vl_4b_int8_convrot.safetensors, CLIP type flux3 | | VAE | flux2-vae.safetensors | | Reference composition | ReferenceMultiLatent, resolution="keep resolution", one input image | | Sampling | KSampler, seed 9527 fixed, 16 steps, CFG 1, euler, simple scheduler, denoise 1.0 | | High-resolution output prefix | AIKSK_MOSS_03_4K | Black Forest Labs identifies the 16-step distilled FLUX 3 Image Klein as a text/image editing and multi-reference model; the vendor's license terms are distinct from MOSS-Image's terms. <bfl.ai> The subtitle says “Euler + Beta” for this stage; the actual saved JSON is Euler + simple, which is what this tutorial reports. The saved graph has the right-hand FLUX section enabled; it is optional by selectively disabling that stage, not because it ships switched off. 3. Run it on RunningHub 1. Open the AI-KSK RunningHub workflow. The link points to the creator's published workflow; check available execution permissions and any applicable charges on the service. 2. Supply an image you own or have permission to transform. Start with an image where subject count and text are easy to inspect. Do not rely on the JPG path embedded in the author's JSON. 3. Locate PrimitiveBoolean. Keep True if you want Gemini to return a spatial JSON Layout; switch to False for a prose caption. Both settings still invoke an LLM; the switch does not bypass the vision-model call. 4. Check the loaded MOSS checkpoint, Qwen text encoder, VAE and two Gemini nodes. If you want only the first-stage result, disable the entire FLUX reconstruction group, including its LLM and output nodes; do not indiscriminately bypass model loaders. 5. Queue the graph. The MOSS stage saves AIKSK_MOSS_03_SINGLE; the optional FLUX stage saves AIKSK_MOSS_03_4K. Use Image Comparer to inspect differences, including changed lettering, face structure, edges, and objects. The accompanying subtitles show the creator using RunningHub and describe the workflow as published there. This write-up did not run a new job on that service, so current job availability, API credits and completion behavior should be checked by the operator. 4. Install locally: file locations and portability ComfyUI can load the unmodified JSON through its workflow import function, but local execution is not simply a matter of copying a 54-KB JSON. The saved graph references third-party model files and two RHLLMChatNode calls. These require a compatible runtime, available checkpoints and an authorized LLM backend. Install compatible model files under the normal ComfyUI model directories (model availability and compatibility must be checked in each installation): ComfyUI/models/diffusion_models/ moss_image_sft_int8_convrot.safetensors flux3_image_klein_sd_int8_convrot.safetensors ComfyUI/models/text_encoders/ qwen3.5_9b_bf16.safetensors qwen3vl_4b_int8_convrot.safetensors ComfyUI/models/vae/ flux2-vae.safetensors ComfyUI/models/upscale_models/ RealESRGAN_x4plus.pth These are required filenames from the JSON, not embedded files, verified download links, or a universal recommendation for memory capacity. For official upstream information, see MOSS-Image, MOSS SFT weights, and FLUX 3 Image Klein. The submitted file requires RHLLMChatNode, the easy showAnything display node (Easy-Use) and Image Comparer (rgthree) (rgthree); also confirm the availability of GetImageSize, PrimitiveBoolean, StringFormat, ImageScaleToMaxDimension, ReferenceMultiLatent, and MOSS/FLUX loader choices in your exact ComfyUI build. Do not substitute arbitrary “similar” node implementations without testing the graph. The RunningHub-specific Gemini node may be unavailable outside that service. Replacing it with a local/API LLM requires rewiring the workflow, verifying image input/output text interfaces, and checking the JSON layout schema. Such a conversion is not included in the distributed original JSON. The workflow also contains a serialized input JPG name absent from this package; re-upload your own image. Each LLM stage may incur provider costs when activated. 5. A sensible comparison and quality-control procedure Keep the original image, the MOSS stage and the FLUX stage side by side. Look at (a) main subjects and counts, (b) framing and cropping, (c) readable Chinese/English text, (d) small accessories, (e) visual style, (f) watermarks and marks, and (g) hallucinated detail. Compare MOSS-only against FLUX-enabled before deciding whether the more expensive second stage is worthwhile for your subject. A larger output is not necessarily a more faithful output. The workflow prompt requests reproduction of clearly visible text, which can include watermark-like markings. Do not treat reproducing or obscuring another person's watermark as proof of ownership or authorize use of protected materials. Use sources you may legally edit and publish. If exact text is mission-critical, verify it manually or use a layout/typography stage after generation. Known limitations and evidence boundary: The uploaded ZIP contains one ComfyUI JSON and one promotional cover only. It contains no sample JPG, no model weights, no generated image exports, no GPU logs, no latency tables, and no complete local/GPU acceptance report. The serialized metadata itself says static_only_no_GPU_or_target_object_info_validation; static inspection is not successful execution. No measured speed, VRAM requirement, quality ranking, or guaranteed 4K outcome is claimed here. 6. Which part should you use? Use MOSS only when you need a new image built around the reference's content, text arrangement and visual style, and you are willing to inspect changes. Enable FLUX reconstruction when you also want a large-edge output with a second generative refinement pass, accepting extra model loads, a second LLM call, processing time, and fidelity risk. Set JSON Layout when spatial structure matters; choose caption mode when the source does not need rigid region descriptions or the JSON parser behavior becomes fragile. This is a practical example of composing a vision-capable description service, a generative image model and a reference-guided enhancer in one graph. The most important operator skill is not a secret sampling preset: it is checking what was actually preserved after each stage. Resources and credits - Main workflow/experience (creator invitation URL): <runninghub.ai> - Entire YouTube video: <youtu.be> - Bilibili video: <bilibili.com> - Related model-files link supplied by AI-KSK (contents and terms have not been independently audited): <pan.quark.cn> - Creator's broader image index (secondary resource): <notion.so> - Upstream MOSS repository and SFT model: <OpenMOSS/MOSS-Image> · <huggingface.co> - Upstream FLUX 3 Klein overview: <bfl.ai> AI-KSK distributes the supplied workflow configuration and cover, not the model weights. MOSS SFT and FLUX 3 Klein have different upstream license terms; the workflow package does not override either model's license. Credit: AI-KSK / KSK, video 325. Workflow access and downloads | Workflow | RunningHub | Civitai | |---|---|---| | MOSS-Image Wash + FLUX 3 Klein 4K | RunningHub | Workflow | Collection downloads: Hugging Face · ModelScope.
We’re MOSS, the team behind MOSS-Image, MOSS-TTS, and more — Ask Us Anything! preview.redd.it Hi r/LocalLLaMA! We’re MOSS, the team behind the MOSS family of models for speech, audio, images, and video. Some of you may know us through MOSS-TTS, or have come across our recent MOSS-Image release. Today, we took the “anything” in “Ask Us Anything” pretty literally. Speech, sound, music, images, video—we brought the whole MOSS model family! We’re based in Shanghai, with roots in the OpenMOSS research team at Fudan University and the Shanghai Innovation Institute. You can explore our models, research, and tools on our website. Our broader research goal is to build AI that can follow what’s happening around it: what people are saying, what they’re seeing, and how the situation changes over time. That takes us across speech generation, audio and visual understanding, and synchronized audio-video generation. 🎨 MOSS-Image MOSS-Image is our text-to-image model with a 5B DiT backbone, Chinese and English text rendering, and JSON layout control. Base and SFT weights and the bundled inference code are available under Apache 2.0. MOSS-Image has remained among the top trending text-to-image models on Hugging Face. Its ComfyUI version has already recorded 3,702,490 downloads. 🎙️ Speech and sound generation - MOSS-TTS — Speech synthesis and voice cloning. - MOSS-TTSD — Multi-speaker conversations, long-form dialogue, and podcasts. - MOSS-TTS-Realtime — Streaming speech generation for conversational applications. - MOSS-TTS-Nano — Lightweight 100M-parameter speech generation with CPU-friendly streaming inference. - MOSS-VoiceGenerator — Design voices from text descriptions, without reference audio. - MOSS-SoundEffect — Generate sound effects from text. 🎧 Audio understanding - MOSS-Transcribe-Diarize — Transcription with speaker labels and timestamps. - MOSS-Audio — Understanding and reasoning about speech, environmental sounds, and music. - MOSS-Music — Music understanding, from lyrics and instrumentation to structure. 🎬 Visual understanding and video generation - MOSS-VL — Image and video understanding, including long videos. - MOSS-VL-Realtime — Understand streaming video as it unfolds. - MOVA — Generate video and audio together, in sync. 🛠️ Other resources - MOSS API & Playground - Hugging Face - GitHub Joining the AMA: - u/garybryant - u/FarAdhesiveness9577 - u/Phospheneser - u/TimeEnvironmental219 - u/Aggressive-Sign-8167 - u/Professional-Milk422 - Other MOSS team members — answering through the accounts above. We'll be answering questions on October 30, from 8–11 AM PT, and will continue checking the thread for 48 hours afterward. Ask us anything!
MOSS-Image Publishes 5B DiT Weights and Layout JSON Workflow 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.
MossAD Demo - MOSS Image Danbooru/E621 57 Artist Style Finetune Hello there. Some of you may vaguely recognize me as that guy that train the weird Danbooru/E621 toy model based on Microsoft's MageFlow 4B recently. Well uh, AI tech move fast. Really fast. And I can't predict the future. And MOSS is also the model of my dream, I legit shed a tear irl after trying the model out and realizing the potential. So yes MOSS Image have completely mog MageFlow and any potential mid size arch that came before it (barring Krea 2 still being a beast). So both me and my direct sponsor, KblueLeaf, and literally everyone else who have eyes, have decided to focus on MOSS. MossAD-Demo (Moss Anime Diffusion) is a Danbooru/Gelbooru/E621 proof of concept Full-Finetune of OpenMOSS's MOSS-Image Base 5B T2I model, trained on a small curated 3,685 images dataset of 57 artists, as a way to test how fast and how well MOSS-Image learns artist styles, booru tags prompting and layout (bounding box) prompting before committing to a much bigger run. Why MOSS Image? Why is everybody noticing it and hyping it up suddenly (with some pushback of course), what makes it special? 1. 3.2 Billion Images pretrained model - this means the model have an impressive amount of knowledge to pull from, similer feel to sdxl back in the day, on just a 5B model. 2. Flux2VAE and a good 9B TE, can't go wrong with that. preview.redd.it 1. People, READ THE OFFICIAL USERGUIDE AND EXPLORE THE MODEL BBOX CAPABILITIES MOSS-Image/USERGUIDE.md , that is WHAT BOUNDING BOX CAN DO, the model does it better than Ideogram 4 before, this changes everything, it's regional prompting on crack, the feature legit elevate the model to potentially compete with corpo based model like Qwen/Flux/NovelAI V5, you're missing out on 50% of the model potential by not trying it/not knowing it exist. 2. As far as I can tell right now, no major arch flaw discovered yet, only downsize being the model is versatile but a bit unstable sometimes. The model is giving people some difficulty on character LoRA training, but it's still early days, and I've seen lots of decent success as well for both characters and style training. 3. 5B is a pretty good model size to me compared to the chonk of Krea 2 13B or even the 9B class models, people with 16GB VRAM and above can use it semi comfortably, and if below that then model can fit on 12GB with int8 convrot. And for the actual model training itself, the test is a big success: After only ~39 hours on a single AMD MI300X (ok I know it's alot for just 3k image on this kind of gpu, but i received the compute very suddenly under a 4 day deadline and didn't have the luxury to optimize training), the styles land at around 90% accuracy, they carry over to subjects the artist never drew (a furry artist's style on anime girls, and the other way around), and hands are solid enough barring some exceptions here and there. The model really is the dream for us finetuners. ~ What the pilot found, and what the next big run will use: - MOSS-Image learns styles fast: ~4.5k views per artist at 512px already gives 70-75% style accuracy, ~7k views gives 85-90% with the style carrying over to other subjects, while ~4k views only shows the style in the artist's own domain (furry artist styles only on furry gens) - Most of the training can stay at cheap 512px, with shorter 768px and 1024px stages for hands, details and texture - The learning rate needs to be halved at every higher resolution stage (4e-5 → 2e-5 → 1e-5), carrying the 512px LR into 768px made it unstable within 5 epochs and the stage had to be restarted (this is pretty basic stuff for finetuning, I just forgot...) - The base model already understands panels and boxes from ComfyUI's default bbox node, and the finetune keeps that working with the trained styles - Watermarks REALLY stick: if most of an artist's images share the same watermark, no tagging, captioning or negative prompt removes it. I will test masked training in the future to keep watermarks and signatures out of the loss if deemed viable and not too much of a hassle. Known issues - Watermarks and signatures that most of an artist's images share can show up in gens - The model is still a bit unstable and have slightly degraded text performance in general compared to base model - Hands are kinda bad in some exceptions here and there Any donation will help with funding the full run, which will begin in a few months time when the OpenMOSS devs release their official anime tune, and I finish my 6k artist style dataset, you can do so through: Crypto (Preferred, cause Kofi/Paypal money transfer time is ass and they take a big cut) 0x6a4bc748cd0bb9ced9a360eb0eb79f4f106614f8 (USDT - BEP20 Network - Custodial wallet) 12PPVYUeS1MerNp38Tpns5qXR6cmhu9tws (Bitcoin - BTC Network - Custodial wallet) 0x6a4bc748cd0bb9ced9a360eb0eb79f4f106614f8 (Ethereum - ERC20 Network - Custodial wallet) GKjLvD9XGAhyEpsZvEUNH5je9PFbrivoV5yBfYKGYskq (Solana - SOL network - Non Custodial wallet) Please handle your money carefully and make sure the address you're sending to is correct. Please contact me through discord (user: talannnn) if you're donating with crypto, to make sure it goes through and you're not losing money. Ko-fi https://ko-fi.com/talanartvn Acknowledgments Beeg thanks to: - Disty0 — The free MI300X compute that made this whole test possible, the biggest thanks to them - OpenMOSS — Creators of MOSS-Image, absolute fuckin legends for providing open source with this amazing base model - Bluvoll — Creator of mage-flow-trainer that my fork is derived from, and general training advice - Motimalu — Inspiration behind finetuning practices and configs, like lowering the LR at every resolution stage (should be obvious but I didn't remember first time) - KBlueLeaf — Future sponsor for MossAD - Anzhc — Detection models used for the bounding box captions, and general training advice - Format inspired by Motimalu's Kirazuri diary
MOSS-Imageの出力仕様メモ：1K/2Kと7比率、参照画像なし MOSS-Image を実際の制作フローに組み込む前に、「何が出せて、何が出せないか」を一枚にまとめておきたくなったので、その整理メモです。プロンプトのコツではなく、解像度・比率・枚数・できないことといった出力仕様の話に絞ります。 先にお断りしておくと、この記事は AI の支援を受けて下書きし、私が手で確認・編集しました。掲載画像はすべて AI 生成で、MixVio のモデルページのギャラリーにある MOSS-Image の実際の出力を、拡大せず元サイズのまま載せています。 モデル側の仕様（OpenMOSS 公式） モデルファミリーは MOSS-Image-Base と MOSS-Image-SFT の 2 つ。SFT は Base を厳選データで微調整したもので、同じアーキテクチャとサンプリング設定を共有します。 5B のバックボーン、最大 4K トークンのプロンプト、JSON によるネイティブなレイアウト指定。 重みは Apache-2.0。 推奨サンプリングは Flow-matching Euler、50 ステップ、CFG 3。 ローカル実行は Python 3.10 以上と NVIDIA GPU が前提です。README には推論に必要な VRAM の下限は書かれておらず、GPU メモリが足りない場合は Gradio の Sequential モードか、画像サイズを下げるよう案内されています。 そして一番大事な点として、これは文生図専用のモデルです。既存画像の編集はできず、参照画像も入力できません。 参照画像がない、ということの意味 画像編集系のモデルに慣れていると、「この写真の看板の文字だけ差し替えたい」と考えがちですが、MOSS-Image ではそれができません。私がフローを組むうえで決めたルールは次の 3 つです。 文言は生成前に確定させる。生成後の 1 語修正は、全体の再生成になる。 同じ構図を何度も出したい場合は、プロンプトを文章で固定し、位置が重要なら JSON レイアウトで bbox を固定する。 ブランドロゴや既存キャラクターを「参照で寄せる」ことはできないので、そもそも権利のあるものだけをプロンプトに書く。 MixVio で使う場合の出力仕様 ホスト型で使う場合の例として、MixVio のモデルページに載っている仕様を表にしました。 項目 内容 入力 英語・中国語のプロンプト、または items 配列を持つ JSON レイアウト プロンプト拡張 JSON レイアウトはそのまま送信、それ以外は拡張あり 出力形式 PNG 解像度 1K / 2K 比率 1:1、4:3、3:4、3:2、2:3、16:9、9:16 の 7 種類 枚数 1 回 1〜4 枚 ないもの 4K、21:9、seed、品質メニュー、ネガティブプロンプト サンプリング 50 ステップ、guidance 3 で固定 seed がないので、同じプロンプトでも再実行の結果は再現できません。ローカルの Python パイプラインでは generator に seed を渡せるので、再現性が必要な検証はローカル、と使い分けるのが現実的です。 クレジットの見積もりを関数にしておく MixVio のページで確認できるのは、1 枚あたり 2〜14 クレジットという幅と、次の 3 点の具体値です。 1K・16:9：2 クレジット 1K・1:1（デフォルト）：4 クレジット 2K・1:1：14 クレジット 枚数を増やすとその分掛け算になり、失敗した生成はクレジットを消費しません。私はバッチを組む前にこれをコードに落としておきました。分かっていない組み合わせは推測せず None を返すようにしています。 KNOWN = {("1K", "16:9"): 2, ("1K", "1:1"): 4, ("2K", "1:1"): 14} RATIOS = {"1:1", "4:3", "3:4", "3:2", "2:3", "16:9", "9:16"} def quote(res, ratio, n=1): if res not in ("1K", "2K") or ratio not in RATIOS: raise ValueError(f"unsupported: {res} {ratio}") if not 1 <= n <= 4: raise ValueError("1-4 images per request") per = KNOWN.get((res, ratio)) return None if per is None else per * n print(quote("1K", "16:9", 4)) # 8 print(quote("2K", "1:1", 2)) # 28 print(quote("2K", "9:16")) # None -> ページの表示を見る 実行すると 8、28、None が出ます。None になったものは、生成ボタンに表示される見積もりを見てから決めます。21:9 や 5 枚を渡すと ValueError になるので、存在しない設定をバッチに混ぜる事故も防げます。 ギャラリー出力の実寸を測ってみた 比率ごとの見え方を確認するため、ギャラリーの出力ファイルの実寸を私が一枚ずつ測りました。下の 4 枚は横長・縦長・文書ページと、形の違うものを選んでいます。 MixVio ギャラリーの MOSS-Image 実出力（AI 生成、1680×944）。横長の写真風シーン。 MixVio ギャラリーの MOSS-Image 実出力（AI 生成、944×1680）。縦長で、UI の小さな文字が多い例。 MixVio ギャラリーの MOSS-Image 実出力（AI 生成、1056×1488）。 MixVio ギャラリーの MOSS-Image 実出力（AI 生成、1088×1456）。 測った値は 1680×944、944×1680、1056×1488、1088×1456 でした。ファイル名や表示からはどの解像度設定で出したかまでは分からないので、ここでは「実寸はこうだった」という記録にとどめます。自分の用途で必要なピクセル数がある場合は、1K と 2K の両方で一度出して実寸を確かめるのが確実です。 文書ページ系の 2 枚は、ぱっと見では整っていますが、よく読むと崩れた字や式が混じっています。模試用紙や教科書のような「読まれる前提」のものは、モックアップや雰囲気づくりまでに使うのが安全です。 ローカル実行とホスト型の使い分け 仕様を並べてみると、ローカル実行とホスト型では向いている用途がはっきり分かれます。 ローカル（公式パイプライン）が向いているケース 再現性が必要な検証。Python パイプラインは generator に seed を渡せるので、同じ条件で結果を比べられます。 サンプリング設定を変えて試したいとき。公式の推奨値は 50 ステップ・CFG 3 ですが、ローカルなら自分で調整できます。 Base と SFT を両方試したいとき。公式ページには、同じプロンプトで SFT のほうが文字のまとまりやホワイトボードの配置が整理された例が載っています。 ホスト型が向いているケース GPU を用意せずに、まず出力の傾向を見たいとき。 比率や枚数を切り替えながら、構図の当たりを付けたいとき。 一方で、ホスト型には seed もネガティブプロンプトもないので、「前回とまったく同じ画像をもう一度」という使い方はできません。私は、当たりを付ける段階とレイアウトを詰める段階を分けて考えるようにしています。 比率の選び方 7 つの比率は、用途から逆算すると選びやすくなります。 16:9：ブログのアイキャッチ、横長のバナー、スライドの背景。 9:16：スマホの縦画面、ショート動画のサムネイル、配信画面の模型。 3:4・2:3：ポスター、チラシ、文書ページの模型。 1:1：SNS の正方形投稿、アイコン周りの素材。 4:3・3:2：写真らしい横構図、商品写真風のシーン。 21:9 のような超横長はないので、横長バナーが必要な場合は 16:9 で出して、後から上下を切る前提で構図を組みます。そのときは文字を画面の中央寄りに置いておくと、切り取りで文字が欠ける事故を避けられます。JSON レイアウトを使う場合は、bbox の座標を要求する幅と高さに合わせる必要がある点にも注意してください。 まとめ 文生図専用。編集・参照画像はない。文言は生成前に確定させる。 MixVio 経由なら 1K/2K、7 比率、1〜4 枚、PNG。seed とネガティブプロンプトはない。 クレジットは分かっている値だけをコードにし、不明な組み合わせは画面の見積もりで確認する。 小さく密な文字は必ず校正する。 参考 MOSS-Image 公式リポジトリ（README・ユーザーガイド） OpenMOSS 公式プロジェクトページ ブラウザから試す場合：MOSS-Image を試す
10 New GitHub Repos You Should Know (An AI Uses a Real iPhone & More) Ten of the most interesting new open source projects on GitHub: an AI that uses a real iPhone with a $7 chip, a project rebuilding the world's software for free, code that becomes a neural net, a fix for smart TV ads and more. Every pick explained in about a minute, from its README. Chapters 0:00 Intro 0:21 #10 datalab-to/indra – OCR at 49 pages per second 0:51 #9 shaongitbd/doory – A Canva alternative with no paid plan 1:18 #8 OpenMOSS/MOSS-Image – An open image model that writes text 1:42 #7 ahwootech/BRUTAL – The framework under RimWorld's new engine 2:16 #6 SubmitGame/awesome-decomp-games – 1,800 classic games rebuilt for PC 2:46 #5 rohit267/net-merge – Combine every internet connection 3:17 #4 Gathin23/tv-vibehack – Your smart TV, minus the ads 3:45 #3 chenglou/handwired – Normal code as a neural network 4:13 #2 HeyPuter/everything – Rebuilding the world's software for free 4:44 #1 onehumanbeing/esp32-iphone-agent – An AI uses a real iPhone 5:13 Outro Repos #10 datalab-to/indra: datalab-to/indra #9 shaongitbd/doory: shaongitbd/doory #8 OpenMOSS/MOSS-Image: OpenMOSS/MOSS-Image #7 ahwootech/BRUTAL: ahwootech/BRUTAL #6 SubmitGame/awesome-decomp-games: SubmitGame/awesome-decomp-games #5 rohit267/net-merge: rohit267/net-merge #4 Gathin23/tv-vibehack: Gathin23/tv-vibehack #3 chenglou/handwired: chenglou/handwired #2 HeyPuter/everything: HeyPuter/everything #1 onehumanbeing/esp32-iphone-agent: onehumanbeing/esp32-iphone-agent Scripts written from each project's README; check the repos for details. Music: "Ouroboros" by Kevin MacLeod (incompetech.com), licensed under Creative Commons: By Attribution 4.0 License creativecommons.org
MOSS-Image: a new free AI image model that writes long, clear text MOSS-Image is an open text-to-image model family from the OpenMOSS team, released on 16 Oct 2026 in Base and SFT versions. Its model weights are licensed under Apache 2.0. It is built to render long, clear text inside images, in English and Chinese, and a JSON layout prompt lets you set where each object and line of text goes using bounding boxes. In OpenMOSS's own Base vs SFT example, the SFT version groups the text more clearly. To run it yourself, the official quick start loads the model onto a CUDA (NVIDIA) GPU. Sources: - Project page: openmoss.ai - GitHub (README, quick start, Apache-2.0 licence): OpenMOSS/MOSS-Image - Hugging Face model card: huggingface.co - Technical report: openmoss.ai Media credits: images by OpenMOSS from the official MOSS-Image GitHub repository (Apache License 2.0): teaser, Base vs SFT comparison, layout-control diagram, and cropped showcase panels. The people and scenes in these images are the model's own AI-generated examples, not real photos. Not sponsored; not affiliated with OpenMOSS. Like it? Subscribe to Myth & Machine, and tap the bell. #Shorts #AI #AIImage #OpenSource
moss image 上线了！ AI 生图不只拼画质，连文字排版和元素布局都能控制了 moss image 开源了！： [OpenMOSS/MOSS-Image]( OpenMOSS/MOSS-Image) 平时用 AI 生图，应该不少人都遇到过类似的问题：画面看着不错，但图片里的文字经常出错；想做一张有明确布局的海报，生成结果却总和预期有差距。 MOSS-Image 的一个主要方向，就是让图片里的文字和布局更容易控制。 这个项目公开了代码和模型权重，模型规模约为 5B 参数。除了图片生成，它还关注文字渲染、布局控制和后续微调。 我感觉这类方向挺实用的。毕竟很多时候，我们需要的不是一张单纯好看的图片，而是能用来做海报、广告或者其他设计工作的素材。 当然，具体效果怎么样，还是得自己跑一跑，尤其是中文文字、复杂排版这些场景，值得单独测试。 这里推荐一个测试的站点： mossimage.art
【开源图像模型又多一个能玩的】MOSS-Image 有动漫、插画到写实风格，提示词空间也够大，想试不同视觉效果的可以点链接：OpenMOSS/MOSS-Image huggingface.co
Explore MOSS-Image ↓ 🎨 Live Demo: huggingface.co 💻 GitHub: OpenMOSS/MOSS-Image 🤗 Hugging Face: Base: huggingface.co SFT: huggingface.co 🖥️ Comfy-Org Model Repo: huggingface.co Try it out, and show us what you're creating!