<h1 id="kotojima-junichi's-workflow">Kotojima Junichi's Workflow</h1><blockquote>Have you ever tried a new ComfyUI workflow, only to find yourself falling deeper and deeper into the rabbit hole, looking for custom nodes and models? No? Only me, then? All right...</blockquote>If you use and like this workflow and would like to help me, select it as a resource you used when uploading an image to the site!The general idea of the simple workflow:<pre><code>first pass
 (optional 2nd pass)
 -&gt; upscale latent
 -&gt; second pass
-&gt; upscale image (optional)</code></pre>For the extended version:<pre><code>prompt enhancement (optional)
 -&gt; first pass
 (optional 2nd pass)
 -&gt; upscale latent
 -&gt; second pass
 -&gt; face detailer (optional)
 -&gt; upscale image (optional)</code></pre><h2 id="simple-version">Simple Version</h2>The simple version was designed to be plug-and-play:<ul><li>Zero custom nodes.</li><li>Small amount of nodes, laid out in a fairly left-to-right linear fashion: execution flow will not move to the left.</li><li>Subgraphs allow whole portions of the workflow to be safely bypassed.</li><li>Optional enhancer LoRA. (Krea 2 Turbo only)</li><li>4-step lightning LoRA included by default for Qwen Image 2512.</li><li>8-step turbo LoRA included by default for Anima.</li><li>Optional SeedVR upscaler.</li></ul><h2 id="notes">Notes</h2><ul><li>Designed with Nodes 2.0 in mind.</li><li>Peek at the draft, the output of the first stage: don't like it? Cancel the run, get another seed or rewrite the prompt.</li><li>Latent upscaling: upscaling the latent rather than an image allows the model to add some richer detail that will adhere a bit more closely to its "style."</li><li>Single seed: both samplers use the same seed. Although not strictly necessary, it does make things a bit easier to reproduce.</li><li>Simplifying assumptions: the two passes use the same parameters. The only exception is <code>denoise</code>, passed exclusively to the second pass. (Simple version only)</li><li>Denoise for the second pass: this goes from 0.0 to 1.0, where 0.0 basically means "do nothing", and 1.0 means "redraw it from scratch". I have found that values around 0.5 are generally optimal, though that might change depending on what you're working on. The closer to 0.0 you get, the more the second pass will look like the draft, but it won't add as much detail; the closer to 1.0 you get, the more the second pass will be a completely different image.</li><li>Upscaling the final image: <code>target_length</code> setup: set the desired length for the longest edge of the upscaled image.</li><li>Quantized/GGUF models: Most consumer graphics cards can't load whole models, as most cards have 4/6/8 GB VRAM, and models are easily larger than that. If you don't have enough VRAM to load the models completely, they will be offloaded to system RAM, and if you don't have a lot of system RAM this may mean you are simply unable to use heavy models to generate images. One alternative that alleviates this is using quantized models. Quantization is a process in which you transform a more precise weight number that needs more memory, and therefore more storage, into a less precise number that will therefore need less storage and RAM. As a simplification, you can think of it like "bucketing" a more precise number into a wider bucket. Quantized models lose a bit of quality; but the best ones can still produce generally great quality images. I have experimented with a Krea 2 Turbo Q3 K M model, and the results have been very good. Some W4A8 models are also great. Give it a try! I have included a recommendation for a custom node to load quantized GGUF models, Molbal's ComfyUI-GGUF nodes, and I recommend using the dynamic VRAM versions of these nodes. One alternative to using GGUFs is looking for the W4A8 versions of models, which don't require any special nodes, but are still very lightweight, with a reasonable quality trade-off.</li></ul><h2 id="extended-version">Extended Version</h2>The extended version was designed to require a few custom nodes, but to provide a few optional extras:<ul><li>Simple prompt enhancement.</li><li>Face detailer.</li></ul><h3 id="update-to-the-extended-version">Update to the Extended Version</h3>I shuffled some things around on the extended version, to make the basic interface a bit simpler. I tried to provide sane defaults, and give the setup some more flexibility, hopefully without making it unnecessarily complicated, by hiding away some complexity behind sub-graphs.<ul><li><code>scale_by</code> for the 2nd pass replaced by <code>megapixels_2nd_pass</code>. Rather than "I want the output of the 2nd pass to be scaled 2x", which would result in a 4x increase in megapixels, set the target megapixels. If you had a specific resolution in mind for the output of the 2nd pass, you'd have to calculate the scaling factor manually, <code>sqrt(megapixels_2nd_pass/megapixels_1st_pass)</code>, which I suppose not many people would know to do on their own, so this makes things simpler.</li><li>Integrate prompt enhancement into the image generation sub-graph. By my estimation this might give the automated systems that extract info from workflows here in Civitai a better chance of auto-extracting some more details, and this makes the interface a bit simpler, overall. Prompt enhancement is now toggled by the <code>enhance_prompt</code> switch. Parameters can still be fine-tuned, but you'll have to dig a bit deeper for that. I'm assuming that if you want to fine-tune this, you'll know what to do.</li></ul><h3 id="custom-nodes">Custom Nodes</h3><ul><li>Impact-Pack (<a target="_blank" rel="ugc" href="https://registry.comfy.org/nodes/comfyui-impact-pack">registry</a>, <a target="_blank" rel="ugc" href="https://github.com/ltdrdata/ComfyUI-Impact-Pack">github</a>) (face detailer)</li><li>LoraManager (<a target="_blank" rel="ugc" href="https://registry.comfy.org/nodes/comfyui-lora-manager">registry</a>, <a target="_blank" rel="ugc" href="https://github.com/willmiao/ComfyUI-Lora-Manager">github</a>) (convenience, for LoRAs)</li><li>Molbal's GGUF loader (<a target="_blank" rel="ugc" href="https://registry.comfy.org/nodes/comfyui-gguf-reboot">registry</a>, <a target="_blank" rel="ugc" href="https://github.com/molbal/ComfyUI-GGUF">github</a>) (if you want to load quantized GGUF models)</li></ul><h3 id="additional-models">Additional Models</h3><ul><li><code>models/ultralytics/bbox/face_yolov8m.pt</code>: <a target="_blank" rel="ugc" href="https://huggingface.co/datasets/Gourieff/ReActor/blob/main/models/detection/bbox/face_yolov8m.pt">link</a></li><li><code>models/sams/sam_vit_b_01ec64.pth</code>: <a target="_blank" rel="ugc" href="https://huggingface.co/datasets/Gourieff/ReActor/blob/main/models/sams/sam_vit_b_01ec64.pth">link</a></li></ul><h3 id="how-to-use-the-extended-version">How to use the extended version</h3>This is how I use the updated version of the extended workflow:<ol><li>Open workflow in ComfyUI. Duplicate it, rename it with a working title for your project. This step is optional, and makes more sense if you saved this workflow alongside your other ones; if you always open the workflow from a separate file you can skip this step.</li><li>Project title. Set the title of the project in the "Project" node. This setup will save everything to a directory with this name, with a sub-directories named "draft", for the output of the first sampling pass, "face_detailer", and "upscaled", and will also use different names for the images created by the face detailer and upscaler. Don't worry too much about the name; I once called a project <code>doves</code>, because I wanted it to feature doves, but I removed the doves in the end, so yeah... lol.</li><li>Exploration phase. Get a fixed seed. I generally just start with seed 0. Work on the prompt first, getting a different seed won't help you at this point. You may want to set a smaller size at this point, and/or lower the number of steps, if you want to iterate fast. Don't enable the second pass right now, as it will mostly be a waste of time. This is the right time to experiment with different aspect ratios, models and LoRAs, as they will change things significantly further down the line; if you want to generate a lot of pictures, and would like them to have somewhat of a coherent identity, changing LoRAs or models later is probably not a good idea. At this point you may also choose whether you'd like to have the prompt enhanced, or even written completely by writing some instructions in the <code>system_prompt</code> input of the <code>Prompt Enhancement</code> node. Including that in the normal run will take some additional time; with a fixed seed this will always result in the same text, so running it once and copying it back to the <code>Prompt</code> node is probably a good idea; you can do this by turning its bypass off and using the partial execution feature so that only the prompt enhancement will run, by selecting the <code>Preview as Text</code> node under the <code>Prompt Enhancement</code> node, and clicking the blue play button. If you choose to do this as a one-off thing, remember to bypass prompt enhancement when running the whole workflow later. At this stage you're not really worried about the finer details, just the overall picture. Once you are satisfied with what you see, you can go to the next step.</li><li>Drafting phase. At this point you can increase the number of steps to 8+, and set the size to 1+ mega-pixels for the first pass; bear in mind that each model has its ideal range of generation, and if you exceed it the results are likely to degrade. Krea 2 Turbo, for instance, has an optimal range between 1024-2048 for each side, and you should probably not exceed that in any sampling process, for better results. Now you will look at the finer details. At this point you probably should not change your prompt any more. Changing the aspect ratio of the image is also likely to result in a very different image. This is the right time to change the seed. If the image is consistently different from what you've expected, I would recommend you to go back to the previous step. One thing you can do at this step is to set the batch count a bit higher, to 4-8-16, do a bigger run, and select the resulting image you liked best.</li><li>Second pass. Decide whether your image would benefit from a second pass. If you're aiming for realism, this is generally the case. If you're creating an illustration, or using a simpler art style, there's a fair chance that a second pass won't be needed. The most important parameter for the second pass is <code>denoise</code>. A denoise of 0.0 basically means "do nothing", and 1.0 means "redraw from scratch"; both extremes are kind of meaningless for a second pass, so I would recommend you to experiment with values that are in the 0.25-0.50 range. The lower the value, the more the final image will look like the output of the first pass, but you won't add as much detail. You can grab the seed from an image made in the previous step, and run it again through the whole process, or just enable the second pass and use the partial execution feature on the "Compare images" to the right of the "Save Image" node in green, in the middle of the workflow. For the extended version I shifted the way things work, and I'm using a <code>start_step</code> and <code>stop_step</code> as parameters for the second pass; basically, we do a full-schedule run for the first stage, upscale the latent, and then perform a second pass. If we simply did a full-schedule run in the second pass, that would roughly be equivalent to <code>denoise</code> equal to 1.0, and we would just get a completely different image. Considering that a huge chunk of the work was already done in the first pass, and that each step in the schedule actually gets to finer details, I'm splitting the sigmas and feeding the low sigmas to the second stage. I feed <code>stop_step</code> into the actual number of steps for the whole schedule, and <code>start_step</code> as the step from which the sampling will begin; by default, that's 8 and 4, respectively, so that only the second half of the sampling process will be performed. If the image comes out looking "overcooked", you can increase <code>start_step</code> and/or reduce <code>stop_step</code>; if the images shows signs that it was under-sampled - such as appearing "pixelated", or being behind those fogged square glasses - you should probably decrease <code>start_step</code>, so the second pass will do more work.</li><li>Face detailer. Will the image need face detailing? If there are no humans in the image, the answer is more obviously "no". If the person's face is "close to the camera" (i.e., it occupies a large portion of the image), and particularly if it doesn't look "wrong" or awkward in some way, you may skip this step. For one particular image, the model kept creating a green "aura" around the subject's eyes, instead of properly giving them green eyes, because they weren't very close to the camera, so I had to "fix" this by using the face detailer. You can use the face detailer to change the expression or even where someone is looking, for instance.</li><li>Upscaling. Will the image need upscaling? If you'd like to have a bigger image, you can turn the bypass off on the upscaling nodes, and use the partial execution on the "Compare images" node in this group. If you run out of memory, try lowering the <code>target_length</code> parameter. The upscaler will actually downscale your image if <code>target_length</code> is less than the longer side of your image.</li></ol><h3 id="general-notes">General Notes</h3>I ended up using sub-graphs as a way to hide the samplers, as these might be considered "implementation details." This is a bit of a compromise, but it allows the extended version to be a bit more user-friendly. I used the built-in <code>SamplerCustom</code> under the hood, and chose not to expose all sampler and scheduler parameters, because these can vary wildly. If you take a look at the parameters exposed by <code>KSampler</code>, <code>KSampler (Advanced)</code>, <code>SamplerCustom</code>, and <code>SamplerCustomAdvanced</code>, the built-ins, and different sampler/scheduler configurations, such as <code>ClownsharKSampler</code>, or using <code>FlowMatch Euler Discrete Scheduler</code>, you'll quickly realize that even though these essentially perform the same job, they are very, very different, and have very different knobs to tune, so I chose to just "blackbox" the sampler; though perhaps it would be more accurate to say I chose to "graybox" the sampler, because these parameters can still be accessed and tuned, but you'll have to dive a bit deeper in the sub-graphs.<h2 id="general-notes-on-krea-2-turbo">General notes on Krea 2 Turbo</h2>This model has been documented as using CFG 1.0, which roughly means that negative prompts wouldn't work. Using a CFG++ sampler such as <code>euler_ancestral_cfg_pp</code> and setting CFG to 1.2 allows us to have a negative prompt, but bear in mind that this model is different from SD/SDXL, and won't generally work very well with high weights. CFG greater than 1.2-ish is likely to result in images looking "overcooked," and setting weights greater than 1.2-ish (<code>(thin eyebrows:2.0)</code>) probably will not get you good results. I would generally advise you to stick to the positive prompt, try to describe things in as much detail as you can, and avoid creating a long tag-like negative prompt. Or you can just ignore this, go for it, and report back that you had great success. I don't know, I'm not the boss of you.<h2 id="what-can-come-next">What can come next?</h2>Possible next steps to improve the workflow:<ul><li>Prompt enhancement (Extended)</li><li>Face detailer (Extended)</li><li>General detailer (Maybe for a future version of Extended, or an alternative workflow)</li><li>If you have any suggestions, feel free to ask!</li></ul><h2 id="tested-with">Tested with</h2><h3 id="versions">Versions</h3><ul><li>ComfyUI: 0.33.3</li><li>Frontend: 1.49.6</li><li>Templates: 0.11.44</li><li>Python: 3.14.7</li><li>PyTorch: 2.13.0+cu130</li></ul>

Kotojima Junichi's Workflow

V1: 2-Pass Image generation with optional SeedVR2 upscaling

kotojimaJunichisSimple_zimageturboV10.json

kotojimaJunichis_zimageturboSimple.json

kotojimaJunichis_zimageturboSimple.zip

Files with SHA256: 803d981472249ccaa6d065e50466197e83f213b0618891701ee84ceead4e7931