search

lllyasviel / stable-diffusion-webui-forge

GNU Affero General Public License v3.0
8.09k stars 791 forks source link

preprocessor images not being returned in api response #2051

Open dermesut opened 1 week ago

dermesut commented 1 week ago

title says it basically. in the forge-version prior to this "new", constantly updated one controlnet images that were generated, be it canny, lineart, depth etc., were sent together with the resulting image and could be fetched in the response. i don't know, why that's not the case anymore - i found it very useful and would love to have those back.

altoiddealer commented 1 week ago

@dermesut To clarify:

Please clarify your expectations

altoiddealer commented 1 week ago

title says it basically.

Also clarify, I think you mean:

preprocessor images not being returned with api response

dermesut commented 1 week ago

title says it basically.

Also clarify, I think you mean:

preprocessor images not being returned with api response

oh yes, absolutely. thank you. changed the title.

dermesut commented 1 week ago

@dermesut To clarify:

  • Is this for txt2img only? Or, expected for img2img but not working?
  • I see that img2img endpoint has the parameter include_init_images - Are you setting this to True for img2img request?
  • I do not see include_init_images as a valid request param in any other WebUIs for txt2img (A1111 / ReForge / Forge old / etc)
  • In any case, it shouldn't be too painful to retain your own inputs and do whatever you want with them post-gen.

Please clarify your expectations

be it txt2img or img2img, the api-response used to return a list of images: the resulting rendering together with the resulting preprocessor images (the ones that can be seen in the webui as small previews beneath the big rendered image). a depth map if one had a depth-preprocessor activated, or any other preprocessor result, really. one can still see them in the webui, but via api-response they are not returned anymore. in forge "1" they were, in forge "2" they aren't (not sure, how to name those... pre- and post-experimental state maybe?)

altoiddealer commented 1 week ago

Ok so I believe the setting which controls this in particular is the controlnet parameter save_detected_map

Do you have this set to true for each controlnet?

dermesut commented 1 week ago

Ok so I believe the setting which controls this in particular is the controlnet parameter save_detected_map

Do you have this set to true for each controlnet?

yes, i do.

altoiddealer commented 1 week ago

I’ll try to debug this later or tomorrow, as soon as I have time

altoiddealer commented 1 week ago

@dermesut You'll be happy to know I have a PR for this now.

This is a feature I was also using personally some time ago, and I never tried to look into it or report an issue or anything.

dermesut commented 6 days ago

awesome! thank you.