[Feature Request]: processing multiple images at once using the img2img batch mode.

[ImBadAtNames2019]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

So for example, lets say im processing a folder of images using the img2img batch mode, but i want to process the first 3 images at once, and then once they are done move on to the next 3 images, and so on, like a larger batch size without processing the same images multiple times. Currently if i increase the batch size in the img2img batch mode, it processes the same image multiple times, and then moves on to the next one.

Proposed workflow

Im not sure.

Additional information

No response

[Z-nonymous]

So you want to apply the same img2img transform to a batch of images ?

If that is the case, then writing a custom script to do that should be pretty straightforward.

[Z-nonymous]

Oh, sorry, I think I understand now, you want the batch tab of img2img to process images x by x instead of one by one.

Right now, if you have two images in source directory, and you select batch size, it will do two at the same time withthe first image and then two at the same time with the second image. This results in 4 images generated.

Where you would want just the two images to be processed once at the same time, resulting in 2 images generated.

I'll let someone else chime it. I'm really confused by how n_iter and batch_size behave depending on the script or context.

[ImBadAtNames2019]

Oh, sorry, I think I understand now, you want the batch tab of img2img to process images x by x instead of one by one.

Right now, if you have two images in source directory, and you select batch size, it will do two at the same time withthe first image and then two at the same time with the second image. This results in 4 images generated.

Where you would want just the two images to be processed once at the same time, resulting in 2 images generated.

I'll let someone else chime it. I'm really confused by how n_iter and batch_size behave depending on the script or context.

Yes, i dont know how to explain myself better, the first 3 images toghether, then the next 3 images, and so on, in order, same seed same settings same prompt, it should be significantly faster if you have a lot of vram, i think.

[TangrisJones]

Hey ya'll, I'm also looking for this. Any updates?

[Z-nonymous]

I didn't look in details, but you'd likely need to change process_batch() in img2img.py. That's where the batching happens. Doing so would need a rewrite of the for loop since it basically loops the input images one by one, and then multiply each by batch_size before sending to processing as identical images.

Ideally to do it the clean way, you'd need to have maybe another checkbox toggle to activate this so you could also revert to the previous behavior.

It may work. Having a quick look at what StableDiffusionProcessingImg2Img is doing, then there's some additional logic there.

