Address review feedback: the previous fix allowed ImageBlend to return
tensors with > 4 channels (e.g. blending a 3-channel and a 5-channel
image produced a 5-channel tensor). This shifted the original failure
from blend-time to save/preview-time, because SaveImage and PreviewImage
both call PIL.Image.fromarray, which only supports 1/3/4-channel arrays.
Fix:
- In Blend.execute, the alignment target is now min(max(c1, c2), 4):
any image with more than 4 channels is truncated, any image with
fewer is padded with 1.0s up to the (capped) target. This makes the
RGB/RGBA case work and also makes the >4-channel case work end-to-end
rather than just deferring its failure.
- Update the regression test that previously codified the wrong
5-channel-output behavior to assert the correct 4-channel cap.
- Add test_output_capped_at_four_channels (both inputs > 4 channels).
- Add test_save_compatible_output_passes_through_pil that mirrors
SaveImage's exact PIL.Image.fromarray conversion to catch regressions
in the save/preview path.
- Add a small workflow-validation test (image_blend_workflow_test.py)
that loads tests/inference/graphs/image_blend_channel_mismatch.json
and verifies its node types and wiring, so the demo workflow can't
silently bitrot.
Verified end-to-end against a local ComfyUI server: the workflow runs,
output is RGBA, downstream SaveImage succeeds.
- test_output_clamped now uses inputs that would produce -0.5 without
clamping, so it actually exercises the torch.clamp(..., 0, 1) call.
- test_padding_value_is_one verifies that the channel-alignment logic
pads with 1.0 specifically (not 0.0 or some other value), which is the
semantic guarantee of treating the extra channel as an opaque alpha.
- Add regression tests covering RGB+RGBA, RGBA+RGB, channel gap > 1
(the exact CORE-103 error case), all blend modes with mismatch, and
output value clamping.
- Soften the inline comment to reflect that channel padding is well-
defined for alpha-like extra channels rather than claiming support
for arbitrary channel layouts.
