comfyanonymous

ஒவ்வொரு படமும் வேறு மாதிரி வருகிறதா ? ComfyUI-ல் ஒரே workflow, உங்கள் கணினியிலேயே இயங்குகிறது. தமிழ் thumbnail தொடருக்கு ஏற்றது. ஒரே கதாபாத்திரமா, புதிய பாணியா ? comfyanonymous/ComfyUI Instagram-லும் பின்தொடருங்கள்: instagram.com

Some Data You Can't Wait For. Some You Can't Survive. Generating the off-road edge cases a robot can't collect, with ComfyUI running inside FiftyOne, and every synthetic frame is traceable to the real one it came from. !image.mux.com An off-road robot only knows the days it was driven. Its training data was collected on a handful of routes, in whatever weather those runs happened to have, across ground that was mostly safe to cross. The world you deploy it into is wider and meaner than that. This post walks through a workflow for generating synthetic training data with ComfyUI, running directly inside FiftyOne. You produce the conditions and obstacles your robot will face but your dataset never captured, and keep every generated frame linked back to the real one it came from. There are two kinds of missing data here. The kind you can't wait for: every season, every time of day, at every site, on a collection schedule that would take a year. And, the kind you can't survive: nobody is going to point a real vehicle at a flooded trail or a washout just to film what failure looks like. The most safety-critical data is the data that is hardest, or most dangerous, to get. The fix is a data generation engine. ComfyUI generates the data you can't collect. FiftyOne is where you decide which gaps are worth filling, and where you catch the generations that lie. Generation on its own is chaos. Curation is what turns it into a dataset. Why is the most safety-critical off-road data is the hardest to collect? !image.mux.com Two gaps appear in almost every perception dataset for robots moving through the real world. The first is condition coverage. A model that has only seen bright, dry conditions has quietly learned that the world is bright and dry. Rain, fog, dusk, low sun, and snow change the appearance of everything, including the ground the robot has to judge. The second gap is obstacle scarcity. The events you most need the model to handle correctly, standing water, deep mud, a downed tree across the trail, and a washed-out section of road, are exactly the events that are rare in normal operation. A dataset built from ordinary driving is mostly made of ordinary driving. Both gaps are expensive to close by collecting more data, and for the obstacles, collecting more is not just expensive but also unsafe. You cannot responsibly drive a real vehicle toward a flood to capture a few hundred frames of it. So the data you need most is the data you are least able to gather. That is the problem: synthetic data is actually good at it, as long as you stay disciplined about which synthetic frames you trust. Key Takeaways - The most safety-critical off-road perception data, adverse weather and dangerous obstacles, is also the hardest and least safe to collect in the real world. Generating it synthetically targets exactly those gaps without putting a vehicle at risk. - The ComfyUI plugin runs inside the FiftyOne sample modal, so you curate, generate, and review synthetic data in one loop instead of switching between two separate tools. - Every ComfyUI generation saved in FiftyOne stores its generation parameters (prompt, seed, sampler, steps, CFG, and model) and the full workflow graph on the new sample, and embeds the generating workflow in the output image, so any synthetic frame can be reproduced and traced back to the real frame it came from. - Generating synthetic data is only half the loop. Curating it in FiftyOne, culling near-duplicates and catching frames whose edits no longer match their labels, is what keeps synthetic data from degrading the model. - Synthetic generation augments real-world data collection rather than replacing it, because these edits change camera appearance, not the underlying 3D sensor ground truth. The STONE dataset and the ComfyUI–FiftyOne integration For a concrete example, this walkthrough uses STONE, an off-road traversability dataset from ICRA 2026 (parsed as a FiftyOne grouped dataset). Each group is a single keyframe from the vehicle and contains seven slices: six surround cameras (CAM_FRONT, CAM_FRONT_LEFT, CAM_FRONT_RIGHT, CAM_BACK, CAM_BACK_LEFT, CAM_BACK_RIGHT) and a LIDAR_TOP 3D scene. Every frame carries a terrain label derived from the voxel grid, with classes free, traversable, potentially traversable, and non-traversable, plus per-frame fractions like pct_non_traversable that tell you how much of the scene falls into each class. !image.mux.com The ComfyUI plugin embeds a full ComfyUI instance inside the FiftyOne sample modal. Open a sample, open the ComfyUI tab, and the current slice is already available as an input image. Run any workflow against it and save the result back to your dataset as a new sample or a new group slice. Every save records the generation parameters as fields on the new sample (the prompt, seed, model, sampler, and the rest) and writes a source_sample_id that points back to the frame you started from. That link is the whole point. !image.mux.com Synthetic data you can trace is an asset. Synthetic data you can't trace is a liability. > The remainder of this piece assumes you have FiftyOne and the ComfyUI plugin installed, and that the appropriate models for each workflow have been downloaded. The workflow will tell you which models you need to download. These docs will teach you how to download models. > Good to know. How do you generate synthetic training data for an autonomous robot? > > Start from real frames, not from scratch. You open a real sample inside FiftyOne, run a ComfyUI workflow against it to change conditions or add an obstacle, and save the result back to the dataset with its generation parameters and a link to the source frame. Then you review the results in FiftyOne and keep only the ones that hold up. Step 1: Find the data gaps in FiftyOne You don't generate blindly. You look first, and you let the dataset tell you what it is short on. Load STONE, compute an embedding visualization on one camera slice, and launch the App. import fiftyone as fo import fiftyone.brain as fob from fiftyone.utils.huggingface import load_from_hub dataset = load_from_hub("Voxel51/STONE") # Study appearance coverage on one camera slice cam_front = dataset.select_group_slices("CAM_FRONT") fob.compute_visualization(cam_front, brain_key="cam_front_viz") # pass model=... or your own embeddings session = fo.launch_app(dataset) In the App, open the embeddings plot. Then color the grid by terrain, or any other sample field, and scrub through the samples to get a feel for the data. You are looking for two things. First, there is the variety in scene conditions. Collection campaigns tend to run in workable weather, so the conditions in the data are usually far narrower than the conditions the robot will drive in. Look at how tightly the points group together. Second, is how rare any adverse/dangerous frames are. Use the terrain fractions to gauge how often the vehicle actually met non-traversable ground. In most collections, these frames are a small minority. !image.mux.com As you explore, tag what you want to work from. Tag frames you want to in-paint. Tag clean, drivable scenes you will use as canvases for in-painting some type of driving obstacle. By tagging, you’re deciding, by eye, which real frames are worth turning into synthetic ones. If you would rather start from the numbers, you can tag samples programmatically using the FiftyOne SDK and refine them by hand from there. from fiftyone import ViewField as F # Optional: seed the restyle set from a fraction threshold, then refine in the App cam_front.match(F("pct_non_traversable") > YOUR_CUTOFF).tag_samples("restyle") !image.mux.com Step 2: Generate the weather conditions you can't wait for You don’t necessarily need to edit all six group slices (cameras) and hope they agree. You can edit one group slice and generate the other views from it. One edit becomes a coherent keyframe. > Good to know. What is domain randomization, and how does this relate? > > Domain randomization means varying the appearance of your training data (lighting, weather, textures, viewpoints) so that a model learns the underlying task rather than the look of the collection conditions. Restyling real frames into rain, fog, dusk, and snow is a targeted form of it, aimed at the specific conditions your data lacks rather than at random noise. Open one of your restyle groups, go to the CAM_FRONT slice, and open the ComfyUI tab. The slice is already loaded as the input image. Build a simple restyle: load the image, run it through the Qwen-Image-Edit workflow (or a similar workflow) with a conditional prompt (rain on the trail, heavy fog, dusk light, fresh snow), then save the result by right-clicking the SaveImage node and selecting Save as a new sample. That single save creates a fresh synthetic keyframe, tags it as a ComfyUI output, captures the generation parameters, and writes source_sample_id back to the real frame. > Example prompts: Qwen-Image-Edit weather restyle (run on CAM_FRONT first) > > Rain: “Make this an overcast, rainy scene. Wet ground with puddles and reflections, light rain in the air, dark gray sky, lower contrast. Keep the terrain layout, objects, and camera framing identical.” > > Fog: “Add dense fog that reduces visibility. Soft, diffuse light, muted colours, low contrast, distant terrain fading into a gray haze. Keep all terrain and objects in the same positions.” > > Dusk: “Change the time of day to dusk. Warm, low-angle light, long shadows, an orange-and-pink sky, dimmer overall illumination. Preserve the scene contents and camera framing.” > > Night: “Convert the scene to night. Mostly dark, lit by the vehicle's headlights, with deep shadows and faint ambient skylight. Keep the ground and obstacles unchanged.” > > Snow: “Cover the scene in fresh snow. White snow on the ground and surfaces, cool overcast light, light snowfall, reduced colour saturation. Keep the underlying terrain shape and object positions the same.” > > Starting points, tune to taste. The clause about keeping geometry and objects fixed matters: it pushes the edit toward appearance-only changes, so the terrain label underneath remains as valid as possible. The gate step in Step 4 is where you catch the cases that did not hold. !image.mux.com Now fill the rest of the rig from that single edited frame. Open the new seed sample, open the ComfyUI tab, and load the 1-click Multiple Scene Angles template, which takes one image and produces several viewpoints. Adapt it once into a reusable STONE rig and save it, so every future keyframe is one click. > Camera-angle prompts: paste one per output branch > > CAM_FRONT: “Forward-facing view from the vehicle, looking straight ahead along the trail. Keep the same weather, lighting, time of day, and ground surface as the input image.” > > CAM_FRONT_LEFT: “Rotate the camera about 55 degrees to the left at the same mounting height, showing the terrain ahead and to the left of the vehicle. Match the input's weather, lighting, and ground surface exactly.” > > CAM_FRONT_RIGHT: “Rotate the camera about 55 degrees to the right at the same mounting height, showing the terrain ahead and to the right of the vehicle. Match the input's weather, lighting, and ground surface exactly.” > > CAM_BACK: “Rear-facing view from the vehicle, looking directly behind it along the trail it has traveled. Keep the same weather, lighting, time of day, and ground surface as the input.” > > CAM_BACK_LEFT: “Rotate the camera about 120 degrees to the left, showing the terrain behind and to the left of the vehicle. Match the input's weather, lighting, and ground surface exactly.” > > CAM_BACK_RIGHT: “Rotate the camera about 120 degrees to the right, showing the terrain behind and to the right of the vehicle. Match the input's weather, lighting, and ground surface exactly.” > > Front and side views share real content with the input and stay fairly grounded. The rear views are largely invented, since the front image holds no information about what is behind the vehicle; scrutinize those hardest at the gate. You can also keep your original seed as CAM_FRONT instead of regenerating it. !image.mux.com > Keep it honest. The multiple-angles workflow produces plausible alternate viewpoints, not geometrically calibrated reprojections of the real camera extrinsics. Nothing in this step touches the LIDAR_TOP slice or the voxel ground truth. You are augmenting camera appearance, not regenerating the sensor rig, and the post should say so plainly. Step 3: Stage the off-road obstacles you can't drive through Track A changes the weather. Track B changes what is on the ground. The mechanics are the same two stages, with one addition at the end: you label the obstacle yourself in the App. Open one of your images tagged as comfy_output groups at the CAM_FRONT slice, then open the ComfyUI tab. Look for the Flux Infill workflow. Mask the part of the trail where the obstacle should go, in-paint a plausible danger into it (standing water, deep mud, a fallen tree, a washout), and save the edited image as a new sample. Image only for now, no label yet. !image.mux.com Then fill the six camera views from this seed exactly as in Step 2, using the template you saved, so every camera shows the staged obstacle. > Example prompts: obstacle inpainting (mask the trail region first) > > Standing water: “A wide puddle of muddy standing water across the trail, reflecting the sky and surrounding terrain, blending naturally into the dirt at the edges. Match the scene lighting and perspective.” > > Deep mud: “A stretch of deep, wet mud with tire ruts, dark saturated brown, blending into the surrounding dry trail. Match the scene lighting and perspective.” > > Fallen tree: “A fallen tree trunk lying across the trail, with bark texture and a few broken branches, casting shadows consistent with the scene lighting. Blend naturally into the surroundings.” > > Washout: “A washed-out, eroded section of trail with a rutted gully, exposed soil and loose rocks, and crumbling edges. Match the surrounding terrain, lighting, and perspective.” > > Rockfall: “A pile of fallen rocks and rubble of varied sizes across the trail, with shadows matching the scene lighting. Blend into the surrounding ground.” > > Keep the mask tight to the region you want changed. Everything outside the mask stays real, which is exactly why you can annotate the obstacle with confidence afterward. !image.mux.com Now label it. Because you placed the obstacle, you know exactly where it is, so the annotation is quick and reliable. Open the new synthetic group and annotate the obstacle region directly in the FiftyOne App on each camera view that shows it. !image.mux.com > Keep it honest. The obstacle label is a camera-space annotation you draw by hand. It does not modify STONE's 3D voxel ground truth, and it should not pretend to do so. You are intentionally adding a new label to a synthetic frame and making it clear. The LIDAR_TOP geometry under the synthetic frame is not edited. > Good to know. Can you add labels to AI-generated images? > > Yes. When you stage an obstacle, you place yourself so you know exactly where it is, then annotate it directly in the FiftyOne App on the views that show it and deliberately set the class label. The label is a real annotation you author on the synthetic frame, separate from any 3D ground truth in the original dataset. Step 4: Keep the synthetic data honest Everything you generate is a guess until you check it. This is the half of the loop people skip, and it is the half that decides whether your synthetic data helps the model or quietly poisons it. Go back to FiftyOne, bring the new samples into the picture, and look hard. Two things go wrong, and both are visible. The first is redundancy. You will often generate what feels like 40 new frames, but they are really just one frame with small variations. Rank the camera slices by uniqueness, or run a similarity index and cull near-duplicates, because they add cost and bias without increasing coverage. The second is label conflict. A restyle can contradict the label underneath it. If a snow pass buries a path that the terrain label still marks as traversable, the pixels now indicate impassability, while the label says go, and training on that teaches the model the wrong lesson. Cut those, or relabel them on purpose. Same check for the obstacles: if a staged obstacle reads wrong or the region is sloppy, fix it before it ships. Generation is chaos. FiftyOne is where the chaos gets caught. > Good to know. How do you stop synthetic data from corrupting your dataset? > > Curate before you train. Use uniqueness or similarity to remove near-duplicates that add bias without coverage, and review for label conflicts where an edit no longer matches the label underneath it. Approve frames explicitly, and keep the link back to each source frame so the synthetic data stays auditable. The payoff: ComfyUI and FiftyOne as one loop Train from your real frames plus the synthetic ones you approved. Because every generated frame carries source_sample_id, you can always trace a synthetic sample back to the real keyframe it grew out of, audit what you added, and reproduce any of it from the saved generation parameters. The change is in the cost of hard requests. We need rain data, so we need to schedule a field day. We need washout data, which means finding a washout and driving at it. You curate in FiftyOne to find what is missing, generate it in ComfyUI without leaving the app, gate it back in FiftyOne, and train. ComfyUI and FiftyOne stop being two tools and become one loop. Random generation, tamed by curation. > Good to know. Does this replace real-world data collection? > > No. It fills gaps that are slow or unsafe to collect, in addition to real data. The honest framing is augmentation, not replacement: generated frames are plausible, not measured, and they earn their place by surviving review. Try the workflow yourself Install FiftyOne, ComfyUI, the plugin, load STONE, and run the loop on a few frames of your own. The links below get you to the dataset, the workflow template, and the docs. - FiftyOne ComfyUI plugin: harpreetsahota204/ComfyUI_in_FiftyOne - STONE dataset: huggingface.co - 1 click Multiple Scene Angles template: comfy.org workflow template - FiftyOne docs: docs.voxel51.com - ComfyUI: comfyanonymous/ComfyUI Frequently Asked Questions Does generating the other five camera views from one edited frame preserve geometry? No. The multiple-angles ComfyUI workflow generates plausible alternate viewpoints, not geometrically calibrated reprojections of the real camera extrinsics. The front and side views share real content with the seed frame and stay fairly grounded, while the rear views are largely invented, since the front frame holds no information about what is behind the vehicle, so scrutinize those hardest during review. This step changes camera appearance only and never touches the LIDAR_TOP slice or the voxel ground truth. Are STONE's original 3D voxel labels still valid on a synthetic frame? Not automatically. The 3D voxel ground truth from STONE is left unedited when you generate a synthetic frame, but the new pixels can contradict it. A snow restyle can bury a path the terrain label still marks traversable, and a staged obstacle can sit on ground still labeled free. Treat the original 3D labels as unverified on any synthetic frame, then either cut the conflicts or relabel them deliberately in FiftyOne. Any obstacle you draw is a camera-space annotation, separate from the 3D ground truth. What gets stored on each synthetic sample, and can I reproduce it? Every save through the ComfyUI plugin in FiftyOne records the generation parameters (prompt, seed, sampler, steps, CFG, and model) and the full workflow graph as fields on the new sample. The plugin also embeds the generating workflow in the output image's PNG metadata, so opening that sample later auto-reloads the exact graph that made it, including a loader pointing at the original source image. That makes any synthetic sample reproducible and traceable to its origin. How do I stop near-duplicate generations from inflating the dataset? Use the FiftyOne Brain to rank the camera slices by uniqueness, or build a similarity index and cull near-duplicates before training. Forty new frames that are really one frame with small variations add cost and bias without adding coverage. Can I drive curation and tagging from the SDK instead of by hand? Yes. The FiftyOne SDK lets you tag candidate frames programmatically, for example by thresholding on the pct_non_traversable field, and you can then refine the selection by eye in the App. Tagging entirely by hand works too, and the walkthrough shows both paths.

