ComfyUI-enricos-nodes is a visual layer compositor for ComfyUI graphs

What the Compositor node is for

ComfyUI-enricos-nodes is a set of ComfyUI custom nodes, and the repository description calls it compositor node experiments. The centrepiece is the Compositor node, and the README frames it plainly: this node was created to make the composition process quick and easy.

The problem it addresses is a practical one in ComfyUI. When a workflow produces several images that you then need to place together, the usual route is to build the composition with transform nodes, one per image, with numeric inputs for position, angle and scale, and to connect them in a fixed order. That works, it is reproducible, and it is also manual work that has to be redone every time you change the layout.

The Compositor node takes up to 8 images and lets you visually place, rotate, scale and flip them. The list of features is long enough to be worth reading in full, because it shows how much of the work is interaction design rather than image processing.

There is layer management with drag-to-reorder, visibility toggles and previews of images and masks side by side. There is a background colour option that can also be left transparent. There is drawing, sketching and annotating on a foreground layer with an adjustable brush for size, colour and shape, and erasing while drawing by holding ctrl. There are transforms including flip H and V, stretch to fit, aligning selected objects and rotating with precision. There is a precise pixel-level selection mode with snap-to-grid for alignment, and numerical width and height boxes for exact dimensions.

The persistence is the part that makes it more than a scratchpad. Positions, scaling, rotations and z-index are remembered across generations and reloads, and there is a save-on-resources option so inputs persist. There is a Reset All button to restore the initial configuration if you lose an image off screen, a park area for extra padding where you can park assets, a green border marking the exact exported region, and keyboard nudging with arrow keys at 1px and Shift for 10px.

The v4 rewrite, and the known issues it ships with

The v4 line is described in the README as a major rewrite with a complete UI overhaul and enhanced workflow, dated 16.11.2025, and it is marked as an alpha preview while v3 is still there. The attention notice is blunt: this is an alpha preview, v3 still there.

The new features are worth listing because they define what the node can now do. There is a Layers Panel giving visual layer management with thumbnails for images and masks, drag-to-reorder and visibility toggles. There are drawing tools on a foreground layer with brush and eraser modes, a colour picker and an adjustable brush size and shape, circle or square. The toolbar gained flip H and V, stretch and align, snap-to-grid and a precise selection mode. There are numerical inputs for direct width and height control with real-time feedback and a rotation slider with snap, Shift for 5 degree increments. There is save and reset, with auto-save on mouse-out and an orange flash for visual feedback, plus a Reset All button. Mask previews show side by side image and mask thumbnails with opacity indicators, and the composition border is now pixel-perfect with the export area.

Then comes the part that makes this an alpha rather than a release, and the README does not hide it. The known issues list says the erase canvas might restore an erased foreground in certain cases, that positions are not always pixel-perfect because of sub-pixel rounding, that some transformation tools can be unreliable with equalize and distribute disabled, that mask output and advanced outputs have been temporarily removed, and that the node can be very heavy depending on the size of the canvas and the imported images, with the advice to keep it reasonable in size and to avoid importing eight 4K images into a 4K canvas.

That last point is a performance warning stated plainly, and it is the one to take most seriously. A node that holds a compositing canvas and multiple images in a browser frontend consumes memory proportional to the pixel count, and the failure mode is a slow or unresponsive ComfyUI instance rather than a wrong result.

The v3 line, and the features that v4 does not have

Reading the previous changelog is instructive, because it shows what the v4 rewrite dropped and what it inherited.

Version 3.1.5 added mask outputs, a new node that outputs the layers and their masks, connected to a new layer_outputs output socket, with a note that mask stacking, subtracting the top masks from the ones below, would come later. It also added a color picker node where you can specify RGB coordinates or use an eyedropper and connect the 24 bit output to colour inputs, and fixed a regression where the composition overlay was not superimposed while moving objects and z-stacking was not preserved until save.

Version 3.1.1 fixed the GUI not showing up in a Comfy frontend, with the entry naming Comfy 1.1.18 and later. Version 3.1.3 and 3.1.4 were a fix for a regression caused by a Comfy change, with the note that reinstancing the node might be needed and that reloading a flow may no longer preserve the configurations.

Version 3.1.0 is where the configuration model came from, and two of its features matter for anyone deciding between versions. The first is the onConfigChange action toggle, which lets you choose whether a configuration change should stop the flow to allow edits, or grab a capture and continue the flow. The warning attached to the second option matters: it stops, uploads the composition and re-enqueues your prompt, and there is no real pause, so you have to be careful with random seeds on the left of the node or it will loop.

