Acly
commented
1 month ago Hm, that's a huge workflow. Maybe try to start with the simplest workflow possible? I'm not sure your issues are related to combining inpaint + IP-adapter specifically...
It appears to be using the source image and feeding that into the ipadapter, which doesn't make sense to me - it would just generate some variation of the same image, no?
That's a common use case: remove objects from an image, extend (outpaint) image, fill gaps in the image. In all those cases you want to fill with "more of the same", and using the original image also as IP-adapter input works well. It's essentially a substitute for having to discribe via text prompt what's already in the image.
Of course if you want to add something new to the image, feel free to use a different input for IP-Adapter. Here is a workflow: inapint-ip-adapter.json
Hey! Thanks for your hard work in putting this together - I'm having issues getting the ipadapter nodes to produce anything that isn't a jumbled mess.
This may result from some confusion on my end. but the included workflow for promptless doesn't seem to include room for the image being used instead of a prompt. It appears to be using the source image and feeding that into the ipadapter, which doesn't make sense to me - it would just generate some variation of the same image, no?
I like the idea of having an inpainting tool that
actually works that I can pair with ipadapter but nothing I'm producing with this, no variation of ipadapters or models, is producing anything usable with ipadapter. I've included the workflow I've put together that I'm trying to get a working ipadapter inpaint flow for in hopes I've done something wrong, because this doesn't seem to work as-is.
manyipadapters.json