ComfyUI 0.43 is out. FLUX 3 Max and Kling 4.0 arrive as paid API nodes; on the local side it adds Fibo 2.0 support, MOSS-image edit LoRAs and lower peak memory for MOSS. Anyone run Fibo 2.0 locally yet, on what card? github.com/comfyanonymous/ComfyUI/releases/tag/v0…

ComfyUI を Intel Arc から Arm の WSL2 へ。同じ requirements でも部品の版は揃わなかった ! 先に、この記事の要約 いまの PC（Intel Arc の内蔵 GPU）で使っていた ComfyUI の画像のワークフローを、Surface Laptop Ultra（Arm の Windows・NVIDIA RTX Spark N1X）の WSL2 へ移した PyTorch は公式の Linux の Arm 向け（2.14.1+cu132）がそのまま入り、GPU で動いた。モデルが読み込み済みの状態で同じ絵を描き直す時間（サンプリングとデコード）は、いまの PC の 50.87 秒に対して 21.60 秒で、約 2.4 倍速かった 移したときに入らなかったのは torchaudio だけだった。torch と同じ 2.14.1 の版を探したが、PyTorch の CUDA 13.2 の一覧にも PyPI にも無く、ComfyUI の requirements から外した。torch と torchvision は版を固定して入れた。読めなくなったのは音声のノードだけだった あとで調べると、torchaudio は 2.11 から torch の版を固定していない。同じ番号の版を探したのは前提の誤りだった。ただ、PyPI の torchaudio 2.11.0 は入っても import で止まった。CUDA 13.0 向けのビルドで、CUDA 13.2 の torch と合わない。そろえる必要があったのは版の番号ではなく、CUDA の版だった PyTorch の test の索引にある CUDA 13.2 向けの torchaudio 2.11.0 なら、音声のノードまで読み込めた。ただし正式版の索引には無いので、画像用の環境には入れず、外したままにしている ComfyUI は v0.38.0 から requirements に torchaudio を含めていない。新しい版の ComfyUI では、この問題は起きなかった 同じ requirements から入れても、numpy や opencv の版はいまの PC と揃わなかった（移したときの numpy は 1.26.4 と 2.5.2） 同じワークフロー・同じ入力・同じ seed で出力を見比べた。線画の前処理は 2 台でほぼ同じだったが、最終の出力は構図と配置が同じで細部が違った。違いは前処理ではなく、生成（サンプリング）の段階で生まれていた WSL2 が使えるメモリーは、既定では Windows 側の半分である。.wslconfig で 24GB に上げた Surface Laptop Ultra の初期設定の記事で、この PC では画像・動画・音声の生成を WSL2 で動かす、と決めた。Arm の Windows 向けには GPU 版の PyTorch が公式に配られていないが、WSL2 の中なら公式の Linux の Arm 向けがそのまま GPU で動いたからである。 その最初として、いまの PC で使っている ComfyUI の画像のワークフローを移した。いまの PC は Intel の内蔵 GPU（Arc 140V）で、PyTorch は Intel の GPU 向け（XPU）の版で動かしている。GPU のメーカーも、CPU の種類も変わる移し替えになる。 ワークフローは、SDXL の img2img に、線画とタイルの ControlNet を足したものである。新しいモデルを試すのではなく、いま動いているものを同じ形で動かすことを目標にした。 移した先の環境 内容 PC Surface Laptop Ultra（Windows 11 の Arm64 版・NVIDIA RTX Spark N1X） WSL2 Ubuntu 24.04（aarch64）、Python 3.12.3 GPU に回すメモリー 95.5GB（NVIDIA App の設定。初期設定の記事のとおり） ComfyUI コミットを固定（下の表）。起動時の表示は 0.18.1 PyTorch 2.14.1+cu132（PyTorch の CUDA 13.2 の一覧から） モデル 4 点、合わせて約 9.5GiB（チェックポイント・ControlNet・線画の抽出用） WSL2 のメモリーを 24GB に上げた WSL2 が使える CPU 側のメモリーは、Microsoft の WSL の設定の説明によると、既定で Windows の合計メモリーの 50% である。この PC は GPU に 95.5GB を回しているので、Windows 側は約 31GB しかなく、WSL2 の中で見えたのは 15GB だった。 画像生成では、モデルを GPU に載せる前に、いったん CPU 側のメモリーに読む。その山を 8〜16GB と見積もって、%USERPROFILE%.wslconfig を新しく作り、24GB にした。 [wsl2] memory=24GB wsl --shutdown のあとで WSL2 を起こし直すと、free -g の合計は 23GB になった。 結果から言うと、1 枚目の生成で WSL2 のメモリーの使用は最大 5.5GiB で、24GB は余った。このワークフローなら、既定の 15GB でも足りた可能性がある。ただ、これより大きいモデルを読むときのために、24GB のままにしている。 ComfyUI は版を固定して、入れる前に requirements を見た いまの PC で動いている版と同じコミットを、そのまま取ってきた。 リポジトリ コミット ComfyUI comfyanonymous/ComfyUI 13917b388028aee922efce6b4714db96e8cfea36（"Nightly Nvidia pytorch is now cu132 (#13288)"） 拡張ノード Fannovel16/comfyui_controlnet_aux 95a13e2e5d8f8ae57583fbebb0be1f670889858b（"Merge pull request #615 …"） 入れる前に、2 つの requirements.txt に、PyPI 以外から取ってくる行が無いかを見た。git+ で始まる行、URL、-e、--index-url などである。 grep -nE 'git+|https?://|^-e|--index-url|--extra-index-url|--find-links' requirements.txt どちらにも無かった。 PyTorch は公式の CUDA 版がそのまま入った PyTorch は、初期設定の記事と同じ、公式の CUDA 13.2 版の Linux の Arm 向けを入れた。 torch 2.14.1+cu132 cuda.is_available() True NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) get_arch_list() ['sm_80', 'sm_90', 'sm_100', 'sm_110', 'sm_120'] この GPU は compute capability 12.1 だが、一覧には sm_121 が無く、12.0 向けまでしか入っていない。それでも、下の生成は GPU で動いた。NVIDIA の Blackwell の互換性の説明によると、ある compute capability 向けに作ったバイナリ（cubin）は、メジャーの番号が同じで、マイナーの番号が同じか大きい GPU で動く。12.0 向けのコードが 12.1 で動いたのは、この説明と合う。 torchaudio は、版の番号ではなく CUDA の版で合わなかった ComfyUI の requirements.txt には、このコミットでは torch・torchvision・torchaudio が並んでいる。移したとき、このうち torchaudio だけが入らなかった。 移したとき：torch と同じ版を探して、外した torch が 2.14.1 なので、torchaudio も同じ 2.14.1 を探した。 PyTorch の CUDA 13.2 の一覧にある torchaudio は、いちばん新しいもので 2.2.0 の aarch64 版だった。新しい版は、aarch64 に限らず置かれていなかった。この一覧から torch・torchvision・torchaudio をまとめて入れようとすると、Cannot install torch and torchaudio==2.2.0 because these package versions have conflicting dependencies と出て、ResolutionImpossible で止まった PyPI の最新は 2.11.0 で、2.14.1 は無かった CUDA 13.0 と 12.8 の一覧も見たが、torchaudio は 2.11.0 までだった そこで、torch と torchvision だけを CUDA 13.2 の一覧から入れ、ComfyUI の requirements からは torchaudio の行を外して入れた。 もう 1 つ、torch と torchvision は、pip の constraints のファイルで版を先に固定した。requirements の torch には版の指定が無いので、依存の解決の途中で、CUDA 13.2 の一覧から入れた torch が PyPI の版に入れ替わるおそれがあると考えたからである。当時は、PyPI の Arm の Linux 向けの torch は CUDA なしの版だと考えていた。あとで PyPI の aarch64 の wheel の METADATA を見ると、CUDA 13.0 に依存する版だった。CPU 版に替わるおそれは無かったが、13.2 の版が 13.0 の版に替わるのは避けたかった。入れ替わるところを見たわけではない。固定したあとも、torch は 2.14.1+cu132 のままだった。PyPI の Arm の Linux 向けが CUDA 13.0 のビルドであることは、このあとの torchaudio でも同じ形で出てくる。 形にすると、次のようになる（実際に打ったコマンドそのままではない）。 pip freeze | grep -E '^(torch|torchvision)==' > constraints.txt grep -v '^torchaudio' requirements.txt > requirements-noaudio.txt pip install -r requirements-noaudio.txt -c constraints.txt 影響は、起動時に音声のノードの 3 つのファイル（nodes_audio.py・nodes_lt_audio.py・nodes_audio_encoder.py）が読めないことだけだった。画像のワークフローには関係が無い。 あとで調べると、同じ番号を探したのが誤りだった torchaudio の公式のインストールの説明には、次のように書かれている。 TorchAudio 2.11 works with PyTorch 2.11 and with every future PyTorch release PyPI の METADATA でも確かめた。torchaudio 2.10.0 は Requires-Dist: torch==2.10.0 で torch の版を固定しているが、2.11.0 には torch の指定が無い。torchaudio は 2.11 から torch の版に縛られていない。torch 2.14.1 と同じ番号の torchaudio を探したこと自体が、前提の誤りだった。 PyPI の 2.11.0 は、入ったが import で止まった そこで、PyPI の torchaudio 2.11.0（aarch64）を実際に入れてみた。画像用の venv を写した別の venv で試し、画像用の venv そのものは変えていない。 constraints を付けたまま入れると、入るのは torchaudio 2.11.0 だけで、torch は入れ替わらなかった。ところが、import で止まった。 RuntimeError: Detected that PyTorch and TorchAudio were compiled with different CUDA versions. PyTorch has CUDA version 13.2 whereas TorchAudio has CUDA version 13.0. Please install the TorchAudio version that matches your PyTorch version. PyPI の aarch64 の torchaudio は CUDA 13.0 向けのビルドで、torchaudio は import のときに torch の CUDA の版と照合して止める（torchaudio/_extension/utils.py の _check_cuda_version()）。torch は CUDA 13.2 の版なので合わない。ComfyUI は起動したが、音声のノードは同じエラーで読み込まれず、ノードの数は torchaudio が無いときと同じ 706（うち音声のノードは 20）だった。 pip が通っても、動くとは限らなかった。そろえる必要があったのは、版の番号ではなく CUDA の版である。 CUDA 13.2 向けの 2.11.0 は、test の索引にあった 正式な CUDA 13.2 の一覧には、この記事を書いた時点で torchaudio 2.11 が無い。PyTorch の test の索引を見ると、torchaudio-2.11.0+cu132-cp312-cp312-manylinux_2_28_aarch64.whl が置かれていた。これを、torch に手を出さないよう --no-deps で入れた。torch と torchvision は変わらなかった。 形にすると、次のようになる（実際に打ったコマンドそのままではない）。 pip install --no-deps --index-url download.pytorch.org "torchaudio==2.11.0+cu132" torch・torchaudio の version と torch.cuda.is_available() を並べると、次のとおりだった。 2.14.1+cu132 2.11.0+cu130 True torchaudio の version は「2.11.0+cu130」と表示されるが、import の CUDA の照合は通った。 MelSpectrogram と resample が GPU で動いた ComfyUI の起動ログから「torchaudio missing」の行が消え、音声のノードの読み込みの失敗も無くなった ノードは 706 から 732 に、音声のノードは 20 から 45 に増えた（LoadAudio・SaveAudio・VAEEncodeAudio・VAEDecodeAudio など） 画像のワークフローの 1 枚も、この状態で最後まで通った それでも、画像用の環境には入れていない test の索引は、正式版を出す前の置き場である。正式な CUDA 13.2 の一覧には（この記事を書いた時点で）2.11 が無いので、画像用の環境には入れず、torchaudio は外したままにしている。上の結果は、写した venv で試したものである。 なお、ComfyUI の側は、その後 requirements から torchaudio を外している（#16457 "Remove torchaudio dependency."）。PR の本文には「no stable cu132 build」とあり、CUDA 13.2 向けの安定版が無いことが理由に挙がっている。v0.37.0 の requirements には torchaudio があり、v0.38.0 には無い。今回はコミットを固定していたので、外れる前の版に当たった。 拡張ノードは、使わない依存を外して入れた 拡張ノード（comfyui_controlnet_aux）の requirements からは、mediapipe を外して入れた。顔・ポーズ・手を取るノードが使うもので、このワークフローでは使わない。 PyPI を見ると、mediapipe の 0.10.33 には Linux の aarch64 向けの wheel が無く、新しい 1.1.1 にはあった。この拡張ノードが 1.x 系で動くかは確かめていない。使うときに確かめる。 入れたあと、pip list で mediapipe・insightface・torchaudio と、Intel の GPU 向けの部品（intel・xpu の名前のもの）が入っていないことを見た。 もう 1 つ、onnxruntime も入らなかった。どちらの requirements にも無いためで、DWPose（ポーズの推定）が CPU の OpenCV に切り替わる、という警告が起動時に出る。これもこのワークフローでは使わない。 部品の版は、いまの PC と揃わなかった 同じコミットの requirements から入れても、入る部品の版はいまの PC と揃わなかった。requirements の多くは版を決めていない（numpy>=1.25.0 のように下限だけのものもある）ので、入れた時点の新しい版が入る。 部品 いまの PC（移したとき） Surface（WSL2） torch Intel の GPU 向け（XPU）の版 2.14.1+cu132 torchaudio あり 無し（上のとおり） numpy 1.26.4 2.5.2 opencv-python 4.10.0.84 5.0.0.93（headless も同じ） pillow 12.1.1 12.3.0 transformers 5.5 5.20.2 onnxruntime 1.24.4 入っていない comfyui_frontend_package 1.42.8 1.42.8 いまの PC の列は、移したときの版である。その後、いまの PC は Python を 3.12 から 3.14 に上げ、numpy は 2.5.4、opencv-python は 4.14 になった。下の出力の見比べは、この新しい版で行っている。 Surface の側をいまの PC に合わせ直すことはしていない。移したときの版で見ると、numpy は 1 系から 2 系へ、opencv-python は 4 系から 5 系へと、大きい版をまたいでいた。出力がどう変わったかは、下の「出力の見比べ」に書いた。 入れたあとの全部の版は、pip freeze でファイルに残した。あとで差が出たときに、どの部品が違ったかをたどれるようにするためである。 モデルは照合してから置いた モデル 4 点（合わせて約 9.5GiB）は、いまの PC から写した。写したあと、SHA256 とバイト数を元の値と照合し、WSL2 の中に置いてから sha256sum -c でもう一度確かめた。4 点とも一致した。 4 点のうち 1 つ（線画の抽出用の netG.pth）は pickle の形式である。controlnet_aux が使う、公開されている AnimeLineArt の重みである。これは読み込む前に、前の記事と同じ方法で、pickle の命令を実行せずに点検した。呼ばれるものは許可リストの範囲だけだった。 起動と、1 枚目の生成 起動のログの一部である。 Total VRAM 112872 MB, total RAM 23982 MB pytorch version: 2.14.1+cu132 Device: cuda:0 NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) : cudaMallocAsync ComfyUI version: 0.18.1 VRAM の 112872MB（約 110.2GiB）は、NVIDIA App で回した 95.5GB より大きい。初期設定の記事で、CUDA が返す合計は「専用」と「共有」を足した値に近い、と書いたのと同じ数字である。RAM の 23982MB は、.wslconfig の 24GB が反映された値である。 読み込めたノードは 706 で、線画の前処理のノード（AnimeLineArtPreprocessor）もあった Windows 側のブラウザから 127.0.0.1:<ポート>/ を開くと、HTTP 200 が返った。WSL2 の localhost の転送で届いていて、設定は何も変えていない ワークフローを API（POST /prompt）で投げて、1 枚作った。移した日の 1 回目である。 項目 値 かかった時間 53.2 秒（モデルの読み込みを含む 1 回目） GPU のメモリーの最大（nvidia-smi） 13,579MiB GPU の温度の最大 79℃ WSL2 のメモリーの使用の最大 5.5GiB GPU で最後まで動いた。いまの PC との速さの比べと出力の見比べは、あとで条件を揃えて測った（次の 2 つの節）。 2 回目以降の時間を、いまの PC と比べた 2 台で同じ手順を踏んだ。 ComfyUI を起動し直した直後に 1 回目を流す。モデルの読み込みを含むので、準備として扱い、比べる値からは外した 2〜5 回目は seed だけを変えて流す。モデル・線画の前処理・VAEEncode はキャッシュに乗ったままで、走るのはサンプリングとデコードと保存だけである 時間は、ComfyUI のログに出る Prompt executed in X seconds の値を使った つまり、ここで比べているのは同じ絵を 2 枚目以降に描き直すときの時間である。前処理まで含めた 1 枚の時間ではない。 1 回目（読み込み込み） 2 回目 3 回目 4 回目 5 回目 2〜5 回目の平均 いまの PC（Intel Arc 140V・XPU） 99.34 秒 51.09 50.89 51.37 50.12 50.87 秒 Surface（RTX Spark N1X・WSL2） 38.44 秒 21.79 21.57 21.46 21.59 21.60 秒 2 回目以降は、Surface がいまの PC の約 2.4 倍速かった（50.87 ÷ 21.60）。 GPU のメモリーの最大は、いまの PC が約 10.6GiB、Surface が 13,873MiB だった。いまの PC は内蔵 GPU で nvidia-smi に当たるものが無いので、ComfyUI の /system_stats の「全体 − 空きの最小」から出した目安である。Surface は nvidia-smi の値で、ユニファイドメモリーのため、ほかのプロセスの分も含んでいる（測る前は 1,928MiB） 温度は、Surface が最大 82℃（1 回目）で、5 回目は 75℃だった。いまの PC は測る手段が無く、測っていない Surface の 1 回目は 38.44 秒で、移した日の 53.2 秒より短かった。移した日は WSL を再起動した直後で、ディスクのキャッシュも空だったと見ている 出力の見比べ 同じワークフロー・同じ入力・同じ seed で、2 台の出力を比べた。ワークフローには、線画の前処理（AnimeLineArt）の出力を保存するノードを 1 つだけ足し、前処理の結果と最終の出力を別々に比べられるようにした。いまの PC は、上に書いた新しい版（Python 3.14・numpy 2.5.4・opencv-python 4.14）で動かしている。 比べた値は、画素ごとの差の平均（0〜255）・PSNR・SSIM である。 比べたもの 平均の差 最大の差 PSNR SSIM 線画の前処理：いまの PC と Surface 0.044 4 61.7dB 0.9999 最終の出力：いまの PC と Surface 27.8 255 15.3dB 0.45 最終の出力：いまの PC と Surface（移した日の出力どうし） 27.7 255 15.3dB 0.45 最終の出力：同じ Surface の別の日どうし 1.36 210 37.3dB — 最終の出力：同じいまの PC の、版を変える前と後 6.66 227 25.5dB — 線画の前処理は、2 台でほぼ同じだった。96% の画素が完全に一致し、残りの差も最大で 4 である。opencv-python の 4.14（いまの PC）と 5.0（Surface）の差は、この前処理の結果にはほとんど表れなかった。 最終の出力は、大きく違った。前処理がほぼ同じなのに、SSIM は 0.45 まで下がる。差は画面の一部ではなく全体に広がっていて、4×4 に分けた各区画の平均の差は 19〜34 だった。移した日の出力どうしで比べても、ほぼ同じ値になった。 だから、2 台の違いは前処理ではなく、生成（サンプリング）の段階で生まれている。このワークフローの sampler は euler_ancestral で、各ステップで乱数を足す方式である。ComfyUI のコードを読むと、最初に足すノイズは seed から CPU の上で作っていて（comfy/sample.py）、ここは 2 台で同じになるはずである。一方、euler_ancestral が各ステップで足すノイズは、潜在のある装置、つまり GPU の上の乱数生成器で作っている（comfy/k_diffusion/sampling.py）。CUDA と Intel の GPU では乱数生成器が別物なので、同じ seed でもステップのノイズは揃わず、途中から別の絵に分かれていくのだと見ている。ただしこれは推測で、2 台の乱数の列を取り出して比べてはいない。 同じ PC の中でも、同じ seed で完全には一致しなかった。Surface の別の日どうしは PSNR 37.3dB で、見た目ではほぼ同じである。いまの PC の版を変える前と後は 25.5dB だった。どちらも、2 台の間の 15.3dB よりはずっと小さい。 見た目では、構図と人物の配置、文字の位置は同じで、細部が違った。色、文字の形のくずれ方、背景の小物の形や数、暗い部分の締まり方である。どちらかの品質が落ちている、という差は感じなかった。 PyTorch の再現性の説明には、PyTorch の版やプラットフォームが違えば、完全に同じ結果になることは保証されない、と書かれている。同じ seed でも、GPU と torch が違えば同じ絵にならなかったのは、この説明の範囲に入る。 移した目的は「いま動いているものを同じ形で動かす」ことだったので、同じ絵になるかではなく、同じ品質の絵が出るかで見ると、移し替えは成り立った。一方で、同じ seed を渡せば同じ絵がもう一度出る、という前提は、PC をまたぐと成り立たなかった。 新しい版の ComfyUI は、別のフォルダーと venv に入れた この PC では、動画の生成も試す。動画のモデルには新しい ComfyUI が要る。たとえば MiniMax H3 の公式の解説は「ComfyUI 0.36.0 or later」を求めている。 画像のワークフローは、上のとおりコミットを固定している。これを上げると、画像の側の結果が変わるおそれがある。そこで、新しい版は別のフォルダーと別の venv に入れた。 画像用 動画用 ComfyUI コミット固定（0.18.1） v0.42.4（3f438ca69f3d0efc5f748de055daeea9ba26ee50） torch 2.14.1+cu132 2.14.1+cu132 torchaudio 外した requirements に無い フロントエンド 1.42.8 1.55.18 動画用の requirements も、PyPI 以外からの取得が無いことを同じように見た。torchaudio はもう requirements に無いので、外す手間も要らなかった。 版を選ぶときに 1 つ気づいたことがある。GitHub の Releases の「最新」は v0.42.1 のままだが、タグはその後も v0.42.2 以降が打たれている（この記事を書いている時点では v0.42.5 まで）。MiniMax H3 の LoRA の修正（#17239）は v0.42.3 に入っている。Releases の最新だけを見ていると、入っている修正を見落とすので、タグの一覧も見て選んだ。 動画の試験の結果は、ここでは扱わない。 測れていないこと numpy の版の影響：opencv-python の 4 系と 5 系では前処理の差はほぼ無かったが、numpy の 1.26 と 2.5 の差は確かめられていない。見比べた時点で、いまの PC はすでに numpy 2.5.4 に上がっていて、1.26.4 のときの前処理の出力が残っていなかったため 2 台で出力が分かれる仕組み：各ステップのノイズが GPU の上の乱数生成器で作られる、というところまではコードで読んだ。2 台の乱数の列そのものは比べていない 前処理まで含めた 1 枚の時間：比べたのは、キャッシュに乗った状態で描き直す時間（サンプリングとデコードと保存）だけである いまの PC の GPU の温度：測る手段が無く、測っていない 音声を実際に扱うワークフロー：test の索引の torchaudio で確かめたのは、音声のノードが読み込まれ、MelSpectrogram と resample が GPU で動くところまでである。音声を生成したり、音声のファイルを読み書きしたりするワークフローは流していない CUDA 13.0 の torch との組み合わせ：PyPI の torchaudio 2.11.0 は CUDA 13.0 向けなので、torch も CUDA 13.0 の版にすれば、PyPI の版のまま import が通るはずである。ただしこれは推測で、試していない mediapipe を使う拡張ノード（顔・ポーズ・手）は、Arm の Linux で動くかを確かめていない まとめ Arm の Windows でも、WSL2 の中なら、公式の CUDA 版の PyTorch で ComfyUI が GPU で動いた。モデルが読み込み済みの状態で描き直す時間は 21.60 秒で、いまの PC（50.87 秒）の約 2.4 倍速かった 入らなかったのは torchaudio だけだった。torch と同じ番号の版を探して見つからず外したが、torchaudio 2.11 は torch の版を固定していなかった。一方で、PyPI の 2.11.0 は CUDA 13.0 向けで、CUDA 13.2 の torch とは import で合わなかった。部品を足すときは、torch と同じ番号を探すのではなく、依存の指定（METADATA）と CUDA の版を見る。正式な一覧に無いものが test の索引にあることもあるが、正式版ではないので、今回は画像用の環境には入れていない。ComfyUI の v0.38.0 以降は、もともと torchaudio を求めていない 同じコミットの requirements でも、部品の版は揃わない。pip freeze を残しておく 移したら、前処理と生成を分けて出力を見比べる。今回は前処理がほぼ同じで、絵が分かれたのは生成の段階だった。同じ seed でも、GPU と torch が違えば同じ絵にはならなかった。構図と配置は同じで、品質の差は感じなかった WSL2 のメモリーは既定で Windows 側の半分である。GPU に多く回している PC では小さくなるので、.wslconfig で決める 固定した版と新しい版は、フォルダーと venv を分けた。新しい版を選ぶときは、Releases の最新だけでなく、タグの一覧も見る ComfyUI は GPL-3.0、comfyui_controlnet_aux は Apache-2.0 で公開されている。 Surface Laptop Ultra の記事 Surface Laptop Ultra の初期設定。ARM の Windows で GPU が使えるかは、道具ごとに入れる前に確かめる Ollama と Llama-Windows を同じ GGUF で比べたら、差はエンジンではなく既定の設定だった この記事

