[Bug]: 通过 API 生成的批量图像不会创建网格

[zmhgit]

Checklist

• [ ] The issue exists after disabling all extensions
• [x] The issue exists on a clean installation of webui
• [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
• [x] The issue exists in the current version of the webui
• [ ] The issue has not been reported before recently
• [ ] The issue has been reported before but has not been fixed yet

What happened?

Batch images generated through the API do not create a grid After batch_size=4 is set, no grid diagram is returned via api request However, there is a grid diagram return on the webui Parameter passing error or design

Steps to reproduce the problem

What should have happened?

After batch_size=4 is set, no grid diagram is returned via api request However, there is a grid diagram return on the webui

What browsers do you use to access the UI ?

No response

Sysinfo

none

Console logs

none

Additional information

none

[w-e-w]

the code is there so I so it's possible to grid when using via API but but is there a particular reason why you require a grid to be return via API and not just stitch the image on client side?

[zmhgit]

代码就在那里，所以我可以在通过 API 使用时进行网格化， 但是是否有特殊原因为什么您需要通过 API 返回网格而不仅仅是在客户端缝合图像？

Just want to ask if the api request contains this function, adjust the parameter to return the built-in grid diagram. The client stitched the image because the original image generation speed is slow, and the client stitched the processing time is extended

[w-e-w]

to clarify because I worded my answer badly currently it is not possible because the grid code is disabled when using via API

that the grid code is there, so it is not that hard to just enable it by makeing small change to the code

but I believe this was disabled because it was deemed unnecessary as client should be able to stretch the image themselves to their exact use case also sending the grid back basically means doubling the data

[zmhgit]

澄清一下，因为我 目前订购的答案很糟糕，这是不可能的，因为通过 API 使用时网格代码被禁用

网格代码就在那里，所以通过对代码进行小的更改来启用它并不难

但我相信这是禁用的，因为它被认为是不必要的，因为客户端应该能够将图像本身拉伸到其确切的用例， 同时将网格发回基本上意味着数据加倍

Thank you for your help, but our current business requirements may require a return to the grid diagram. Want to ask for your help, how should I modify the grid code, and what is the name of the file that needs to be modified

[w-e-w]

so I was mistaken it is possible for the grid to be returned when using via API but it does come with some issues

currently if you want the grid to be retruned the payload save_images will have to be true this will cause do_not_save_grid to be false ans so allowing the grid to be created and then returned https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/8b6848c6dbee95f055b98b33804b12bd188ac625/modules/api/api.py#L442-L443

but this payload is also used to determine whether or not if the generated images are saved to server output

the code that determined but it will not look good gets generated is here

https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/8b6848c6dbee95f055b98b33804b12bd188ac625/modules/processing.py#L1067-L1078

---

can you explain why exactly in what scenario you're in that requires you to have the great return directly and not stitch by the

Just want to ask if the api request contains this function, adjust the parameter to return the built-in grid diagram. The client stitched the image because the original image generation speed is slow, and the client stitched the processing time is extended

can you explain why exactly do you need the grid to be stitched by the server and returned when using via API it seems to me there's only downsides, wasting server time that can otherwise be used on generating the next batch of images on stitching images then sending essentially double the amount of it of data back across the network

if you can make a compelling reason I could make a PR to webui and to make returning grid support natively

[zmhgit]

所以我错误地认为通过API使用时可能会返回网格， 但它确实存在一些问题

目前，如果您希望重新调整网格，则有效负载save_images必须是true ，这将导致do_not_save_grid因此false，允许创建网格然后返回

https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/8b6848c6dbee95f055b98b33804b12bd188ac625/modules/api/api.py#L442-L443

但此有效负载还用于生成确定图像的是否保存到服务器输出

确定但看起来不太好的代码在此处生成

https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/8b6848c6dbee95f055b98b33804b12bd188ac625/modules/processing.py#L1067-L1078

您能解释一下为什么您的具体情况需要您直接获得东南亚的回报，而不是通过

只是想问一下api请求是否包含这个功能，调整参数返回网格图中。客户端切割图像因为原始图像生成速度慢，客户端切割处理时间延长

你能解释一下为什么你到底需要服务器婚礼网格并在通过API使用时返回网格，在 我看来只有这样，浪费服务器时间，否则可以用于在婚礼图像上生成下一个图像然后发送本质上是通过网络返回的数据量增加一倍

如果你能提出一个令人信服的理由，我向可以通过 webui 发起 PR 并发起支持返回网格

I really feel that your answer has helped me solve the problem. Since I do not know the code logic of stable-diffusion, I think the stitching of the grid diagram by me is the same as the stitching at the stable-diffusion api, both of which occupy the server time. Unexpectedly, stitching at the stable-diffusion api requires the operation of saving images, which takes up server resources. Now look down at the stable-diffusion code when it is unfriendly. I can manually stitch myself through base64

[zmhgit]

所以我错误地认为通过 API 使用时可能会返回网格， 但它确实存在一些问题

目前，如果您希望重新调整网格，则有效负载save_images必须是true ，这将导致do_not_save_grid为falseans，因此允许创建网格然后返回

https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/8b6848c6dbee95f055b98b33804b12bd188ac625/modules/api/api.py#L442-L443

但此有效负载还用于确定生成的图像是否保存到服务器输出

确定但看起来不太好的代码生成在此处

https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/8b6848c6dbee95f055b98b33804b12bd188ac625/modules/processing.py#L1067-L1078

您能解释一下为什么您所处的具体情况需要您直接获得丰厚的回报，而不是通过

只是想问一下api请求是否包含这个功能，调整参数返回内置网格图。客户端拼接图像因为原始图像生成速度慢，客户端拼接处理时间延长

你能解释一下为什么你到底需要服务器缝合网格并在通过API使用时返回网格在 我看来只有缺点，浪费服务器时间，否则可以用于在缝合图像上生成下一批图像然后发送本质上是通过网络返回的数据量的两倍

如果你能提出一个令人信服的理由，我可以向 webui 发起 PR 并原生支持返回网格

Hello, why do I make txt2img request through api, and some large size diagrams fail to generate back, but they succeed in webui, such as 1200×800?

[wei-z-git]

I`m developing a chat bot just like midjourney which could return a grid with 4 pictures, after view the discussion above, I prefer to combine four images on the client side. 🙂