DOGMA v38 Inventory Resize
DOGMA v38 Inventory Resize
- image
- image
- info
Vision language models are slow in proportion to the number of image tokens you hand them, and an 8K archival scan is a lot of tokens for a job that only needs the gist. This node makes the "gist" version - a small proxy of your frame, aligned to a multiple of 16, capped at 1536px on the long side.
It's the cheapest kind of speedup in the whole pack: make the inventory pass look at 1024px instead of 8000.
What it is
A utility in the v38 line, which is the version where the author switched the planner from "ask the model for categories" to "ask the model to inventory the scene, then build the plan from a structured report." Those inventory nodes parse a text list of GROUP | category | sam_prompt | kind rows; this node is what you feed the image through on the way in.
It does exactly one thing and reports it.
How it works
If the image's long side is already under max_side, it's returned untouched - no resampling, no re-encode, no cost. Otherwise it scales down, rounds both dimensions to the nearest multiple of 16 (minimum 16), and resamples bilinearly with antialiasing, which matters because antialiased downscaling of a grainy scan is much less likely to alias fine texture into false pattern.
The /16 rounding is there for the same reason it appears in the crop nodes: keeps the proxy compatible with the VAE and patch dims used downstream. And it only touches the first three channels, so an alpha-carrying input doesn't get mangled.
Inputs and outputs
Two inputs. image (IMAGE). max_side (INT, default 1024, range 512–1536, step 64) - the long-side cap. Note the ceiling: this node will not upscale you to 2048, it only ever makes things smaller, and the useful range is narrow on purpose.
Two outputs. image (IMAGE) - the resized view. info (STRING) - either inventory view 1920x1280 if nothing happened, or inventory view 8000x6000->1024x768 if it did. That arrow form is genuinely helpful, because it tells you at a glance whether the pipeline is looking at a proxy or the real thing.
Wire image into your VLM/planner branch, and keep the original image on the main wire. That's the whole pattern: the language model reads a thumbnail and produces a plan, and the pixel work happens at full resolution. Getting those two wires crossed - sending the proxy into the crop nodes - produces a plan whose category coordinates don't match the frame you're editing, which fails in a confusingly partial way.
Install
ComfyUI Manager → search DOGMA Nodes (publisher axior), install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
# restart ComfyUI
No dependencies, no weights - the pack's requirements.txt is a single "no external dependencies" line and the repo ships nothing to download. The VLM this proxies for is a separate install, and dropping the token count is exactly the point of using it.
Common issues
The failure to know about is that a 1024px proxy can lose small objects entirely - a distant pedestrian, a traffic sign, a damaged window two buildings back. The planner then never lists them, and the detail pass never touches them, all while looking like it did its job. If your source is dense with small features and you want the inventory to catch them, push max_side toward 1536 and accept the extra VLM time.
The opposite mistake is expecting this to help quality. It's a compute proxy and nothing else; there is no detail pass happening here and nothing downstream benefits from it except the planner's runtime. If you're not running a VLM at all - you're on a fixed plan like DOGMAFixedSemanticPlanV23 - this node has no purpose in your graph.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| max_side | INT | 1024512–1536 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| info | STRING | — |