அட. ComfyUI-ல node-களை connect பண்ணி உங்க workflow-வை நீங்களே build பண்ணலாம்.. Flux, Wan local-ல run ஆகும்.. நீங்க முதல்ல எந்த model try பண்ணுவீங்களா ? comfyanonymous/ComfyUI Instagram-லும் பின்தொடருங்கள்: instagram.com

H3 Minimax Background Replace 4k 600 frames Plus github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Workflow github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… The idea in one sentence github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… A large or long video is split into overlapping regions (spatial tiles × temporal windows). At every model call all regions are predicted and blended into one canvas, so there is a single denoising trajectory: no tile seams, no chained clips, and VRAM is one region's. Install github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Easy way (Windows): put bruxosdovfx_EasyInstall_MiniMaxH3.bat in the ComfyUI folder (or the ComfyUI-Easy-Install folder) and double-click it. It finds the folders, installs the custom nodes (SyncTile, Media IO, Latent Upscaler, Easy-Use) and downloads models and LoRAs; anything already present with the same name is skipped, and interrupted downloads resume. Options at the top of the file: text encoder int8/nvfp4, VAE light/full, optional LoRAs, update nodes. Manual: 1. git clone https://github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-v5.4 inside ComfyUI/custom_nodes/ (or copy the bruxosdovfx-SyncTile folder). Delete ComfyUI-SyncTile-H3 if present (old version). 2. Restart. The console prints [bruxosdovfx • SyncTile] v5.5 carregado. 3. Also install the bruxosdovfx Media IO pack — NyckM/Video-Util-ComfYUI (Load Video Pro, Load Image, Save Video Pro — see below). Needs a ComfyUI with the native MiniMax H3 nodes. To write the video file: ffmpeg (on PATH, in FFMPEG_PATH, or pip install imageio-ffmpeg). Background Replace v3 LoRA (summary) github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Experimental merge of five LoRAs by other authors for MiniMax H3 (not an original training). Download: Background Replace v3.safetensors → models/loras/minimax/. BF16, ~1.91 GB, rank-concatenation merge (no SVD); no metadata (credits live in this README). Components and weights: Facial Realism CloseUp — prithivMLmods (1.0); H3 Character Swap — Akatz Labs (1.0); Realism People — Lovis Odin / fal (1.0); Head Swap v1.0 r32 — Alissonerdx / Alisson Anjos (0.2); VFX Edit v1.0 r128 — Alissonerdx / Alisson Anjos (0.2). Links in the table in the Portuguese section. Base model: MiniMax H3 — MiniMaxAI. Load from your LoRA folder at strength 1.0. It mixes FL2VA and REF2VA sources; the name does not guarantee background replacement. The exact Character Swap version is unconfirmed (metadata says v2, deltas resemble v1.5). Structure validated, not yet tested in generation. The source models' licenses apply; credits do not imply the authors endorse the merge. Referências / References / 参考文献 github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Ideas we combined (no code copied unless stated) |Técnica / Technique / 技术|Fonte / Source / 来源|Onde entra / Where it is used / 用于| |:-|:-|:-| |Fusão de caminhos de difusão em regiões sobrepostas · Fusing overlapping diffusion paths · 重叠区域扩散路径融合|Bar-Tal, Yariv, Lipman, Dekel. MultiDiffusion: Fusing Diffusion Paths for Controlled Image Generation. ICML 2023. arXiv:2302.08113|Base matemática da mistura por região · Math behind the per-region blend · 区域融合的数学基础| |SyncTile para MiniMax H3 (tiles 1472×896, refino 4K) · SyncTile for MiniMax H3 · MiniMax H3 的 SyncTile|Tural, A. (2026). alaintural/synctile-h3 (MIT) · pixedi.com · Zenodo DOI 10.5281/zenodo.23196934|Modo "SyncTile original", tamanhos de tile, refino nos passos finais · tile sizes, final-step refine · 图块尺寸、末步精修| |Janelas de contexto no tempo com ruído compartilhado · Temporal context windows with shared noise · 共享噪声的时间上下文窗口|Qiu et al. FreeNoise: Tuning-Free Longer Video Diffusion via Noise Rescheduling. ICLR 2024. arXiv:2310.15169 · DrakenZA/Comfyui-H3-DrakenNodes (joint context windows for H3)|Janelas de 124 frames, ruído único da tela · 124-frame windows, one canvas noise · 124 帧窗口、统一画布噪声| |Divisão espaço + tempo para upscale do H3 · Spatial + temporal chunking for H3 upscaling · H3 放大的时空分块|bbaudio-2025/Comfyui-MMH3-UltimateUpscale|Regiões tile × janela · tile × window regions · 图块 × 窗口区域| |Encadear clipes (comparação) · Clip chaining (comparison) · 片段拼接（对比）|mark9009/ComfyUI-H3-LongTake e outros packs de vídeo longo · and other long-video packs · 及其他长视频节点包|Abordagem que substituímos por uma trajetória só · approach replaced by one trajectory · 被单一轨迹取代的方法| |Latent upscaler 3D · 3D latent upscaler · 3D 潜空间放大器|LBH-123-AI|Entre os estágios 1 e 2 · between stages 1 and 2 · 第一、二阶段之间| |Modelo fused turbo · Fused turbo model · 融合 turbo 模型|MATLOWAI (ref2va delta + lightx2v turbo + Mystic)|Os dois estágios · both stages · 两个阶段| |VAE leve · Light VAE · 轻量 VAE|Kijai/MiniMax-H3-experimental|Encode/decode| |MiniMax H3 + nodes nativos · native nodes · 原生节点|MiniMaxAI · Comfy-Org/MiniMax-H3 · ComfyUI|Tudo · everything · 全部| |Distilação em 4 passos (LoRA opcional) · 4-step distillation (optional LoRA) · 4 步蒸馏（可选 LoRA）|Wang, Yuan, Wang et al. PDMD: Projected Distribution Matching Distillation (UC San Diego / ByteDance), 2026. arXiv:2609.35768 · pdmd2026 · conversão ComfyUI Kijai|Pilha de LoRA 1 · LoRA stack 1 · LoRA 组 1| |Nitidez guiada pelo vídeo fonte · Source-guided sharpening · 源视频引导锐化|Alissonerdx / Minimax-H3-ComfyUI (LMS v1.0 r64)|Pilha de LoRA 2 · LoRA stack 2 · LoRA 组 2| |LoRAs da mescla Background Replace v3 · LoRAs in the merge · 合并所用 LoRA|prithivMLmods, Akatz Labs, Lovis Odin / fal, Alissonerdx / Alisson Anjos (ver acima · see above · 见上文)|LoRA opcional · optional LoRA · 可选 LoRA|