• if the number of image per processing is 1, then it will increase the dimension to batch_size (maybe for the case it's in use by the regular img2img tab (non-batch)).
• else if the number of image per processing is less or equal the batch_size, it reduces the batch size. (not sure why, it's either 1 image from regular img2img and batch_size images if from batch img2img).

Maybe that helps you write this feature.

[Z-nonymous]

Ok, I just took an hour to test a quick hack and it works, but there are some caveats: That quick hack:

• breaks the old behavior of batch_size
• doesn't use batch_count anymore
• doesn't save textinfo (maybe it was already the case before) so maybe it breaks the seed as well, (i.e. increases it by one for each image in the batch) ? Probably need to create a list of identical seeds if that's the case.
• needs the number of source files in input dir to be a multiple of batch_size (otherwise throws an exception)
• may break with source images of different size (untested)
• may also break when using inpainting masks directory (untested)

I think the combination batch_count / batch_size has inconsistent uses throughout stable-diffusion-webui, between how it's using in txt2img/img2img or in various scripts. ...anyway the whole project would benefit from a big refactoring, but then it would slow down development of new features, and likely break a few scripts and extensions along the way.

I won't PR this quick and dirty hack of course, but you can use it if you like: img2img.zip (edit: fixed generated filenames)

Just replace modules/img2img.py. Later if a git pull needs to change that file, it you'll likely need to git checkout modules/img2img.py.

[Z-nonymous]

Actually tested source images of different sizes and it works (at least with Just resize). For inpaint batch it works as well, but it will take the same mask for the batch so you can't have multiple different masks in same batch (not supported by StableDiffusionProcessingImg2Img class).

Additional caveat : it will overwrite the images in destination folder, but that's already the case with the normal batch mode of img2img.

So then, what would be next for this to be somewhat PR-able would be to:

• add UI feature to toggle on/off (maybe that just switches between the legacy process_batch and a new one with above changes)
• fix the seed (maybe also a UI toggle for it)

Not sure if Automatic1111 is ok to further bloat the UI with this. Also, this is a specific rare usage case, I don't think having the regular one by one processing is that a big deal. I'm having a hard time thinking why you'd use often img2img with many images with the same settings. Also larger images in batch will need more GPU VRAM. I may look further into it if Automatic1111 thinks it's worth adding.

[ImBadAtNames2019]

Ok, I just took an hour to test a quick hack and it works, but there are some caveats: That quick hack:

• breaks the old behavior of batch_size
• doesn't use batch_count anymore
• doesn't save textinfo (maybe it was already the case before) so maybe it breaks the seed as well, (i.e. increases it by one for each image in the batch) ? Probably need to create a list of identical seeds if that's the case.
• needs the number of source files in input dir to be a multiple of batch_size (otherwise throws an exception)
• may break with source images of different size (untested)
• may also break when using inpainting masks directory (untested)

I think the combination batch_count / batch_size has inconsistent uses throughout stable-diffusion-webui, between how it's using in txt2img/img2img or in various scripts. ...anyway the whole project would benefit from a big refactoring, but then it would slow down development of new features, and likely break a few scripts and extensions along the way.

I won't PR this quick and dirty hack of course, but you can use it if you like: img2img.zip (edit: fixed generated filenames)

Just replace modules/img2img.py. Later if a git pull needs to change that file, it you'll likely need to git checkout modules/img2img.py.

Actually tested source images of different sizes and it works (at least with Just resize). For inpaint batch it works as well, but it will take the same mask for the batch so you can't have multiple different masks in same batch (not supported by StableDiffusionProcessingImg2Img class).

Additional caveat : it will overwrite the images in destination folder, but that's already the case with the normal batch mode of img2img.

So then, what would be next for this to be somewhat PR-able would be to:

• add UI feature to toggle on/off (maybe that just switches between the legacy process_batch and a new one with above changes)
• fix the seed (maybe also a UI toggle for it)

Not sure if Automatic1111 is ok to further bloat the UI with this. Also, this is a specific rare usage case, I don't think having the regular one by one processing is that a big deal. I'm having a hard time thinking why you'd use often img2img with many images with the same settings. Also larger images in batch will need more GPU VRAM. I may look further into it if Automatic1111 thinks it's worth adding.

O wow thank you so much, i will check it out.

[TangrisJones]

@Z-nonymous thanks!

[anduvo]

Hi Z, I have generated 100000 images with txt2img in 24h generating them in batches of 10 at once. They are 768x512 and now I am using img2img with the outpainting script to outpaint them to 768x768.

And I have this exact problem that img2img batch, takes one image at the time and using very few ram although I have 24gb.

So I have calculated that it will take about a week to finish!. And doing them 10 at once would have taken again a day or two I think. So just wanted to give you a real example use case for this feature

[ArakiSatoshi]

The new img2img.py doesn't seem to be working for me. The terminal window gives me this error, even with the 3rd party extensions disabled:

    Traceback (most recent call last):
      File "C:\Users\User\Desktop\Large Language Models\AI Art\Automatic1111\webui\modules\call_queue.py", line 58, in f
        res = list(func(*args, **kwargs))
      File "C:\Users\User\Desktop\Large Language Models\AI Art\Automatic1111\webui\modules\call_queue.py", line 37, in f
        res = func(*args, **kwargs)
      File "C:\Users\User\Desktop\Large Language Models\AI Art\Automatic1111\webui\modules\img2img.py", line 85, in img2img
        override_settings = create_override_settings_dict(override_settings_texts)
      File "C:\Users\User\Desktop\Large Language Models\AI Art\Automatic1111\webui\modules\generation_parameters_copypaste.py", line 349, in create_override_settings_dict
        k, v = pair.split(":", maxsplit=1)
    ValueError: not enough values to unpack (expected 2, got 1)

I'm a bit confused about the needs the number of source files in input dir to be a multiple of batch_size part, could it be the issue of the ValueError? In my example, I have 16 images starting with frame0001.png and ending with frame0016.png, and I tried every available batch size from 1 to 8.

About if it has its place in the official build. I was pretty confident that the feature discussed in this thread already exists in the UI. The use case to consider when thinking about implementing it officially could be generating images based on extracted frames from videos and assembling them back into an AI-generated video. As it is shown by @anduvo, it's cutting the time needed to process the whole set of images more than in half.