-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Feature(app): Add an endpoint to recall generation parameters #8758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…nsmit to frontend -core generation parameters -support for LoRAs and IP-adapters -controlnets -documentation in docs/contributing/RECALL_PARAMETERS
|
An idea: Could this work with existing saved (i.e. in-database) workflows rather than recalling past queued generations, using linear-exposed parameters as those you could populate? |
This functionality is agnostic about where the parameters are coming from. They could be retrieved from image metadata, come out of an in-database workflow, or be generated de novo by another application. My driving use case is to enable a loose integration with PhotoMapAI such that if you have indexed and clustered a folder of InvokeAI images, then you can click on an image, retrieve its linear-exposed parameters, and pass them to a running InvokeAI for remixing. Or here's a fun use case. You right click on an image in some photo app or other and send it to a visual LLM to generate a description of the image. You then retrieve the image dimensions and send them along to InvokeAI to generate something that matches the description. |
|
Fair. I am going to defer to frontend folks on this one. But I definitely like the idea and see usefulness in creating another endpoint that lets you execute a specified saved workflow by giving it potential overrides for its exposed linear parameters. This is certainly one path to get to sub-workflow execution if we do it right. |
Summary
This PR adds a new route endpoint named
/api/v1/recallwhich updates the recallable image generation parameters with new values passed via a POST. The route then triggers the front end to load the updated values. This is intended to make it possible to integrate InvokeAI into desktop workflows where image generation parameters are stored in an external database. It also creates the foundation for remote-controlling the front end.Related Issues / Discussions
None.
QA Instructions
You can test this PR by sending the following requests to the back end and confirming that the frontend picks up and displays the changed parameters.
Basic Fields:
The full list of recallable parameters that can try for testing is here:
positive_promptnegative_promptmodelrefiner_modelvae_modelschedulerstepsrefiner_stepscfg_scalecfg_rescale_multiplierrefiner_cfg_scaleguidancewidthheightseeddenoise_strengthrefiner_denoise_startclip_skipseamless_xseamless_yrefiner_positive_aesthetic_scorerefiner_negative_aesthetic_scoreLoRA Models:
(Change the LoRA names as appropriate to what you have installed).
IP Adapters:
Currently you can only use images that have previously been uploaded or generated and are located in the
INVOKEAI/outputs/imagesdirectory.The API handles both ip_adapters and flux_redux models, even though they take different parameters (irrelevant parameters are ignored). This matches the behavior of the front end.
ControlNets
Again, you need to provide the name of an image that is already in the InvokeAI system. If no image name is provided, then the controlnet parameters will be loaded and the user can upload the image of their choice.
Full Description of the API
See
docs/contributing/RECALL_PARAMETERS/*.mdMerge Plan
Should be a simple merge.
Checklist
What's Newcopy (if doing a release after this PR)