UpscaleModelLoader/ImageUpscaleWithModel native; frame interpolation and the restore/colorize nodes are well-maintained customs
rembg (17.2 GB)
rembg + BiRefNet
BiRefNet / rembg nodes
segment-langsam (10.4 GB)
GroundingDINO + SAM 2.1 prompted segmentation
GroundingDINO + SAM 2 nodes
Why it is worth anything
Not disk. Load count. Today generate → upscale → restore faces is three separate entries in an exclusive group: three docker stop/docker run cycles and three model loads for one logical operation, each costing the 45s–3m cold-swap seen in the logs. Inside one ComfyUI it is one graph, one load, and the intermediate images never leave the process.
That composition is exactly what mort's media agents do constantly.
Why it is last
It is the phase with the most dependency-hell risk. GroundingDINO and SAM 2 in particular have pinned CUDA-extension builds that fight with everything else in a shared venv.
The payoff only exists after phase 1, because before that the image ComfyUI is not the resident process anyway.
Each of these has a working, isolated container today. The current arrangement is not broken; it is just slower than it could be.
Scope discipline
Do not fold in faceswap, audioutils, or videoutils — they live in the cpu-ondemand persistent group specifically so a GPU load cannot evict them mid-job. Moving them into a GPU-group ComfyUI would delete that property.
Mort-side impact — this one is NOT free
Unlike phase 1, these are not /sdapi calls behind a model id. majordomo reaches them through /upstream/<model>/<path> with per-shim native APIs:
POST /upstream/mediautils/v1/upscale, /v1/interpolate, /v1/colorize, /v1/restore_faces
POST /upstream/rembg/api/remove
POST /upstream/segment-langsam/...
A merged ComfyUI would have to serve all of those paths to keep mort unchanged, or mort's provider changes. Serving the existing paths from the new shim is the cheaper answer and keeps the blast radius at zero — decide before writing code, not after.
Acceptance
Every existing /upstream/... path still answers with the same request and response shapes
enhance_video, upscale_image, remove_background, interpolate_video, restore_photo, and segment_image all still work from mort with no code change
A generate → upscale → restore chain measurably beats three separate swaps
Part of #3. Blocked by #5. Optional — do it only if phases 0–1 land cleanly.
## The observation
Three GPU entries in the `all` group are already graph-shaped work that ComfyUI does natively:
| entry | today | ComfyUI equivalent |
|---|---|---|
| `mediautils` (11.1 GB) | Real-ESRGAN upscale, RIFE interpolate, DDColor colorize, GFPGAN face restore, RVM matte | `UpscaleModelLoader`/`ImageUpscaleWithModel` native; frame interpolation and the restore/colorize nodes are well-maintained customs |
| `rembg` (17.2 GB) | rembg + BiRefNet | BiRefNet / rembg nodes |
| `segment-langsam` (10.4 GB) | GroundingDINO + SAM 2.1 prompted segmentation | GroundingDINO + SAM 2 nodes |
## Why it is worth anything
Not disk. **Load count.** Today `generate → upscale → restore faces` is three separate entries in an exclusive group: three `docker stop`/`docker run` cycles and three model loads for one logical operation, each costing the 45s–3m cold-swap seen in the logs. Inside one ComfyUI it is one graph, one load, and the intermediate images never leave the process.
That composition is exactly what mort's media agents do constantly.
## Why it is last
- It is the phase with the most dependency-hell risk. GroundingDINO and SAM 2 in particular have pinned CUDA-extension builds that fight with everything else in a shared venv.
- The payoff only exists **after** phase 1, because before that the image ComfyUI is not the resident process anyway.
- Each of these has a working, isolated container today. The current arrangement is not broken; it is just slower than it could be.
## Scope discipline
Do not fold in `faceswap`, `audioutils`, or `videoutils` — they live in the `cpu-ondemand` persistent group specifically so a GPU load cannot evict them mid-job. Moving them into a GPU-group ComfyUI would delete that property.
## Mort-side impact — this one is NOT free
Unlike phase 1, these are not `/sdapi` calls behind a model id. majordomo reaches them through `/upstream/<model>/<path>` with per-shim native APIs:
- `POST /upstream/mediautils/v1/upscale`, `/v1/interpolate`, `/v1/colorize`, `/v1/restore_faces`
- `POST /upstream/rembg/api/remove`
- `POST /upstream/segment-langsam/...`
A merged ComfyUI would have to serve **all of those paths** to keep mort unchanged, or mort's provider changes. Serving the existing paths from the new shim is the cheaper answer and keeps the blast radius at zero — decide before writing code, not after.
## Acceptance
- Every existing `/upstream/...` path still answers with the same request and response shapes
- `enhance_video`, `upscale_image`, `remove_background`, `interpolate_video`, `restore_photo`, and `segment_image` all still work from mort with no code change
- A generate → upscale → restore chain measurably beats three separate swaps
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #3. Blocked by #5. Optional — do it only if phases 0–1 land cleanly.
The observation
Three GPU entries in the
allgroup are already graph-shaped work that ComfyUI does natively:mediautils(11.1 GB)UpscaleModelLoader/ImageUpscaleWithModelnative; frame interpolation and the restore/colorize nodes are well-maintained customsrembg(17.2 GB)segment-langsam(10.4 GB)Why it is worth anything
Not disk. Load count. Today
generate → upscale → restore facesis three separate entries in an exclusive group: threedocker stop/docker runcycles and three model loads for one logical operation, each costing the 45s–3m cold-swap seen in the logs. Inside one ComfyUI it is one graph, one load, and the intermediate images never leave the process.That composition is exactly what mort's media agents do constantly.
Why it is last
Scope discipline
Do not fold in
faceswap,audioutils, orvideoutils— they live in thecpu-ondemandpersistent group specifically so a GPU load cannot evict them mid-job. Moving them into a GPU-group ComfyUI would delete that property.Mort-side impact — this one is NOT free
Unlike phase 1, these are not
/sdapicalls behind a model id. majordomo reaches them through/upstream/<model>/<path>with per-shim native APIs:POST /upstream/mediautils/v1/upscale,/v1/interpolate,/v1/colorize,/v1/restore_facesPOST /upstream/rembg/api/removePOST /upstream/segment-langsam/...A merged ComfyUI would have to serve all of those paths to keep mort unchanged, or mort's provider changes. Serving the existing paths from the new shim is the cheaper answer and keeps the blast radius at zero — decide before writing code, not after.
Acceptance
/upstream/...path still answers with the same request and response shapesenhance_video,upscale_image,remove_background,interpolate_video,restore_photo, andsegment_imageall still work from mort with no code change