Minimax h3 Replace Background Workflow 4k 600frames+ github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Workflow github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… The idea in one sentence github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… A large or long video is split into overlapping regions (spatial tiles × temporal windows). At every model call all regions are predicted and blended into one canvas, so there is a single denoising trajectory: no tile seams, no chained clips, and VRAM is one region's. Install github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Easy way (Windows): put bruxosdovfx_EasyInstall_MiniMaxH3.bat in the ComfyUI folder (or the ComfyUI-Easy-Install folder) and double-click it. It finds the folders, installs the custom nodes (SyncTile, Media IO, Latent Upscaler, Easy-Use) and downloads models and LoRAs; anything already present with the same name is skipped, and interrupted downloads resume. Options at the top of the file: text encoder int8/nvfp4, VAE light/full, optional LoRAs, update nodes. Manual: 1. git clone https://github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-v5.4 inside ComfyUI/custom_nodes/ (or copy the bruxosdovfx-SyncTile folder). Delete ComfyUI-SyncTile-H3 if present (old version). 2. Restart. The console prints [bruxosdovfx • SyncTile] v5.5 carregado. 3. Also install the bruxosdovfx Media IO pack — NyckM/Video-Util-ComfYUI (Load Video Pro, Load Image, Save Video Pro — see below). Needs a ComfyUI with the native MiniMax H3 nodes. To write the video file: ffmpeg (on PATH, in FFMPEG_PATH, or pip install imageio-ffmpeg). Background Replace v3 LoRA (summary) github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Experimental merge of five LoRAs by other authors for MiniMax H3 (not an original training). Download: Background Replace v3.safetensors → models/loras/minimax/. BF16, ~1.91 GB, rank-concatenation merge (no SVD); no metadata (credits live in this README). Components and weights: Facial Realism CloseUp — prithivMLmods (1.0); H3 Character Swap — Akatz Labs (1.0); Realism People — Lovis Odin / fal (1.0); Head Swap v1.0 r32 — Alissonerdx / Alisson Anjos (0.2); VFX Edit v1.0 r128 — Alissonerdx / Alisson Anjos (0.2). Links in the table in the Portuguese section. Base model: MiniMax H3 — MiniMaxAI. Load from your LoRA folder at strength 1.0. It mixes FL2VA and REF2VA sources; the name does not guarantee background replacement. The exact Character Swap version is unconfirmed (metadata says v2, deltas resemble v1.5). Structure validated, not yet tested in generation. The source models' licenses apply; credits do not imply the authors endorse the merge. Referências / References / 参考文献 github.com/NyckM/Bruxosdovfx-SyncTile-MiniMax-H3-… Ideas we combined (no code copied unless stated) |Técnica / Technique / 技术|Fonte / Source / 来源|Onde entra / Where it is used / 用于| |:-|:-|:-| |Fusão de caminhos de difusão em regiões sobrepostas · Fusing overlapping diffusion paths · 重叠区域扩散路径融合|Bar-Tal, Yariv, Lipman, Dekel. MultiDiffusion: Fusing Diffusion Paths for Controlled Image Generation. ICML 2023. arXiv:2302.08113|Base matemática da mistura por região · Math behind the per-region blend · 区域融合的数学基础| |SyncTile para MiniMax H3 (tiles 1472×896, refino 4K) · SyncTile for MiniMax H3 · MiniMax H3 的 SyncTile|Tural, A. (2026). alaintural/synctile-h3 (MIT) · pixedi.com · Zenodo DOI 10.5281/zenodo.23196934|Modo "SyncTile original", tamanhos de tile, refino nos passos finais · tile sizes, final-step refine · 图块尺寸、末步精修| |Janelas de contexto no tempo com ruído compartilhado · Temporal context windows with shared noise · 共享噪声的时间上下文窗口|Qiu et al. FreeNoise: Tuning-Free Longer Video Diffusion via Noise Rescheduling. ICLR 2024. arXiv:2310.15169 · DrakenZA/Comfyui-H3-DrakenNodes (joint context windows for H3)|Janelas de 124 frames, ruído único da tela · 124-frame windows, one canvas noise · 124 帧窗口、统一画布噪声| |Divisão espaço + tempo para upscale do H3 · Spatial + temporal chunking for H3 upscaling · H3 放大的时空分块|bbaudio-2025/Comfyui-MMH3-UltimateUpscale|Regiões tile × janela · tile × window regions · 图块 × 窗口区域| |Encadear clipes (comparação) · Clip chaining (comparison) · 片段拼接（对比）|mark9009/ComfyUI-H3-LongTake e outros packs de vídeo longo · and other long-video packs · 及其他长视频节点包|Abordagem que substituímos por uma trajetória só · approach replaced by one trajectory · 被单一轨迹取代的方法| |Latent upscaler 3D · 3D latent upscaler · 3D 潜空间放大器|LBH-123-AI|Entre os estágios 1 e 2 · between stages 1 and 2 · 第一、二阶段之间| |Modelo fused turbo · Fused turbo model · 融合 turbo 模型|MATLOWAI (ref2va delta + lightx2v turbo + Mystic)|Os dois estágios · both stages · 两个阶段| |VAE leve · Light VAE · 轻量 VAE|Kijai/MiniMax-H3-experimental|Encode/decode| |MiniMax H3 + nodes nativos · native nodes · 原生节点|MiniMaxAI · Comfy-Org/MiniMax-H3 · ComfyUI|Tudo · everything · 全部| |Distilação em 4 passos (LoRA opcional) · 4-step distillation (optional LoRA) · 4 步蒸馏（可选 LoRA）|Wang, Yuan, Wang et al. PDMD: Projected Distribution Matching Distillation (UC San Diego / ByteDance), 2026. arXiv:2609.35768 · pdmd2026 · conversão ComfyUI Kijai|Pilha de LoRA 1 · LoRA stack 1 · LoRA 组 1| |Nitidez guiada pelo vídeo fonte · Source-guided sharpening · 源视频引导锐化|Alissonerdx / Minimax-H3-ComfyUI (LMS v1.0 r64)|Pilha de LoRA 2 · LoRA stack 2 · LoRA 组 2| |LoRAs da mescla Background Replace v3 · LoRAs in the merge · 合并所用 LoRA|prithivMLmods, Akatz Labs, Lovis Odin / fal, Alissonerdx / Alisson Anjos (ver acima · see above · 见上文)|LoRA opcional · optional LoRA · 可选 LoRA|

