Adapter node: IMAGE (batch) + BOUNDING_BOX (+ MASK, + LAYERS) -> LAYERS.
One document item per frame, each placed by its own box.
Why this is needed. A node that separates an image into elements emits
them as an image batch plus a list of boxes. That batch cannot be fed to
Create Layered Image with the placement intact, because
`expand_item_frames` applies the item's single x/y/w/h/name/z_index to
every frame of a batch. Sixteen layers get one placement between them.
The current workaround is to have the producer pre-place each layer on a
full-size canvas so x=0,y=0 is correct for all of them. That works but is
expensive: at 2K with 16 layers it carries ~768MB of layer tensors and
~268MB of masks to encode what cropped layers hold in a fraction of it.
This node emits one item per layer instead, so each carries its own
placement. It needs no change to the existing compositor path:
`document_items` already sorts by z_index, and `expand_item_frames`
already handles single-frame items correctly - the shared-placement
limitation only bites on batches.
Reads `metadata.name`, `metadata.z_index` and `metadata.content_rect`
where present. `crop_to_content` trims each frame out of a padded batch
and places it by its box, which is what recovers the memory win.
Also restores a `_bbox_list` parser. The equivalent (`_bbox_entries`,
`layout_bboxes`, `state_from_bboxes`) was removed in 1c4953ff along with
the rest of the bbox handling when the node moved to the LAYERS document,
so there is currently no path from a bounding box into the compositor.
Verified: two padded layers with different content sizes, cropped and
placed independently, composite to within 0.50/255 of expectation - the
8-bit quantisation floor of the PIL round trip inside the compositor.
The 76 existing compositor tests still pass.
Blending exists in two implementations - the numpy compositor and the
layerBlend.frag shader that drives the live preview - with nothing holding
them together. They have already diverged once (the safeDiv operand), and a
divergence only shows up to the user as 'the render does not match the
preview'.
Adds compositor_blend_golden.json: every mode, at both endpoints, the
midpoint and inside each epsilon guard. Any implementation of these 26 modes
must reproduce it. compositor_blend_test.py pins the numpy side to it and
additionally spells out the boundary rules by hand, so the guards cannot be
re-broken by regenerating the fixture.
Diffing the shader against the numpy implementation over that grid leaves
exactly one mismatch: luminosity. safe_div guards the denominator and
returns 0, so a luminosity layer over a black or near-black backdrop
disappears. The backdrop has no hue or saturation to preserve there, so the
result should be a neutral grey at the layer's luminance - which is also the
analytic limit of i * lum(l)/lum(i) as the backdrop approaches black. The
matching four-line shader change is proposed on the frontend PR; with both
applied all 26 modes agree.
Also clamps layer opacity to [0, 1]. The layer state round-trips through the
saved workflow and is accepted verbatim on /prompt, so it is untrusted
input; the canvas is only clamped once, after the last layer, so an
out-of-range coverage multiplier changes the blend of every layer above it.
_parse_background already clamps the same field.
This avoids name collision (circular imports) for external custom nodes,
for which the comfy path is pushed into sys.path so Python's own logging module
is shadowed otherwise.
fixes: #15229
This priority scheme was broken in the case where you have pin
registration exhaustion while loading a VBAR that gets a big evicition.
The weight would stay in the loaded set but inherit the MRU priority
against other workflow models WRT pin registration which leads to async
offload without pinning.
Fix by universally promiting active pin registration above workflow
pins without concern for the weights/weights-loaded split. This diverges
from the actual budgeting where the split still makes sense.
Changes:
Remove sequential scan hint
Prefer NVML pressure on windows
Add async malloc clamp option (unused by comfy so far)
Workaround AMD windows GPU virtual address space leak
The largest change is the NVML pressure, which works around a cuMemGetInfo
drift from actual VRAM in some circumstances.
Windows has proven this logic works for a long time and there are
corner cases where this materialization actual consumes real RAM
on linux.
Its not as bad as the original windows commit charge surge, but
its still a detectable transient leak. So simplify and unify.
* Fix SVG previews broken by the stored-XSS forced-download
/view and the assets download route force every SVG to
application/octet-stream + attachment. That blocks the stored XSS from
GHSA-779p-m5rp-r4h4, but it also breaks the SVG node output and Media
Assets previews, which request the file with a plain <img>.
Exempt only that case. An SVG referenced by an <img> loads in secure
static mode with scripting and external references disabled, so the
payload cannot fire. The attack needs the SVG to become a document,
which arrives with a different Sec-Fetch-Dest. Browsers set that header
themselves and page script cannot override it. A missing header, from a
non-browser client or a proxy that strips it, fails closed.
The blocklist itself is unchanged; this is a call-site gate.
* Don't let a cache replay the inline SVG into document context
The Sec-Fetch-Dest exemption makes /view and the assets content route vary
their Content-Type and Content-Disposition on a request header, but neither
response said so. FileResponse emits Last-Modified/ETag and the cache_control
middleware skips /view (the filename is in the query string, not the path), so
the inline image/svg+xml variant is heuristically cacheable. A cache keyed on
the URL alone could hand an entry primed by an <img> load to a later top-level
navigation of the same URL, turning the SVG back into a document and
re-enabling the stored XSS the forced download blocks.
Set Vary: Sec-Fetch-Dest and Cache-Control: no-store on both branches, not just
the exempt one: a cached attachment replayed to an <img> would re-break the
preview this fix exists to restore.
Also strip parameters from content_type before building the assets response.
mime_type there is uploader-supplied and unvalidated, and aiohttp rejects a
charset in the content_type argument with ValueError, so a stored
"image/svg+xml; charset=utf-8" turned a valid inline SVG into a 500.
Route-level guards now pin the headers on both branches and the parameterised
mime type; all three fail against the previous commit.
