fix: allow to process multiple images

[bluematter]

Motivation

I want to pass in a number of outputs into comfy and get the same amount of outputs sent back in the API

Issues closed

#95

[khengyun]

why you hard code like this ?

[khengyun]

replace with ENV variable pls

[TimPietrusky]

@bluematter thanks for putting the effort into this PR.

it looks to me that you not only added support for multiple images, but also a lot more (like redis and loras and more). would you mind to clarify everything you have done here, so that we can do a proper review?

[Andergraw]

Hey guys, thank you all for the great work. @bluematter wouldn't it be easier to just fix the batch loading separately and then add the other features sequentially?
Thanks!

[TimPietrusky]

@bluematter @Andergraw @khengyun we have added support for multiple output images in #118, is that what you wanted? because multiple input-images are already possible

[Andergraw]

@bluematter @Andergraw @khengyun we have added support for multiple output images in #118, is that what you wanted? because multiple input-images are already possible

This exactly what I wanted, thanks! How is it done? Using the batch input from Empty Latent node? Can It be done with runsync endpoint?
Thanks again!

[TimPietruskyRunPod]

Hi @bluematter — thanks for sending this, but this PR is unfortunately too far out of date to merge as-is.

It modifies src/rp_handler.py, which no longer exists on main — the handler was moved to handler.py at the repo root and substantially rewritten in the 5.x series. The diff is 908+/227− against a file that's no longer there, so a clean rebase isn't feasible — it would need to be re-implemented against the current handler.

What the PR appears to add (handling multiple input images) is actually already supported on main: the input schema accepts an input.images array where each element is {name, image (base64)}, and the handler uploads each one to ComfyUI before queueing. See handler.py:170-200 and handler.py:320-340 for the current implementation.

Two options:

1. If your use case is not covered by the current array-of-images input — could you open a fresh issue describing the specific scenario? I'd be happy to look at it.
2. If your use case is covered, this PR can be closed.

Either way, the existing diff isn't recoverable into a modern PR. Sorry for the slow reply.