[enhancement]: Bulk Image Actions

[peterdandreti]

Is there an existing issue for this?

• [X] I have searched the existing issues

Contact Details

No response

What should this feature add?

Bulk actions for Image Board

Two ideas come to mind to make image boards more useful:

1. Export selected images
2. Export all images
3. Export selected metadata to CSV / workflow
4. Export all metadata to CSV / workflow

Just thinking about making image boards more useful. I'll use an example to demonstrate the point: Say you've put together a collection of images into a board - there's no way of exporting that. It still needs to be downloaded 1 by 1. Bulk actions that apply to a board would be ideal, such as download the board of images, or export the meta data for each image to a CSV.

Alternatives

Using the Retrieve Images from Board node and wiring this for output.

Additional Content

No response

[psychedelicious]

Let's focus this on exporting images - we'll be refactoring the workflow storage implementation in 3.3.1/3.4, and after that we can iterate on exporting metadata/workflows in a more flexible way.

For board/image export, I think this is a fairly straightforward feature, but involve a changes across the stack:

• Update the low-level image storage services - base class ImageFileStorageBase and disk implementation DiskImageFileStorage - to take a list of image names and return a zip file containing all of them. Discussion points include:
  • Do we include thumbnails? (probably not)
  • Do we offer a quality option? (probably not)
  • How do we name the images? They have UUIDs for names, and it probably makes sense to leave it like that
  • Do we write any other data to a file? Maybe a summary txt file?
• Update the base class ImageServiceABC and ImageService implementation to accept a board id or list of image names, and then call the newly implemented low-level methods. If given a board id, you'd need to use the board images service to get the image names for that board
• Update the images_router and boards_router with routes to handle these tasks this is completed, see invokeai/app/api/routers/images.py
• Update the context menus for boards and multiple-image-selections with options to call these methods this is completed, see invokeai/frontend/web/src/features/gallery/components/ImageContextMenu/MultipleSelectionMenuItems.tsx & invokeai/frontend/web/src/features/gallery/components/Boards/BoardContextMenu.tsx

I'd suggest waiting until #4671 is merged before working on this, as it simplifies the services structure greatly.

Please touch base with us if you want to work on this!

[maryhipp]

@psychedelicious I would add that this should kick off something like a background task, right? Versus within the request/response cycle

[psychedelicious]

Yeah good call. I suppose it would need to prepare the file, then emit an event saying it's ready. Clients could handle the event by downloading the file, or another service could respond to the event however they chose.

Does that sound right @maryhipp ?

[empessah]

I just want to add mostly for better user flow work for production. Could we get "Export" that take selected image, puts them in a folder, and adds metadata that is compatible with Adobe Bridge? Being able to use bridge tagging and filtering on larger projects will be extremely helpful, especially when developing many assets for a project. And be able to leverage the Rating system. I might be rambling, but it would be really cool if Adobe Bridge could be the "File manager" for exports so you can run invoke semi-headless on a network. Just navigate to the folder view in Bridge and do the work.

[peterdandreti]

@empessah : On Adobe Bridge / other metadata based content managers. Bridge(and others) read the EXIF chunk from the image file. So an option in Invoke to write an EXIF chunk into the output PNG might be the agnostic way to provide metadata to any of the 3rd party content managers. (Since they all know to look for EXIF, and Bridge is not available for Linux.)

On the Bridge side of things, try to get your hands on an untainted image output from automatic1111 (i.e. including the original automatic1111 metadata, such as by asking a favour on discord), then see how this metadata looks in Bridge. I have a suspicion a lot of it will just get filed under a generic catch all category as XMP (Adobe's metadata format) is centred on photography, rights and design specific metadata. However the metadata will still be sort- and search-able.

The reason why I say "untainted image output from automatic1111" is because a downside to saving metadata in the image file is that a sizeable chunk of online sharing / social media services automatically recompress images which destroys this metadata.