The same release added a normalize height option that makes all images the same height as the canvas, at the cost of image quality, made output transforms return the angle and bounding box coordinates, allowed forcing transform output values to be integers because some nodes require it, and introduced an experimental and limited Tools feature for controlling some aspects of the compositor, including a precise selection toggle, centering selected images and resetting transforms. That last one has a stated limitation: saving discards the selection and it happens on mouse out, so you may need to re-select.

The node files, the web frontend and the registry entry

The repository layout shows how the versioned node set is organised, and it explains why both v3 and v4 exist side by side.

The Python node files are Compositor3.py, Compositor4.py, Compositor4MasksOutput.py, Compositor4TransformsOut.py, CompositorColorPicker.py, CompositorConfig3.py, CompositorConfig4.py, CompositorMasksOutputV3.py, CompositorTools3.py, CompositorTransformsOut3.py and ImageColorSampler.py, plus an __init__.py that registers them. The naming makes the versioning explicit. A file with a 3 suffix belongs to the older line and one with a 4 suffix to the new one, so the older Compositor3.py and its config and tools companions are still registered and still runnable alongside the v4 set.

The web directory holds the frontend, which is where the drawing surface, the layers panel and the toolbar live. The assets directory holds the showreel images, the v3 and v4 interface screenshots, and a workflows folder that the v3 changelog references, pointing at a sample workflow with assets for the mask outputs in /assets/workflows.

The package metadata in pyproject.toml is minimal and describes the node in the terms the README uses: pass up to 8 images and visually place, rotate and scale them to build the composition, group move and group rescale, remember their position and scaling value across generations, and use the buffer zone to park an asset you do not want to use or to reach the transformation controls. The version there reads 4.0.3, while the newest tag listed is v4.0.1, so the working tree is ahead of the last tag again.

The project is also published through the Comfy Registry, so it is installable through the registry rather than only by cloning into the custom_nodes directory. The registry entry in pyproject.toml is:

[tool.comfy]
PublisherId = "erosdiffusion"
DisplayName = "ComfyUI-enricos-nodes"

The README does not give an install command, so the registry listing and the release page are where you would start.

Where ComfyUI-enricos-nodes is the wrong tool

Three boundaries, and the first is the one that decides whether the node is useful at all to you.

The first is that a visual compositor is a manual step in what is otherwise an automated pipeline. The whole value of ComfyUI is that a graph runs without you. This node exists to place images by eye, which means a workflow containing it has a human in the loop by construction. That is fine for a series of images you are curating, and it is a poor fit for a batch job that has to run unattended overnight. The saving of positions across generations softens this, since the layout becomes reusable, but the first composition of every new layout is still manual.

The second is the alpha status and the two coexisting versions. The v4 line is explicitly a preview, with erase restoring a foreground in some cases, sub-pixel rounding, unreliable transformation tools, and mask output removed. The v3 line is stable in the sense that it is the older released behaviour, but it has its own issues, including that reload may no longer preserve configurations after a Comfy regression, and that the mask stacking feature is promised but not delivered. Choosing between them is a choice between an unstable new interface and an older one missing a feature, and the README does not steer you.

The third is resource use. The README says it plainly: it can be very heavy depending on the size of the canvas and the imported images, and advises against importing eight 4K images into a 4K canvas. Since the node keeps a compositing canvas and the layers in the browser frontend, and the whole thing is a JavaScript UI, a ComfyUI instance on a modest GPU box with a modest browser can struggle before the model even runs.

The alternative approach is to do the composition in the graph with transform nodes, and the difference in approach is reproducibility versus convenience. Numeric transform nodes are deterministic, they are part of the workflow file, and they compose with everything else in the graph, and they cost you the drag-and-drop that makes the visual node pleasant for a first layout. A hybrid is what most people end up with, using the compositor to explore a layout, then baking the resulting numbers into plain transform nodes for the workflow that actually runs. That is a reasonable pattern, and the node supports it, since positions and scaling are remembered and the output transforms report the angle and bounding box coordinates.

Editorial conclusion

Adopt ComfyUI-enricos-nodes if you build ComfyUI workflows that need precise manual composition of several generated images, since the alternative is doing that arithmetic in graph nodes, and the node remembers positions, scaling and rotation across generations and reloads. Do not adopt it if you need a stable production node, because the v4 line is published as an alpha preview with a stated list of known issues including unreliable transformation tools and sub-pixel rounding, and the v3 line still exists for the older behaviour. Verify first that you are on the version whose behaviour you want, since the v3 and v4 implementations are separate files in the repository, that your canvas and image sizes are reasonable because the README warns the node is heavy, and that the outputs you need exist, because the v4 changelog notes that mask output and advanced outputs were temporarily removed.

Frequently asked questions

Official sources

1. erosDiffusion/ComfyUI-enricos-nodes on GitHub
2. Issues
3. License: MIT
4. README
5. Releases