MIDI-3D Preprocess (Files)
The file-path version of MIDI-3D preprocess (skip ComfyUI's loaders)
- preprocessed
MIDI-3D Preprocess (Files) is the same job as MIDI-3D Preprocess - chop an RGB scene and a per-object mask into the per-instance inputs the diffusion needs - except it reads its inputs straight from disk instead of from ComfyUI's IMAGE/MASK tensors. Same end result, different front door.
You feed it two paths:
- rgb_path - absolute path to the scene image (PNG, JPG, whatever PIL can open).
- seg_path - absolute path to the segmentation mask. Same rule as the tensor version: each object must be a different value in the mask, not a single binary blob.
- do_padding - same option as the tensor version, default false. Turn it on only when objects touch the image edges.
Output is a MIDI3D_DATA bundle identical to what the main preprocess node produces, so both versions feed MIDI-3D Process and MIDI-3D Texture interchangeably. If you have a workflow saved with one, swapping in the other just changes how the data gets in.
When to actually reach for this
The honest answer: rarely, unless you're scripting. The tensored version is usually the right call because it plugs into ComfyUI's normal Load Image flow, which handles the input folder and image metadata for you. This variant exists for the cases where your assets aren't in ComfyUI's world at all - a batch script dumping renders, images you're testing from a research dataset, or a workflow where the segmentation was produced by an external tool and you don't want to round-trip it through the UI.
The path gotcha
Both paths are raw strings, and PIL opens them as given. Relative paths resolve against ComfyUI's working directory, which is not necessarily your input/ folder - so input/00_seg.png may or may not resolve depending on how you launched ComfyUI. Use absolute paths. If you get a "file not found" style error, the first thing to check is whether the path you typed is the path on disk. Yes, really - it's the top cause of issues with this node, because the string input gives you no picker to be wrong in comfort.
You'll also want the image and mask to be the same resolution. The node does not resize or align them for you - it converts both to PIL and splits by label, and mismatched dimensions mean misaligned instances. Crop them to match before you point the node at them.
Troubleshooting
- "No instances found in segmentation mask" - the mask is all zeros, same as the tensor version. Either the file is wrong or it doesn't contain distinct per-object values. Convert a color-coded mask with
RGB to Instance Maskfirst and save that. - Weird object crops - image and mask misaligned. Check resolution and orientation.
- It's slower than you'd like on first run - that's not this node. The model download and diffusion happen downstream in
MIDI-3D Process; this node is pure image processing and is near-instant.
Think of it as the batch/automation escape hatch for the pack. If you're hand-building workflows in the UI, the regular MIDI-3D Preprocess is almost always the one you want. Keep this one in your back pocket for when you're driving ComfyUI from code.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| rgb_path | STRING | Path to RGB image file | |
| seg_path | STRING | Path to segmentation mask file | |
| do_paddingopt | BOOLEAN | false | Pad image for border objects |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| preprocessed | MIDI3D_DATA | Preprocessed instance data for MIDI-3D |