Make AI Images for FREE: 2 Ways Nobody Explains #shorts Two ways to make AI images for free: online tools with daily free plans, or open-source tools on your own PC. Sources: - comfyanonymous/ComfyUI - wavespeed.ai - aitoolsbridge.com Free plans and features change often: check each tool's official site before you rely on them. Animation: Stick AI Lab. Narration: synthetic voice (Kokoro TTS). #shorts #ai #aitools #stickailab sal-meta: ep=sal-ai-images-overview; topic=ai-images; tool=series; angle=overview

KIẾN TẠO PIPELINE SINH ẢNH VÀ VIDEO AI CHUYÊN NGHIỆP: COMFYUI LÀ CHUẨN MỰC NODE-BASED GRAPH CHO GENERATIVE AI Giao diện WebUI truyền thống (như Automatic1111) rất tiện lợi cho người mới bắt đầu nhưng bộc lộ nhiều hạn chế khi bạn muốn xây dựng các quy trình sinh hình ảnh và video phức tạp: kết hợp nhiều mô hình LoRA, áp dụng ControlNet đa tầng, hay tích hợp mô hình upscale tùy biến theo từng bước. ComfyUI là giao diện đồ họa dạng đồ thị (Node-Based Flowchart GUI) mã nguồn mở mạnh mẽ và module hóa nhất hiện nay dành cho các mô hình Stable Diffusion, SDXL, Flux và Video Generation. Tech Stack: Được xây dựng bằng Python và PyTorch ở backend, giao diện frontend trực quan bằng JavaScript thuần trên nền Canvas đồ thị. Cơ chế tính toán dựa trên đồ thị tính toán có hướng (Execution Graph). Tại sao nên dùng? - Kiểm soát chính xác từng bước của pipeline: Cho phép bạn can thiệp vào bất kỳ mắt xích nào của quá trình khuếch tán (Denoising step, VAE decode, Clip skip, Latent upscale) mà không bị giới hạn bởi các thiết lập cố định. - Tái sử dụng và chia sẻ Workflow dễ dàng: Toàn bộ cấu trúc quy trình phức tạp được nhúng trực tiếp vào siêu dữ liệu (metadata) của file ảnh PNG xuất ra. Chỉ cần kéo thả bức ảnh vào ComfyUI là toàn bộ dàn node được khôi phục nguyên vẹn. - Hiệu năng tối ưu hóa VRAM vượt trội: Chỉ nạp vào bộ nhớ GPU những mô hình và dữ liệu đang thực sự tính toán ở bước hiện tại, cho phép chạy các mô hình khủng như Flux trên các dòng card đồ họa phổ thông. Dự án sở hữu hơn 60.000 stars trên GitHub và đang là công cụ tiêu chuẩn trong các studio đồ họa chuyên nghiệp và các dây chuyền sản xuất media bằng AI. Link tham khảo: comfyanonymous/ComfyUI #OpenSourceVN #VNOSS #opensourcevn #vnoss #DevCommunity #ComfyUI #GenerativeAI #StableDiffusion #Flux #Python #AIWorkflow

AI 出图最烦的就是每次都像抽卡。。。 ComfyUI 是把出图拆成一个个节点连起来：模型、采样、放大、抠图，每一步都摆在眼前。连好的流程能存下来，下次换张图直接跑，风格和尺寸不会乱飘。 我还没在自己电脑上装，显卡有点虚（ GitHub 13.6 万星，GPL-3.0 comfyanonymous/ComfyUI