Krea 2 cleanup graphs all share the same skeleton, and once you see it the three workflows in this episode stop looking like three different products. They are one recipe wrapped in three different I/O shells: a single image, a local folder loop, and a RunningHub ZIP batch.
The recipe: reverse-prompt the input image into a Krea 2 prompt, rebuild it through three depth-structure passes with one structure LoRA, then upscale with 4x-UltraSharp. A console at the top of each graph controls the render stages, the final long edge, and which reverse-prompt route to use.
No inference was run for this release. Everything below is read from the saved nodes.
| Variant | File | Nodes / links | I/O |
|---|---|---|---|
| Single image | 01 | 51 / 89 | one LoadImage |
| Local batch | 02 | 57 / 98 | folder loop, local-only |
| Online batch | 03 | 66 / 109 | RunningHub ZIP + batch nodes |
The shared engine
All three load krea2_turbo_fp8.safetensors, encode text with qwen3vl_4b_fp8_scaled.safetensors (type krea2) and use qwen_image_HDR_vae_fp32_comfy.safetensors as the VAE. There is exactly one structure LoRA — a Krea2ControlLoRALoader on depth-control-lora.safetensors at strength 1.0. If you were expecting the three-strength preset trio from the later cleanup release, that is a different episode; this one uses a single shared LoRA.
The depth side is three Krea2ControlImageEncode → Krea2ControlApply pairs: source-size encoding for the high-noise stage, a mid-size encoding, and a final-size encoding. The depth maps come from DA3 nodes in-graph.
Sampling is three KSamplers at 8 steps, CFG 1, euler, simple. Denoise is 0.55 in the single-image file and 0.95 in the two batch files for the base pass, then 0.35 and 0.25 for the following passes. Two LatentUpscale nodes are present but saved disabled; the real upscale is UpscaleModelLoader with 4x-UltraSharp.pth plus ImageUpscaleWithModel.
The reverse-prompt stage has two routes: Qwen3VLProcessor for the open-source path, and an RH_LLMAPI_Pro_Node for the closed path (its model label is GLM-4.6V). The console decides which one is active.
01 — Single image: the cleanest read
The single-image file is the best place to understand the recipe. One LoadImage, the console, three depth passes, the upscale, and a save to KSK_Krea2_ReverseDepthHires. ConditioningKrea2Rebalance is saved bypassed here, and the ComfyUI-Krea2T-Enhancer patch is saved enabled.
Practical dial: the graph's own note says 2048 on the long edge is the value-for-money point and that 3072/4096 increase VRAM and cost noticeably. That is the author's guidance, not a measured benchmark.
02 — Local folder batch: the one that stays on your machine
This is the local-only variant. The batch loop is easy loadImagesForLoop + easy forLoopEnd + easy batchAnything, and the save prefix is Krea2_本地批量洗图/Krea2_batch. Each image gets its own reverse prompt, its own width/height calculation and its own depth extraction — results are not reused across the folder.
Two things worth flagging:
- There is no RunningHub page for this one in the source material. A CN-catalog page titled "Krea+2本地批量洗图 (仅本地使用)" exists, but the episode's 说明 does not list it and the title itself says local use only. I treated the workflow as local-only and did not link that page.
- The in-graph note is stale. It still says "线上批量版" (online batch), but the nodes are a local folder loop and the output path is the local-batch path. Trust the node graph, not the note text. This is exactly the kind of thing that makes someone think they uploaded a ZIP when they queued a folder.
03 — Online batch: RunningHub does the I/O
The online variant swaps the local loop for RHUploadZip, RHBatchImages: (range like 0-9), RH_ExtractImage and a for-loop start/end pair. You upload a ZIP containing only jpg/jpeg/png/webp images, enter the exact image count, and the graph derives the index range from it.
Outside RunningHub those nodes will not resolve — it is a platform-bound workflow, not a broken one. Per the saved note, each image is reverse-prompted and depth-encoded independently; the first image's prompt is not reused for the batch.
How I would sequence a first run
Start with 01 on one image at 2048 to see whether the reverse prompt and structure lock behave the way you expect. Only then move to 02 for a folder; use 03 when you specifically want the RunningHub caption path and platform compute. If you are debugging batch output, check the per-image prompt and dimensions first — the most likely failure is a bad reverse prompt on one image, not the structure stages.
What this is not
Not a benchmark, not a fidelity test, and not a license grant. The video's framing about a one-stop cleanup solution and free workflows is the author's description. The files carry no grant for the checkpoint, the LoRA, the depth model, the upscaler or the VLM route.
Getting the workflows
Published by this channel. The graphs are free; the checkpoint, LoRA, depth model, upscaler and example media are not bundled.
- Hugging Face: AI-KSK/krea2-advanced-cleanup-280 — three JSONs, source covers, SHA256 manifest. Start here.
- ModelScope (魔搭): Sunjian520/krea2-advanced-cleanup-280
- Civitai: 01 single image · 02 local batch · 03 online batch
-
Run without a local GPU: 01 · 03 — these carry the author's invite code
rh-v1111. (02 is local-only.) - Tutorial: YouTube · Bilibili
Verify workflow, node, model, LoRA, depth model, upscaler, VLM route, input-image and cover rights separately. No blanket commercial or redistribution license is asserted for the graphs or the example media.
Top comments (0)