Skip to content
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

[Feature Request] API support in Workflow JSON #2275

Open
ecornbower opened this issue Dec 12, 2023 · 2 comments · May be fixed by #3625
Open

[Feature Request] API support in Workflow JSON #2275

ecornbower opened this issue Dec 12, 2023 · 2 comments · May be fixed by #3625

Comments

@ecornbower
Copy link

ecornbower commented Dec 12, 2023

For external integrations, it is currently impossible to generate an API call solely from a workflow json file. This is because the input names for widgets are not stored in the file, only the values are:

"inputs": [
        {
          "name": "clip",
          "type": "CLIP",
          "link": 3
        }
      ],
"widgets_values": [
        "beautiful scenery nature glass bottle landscape, , purple galaxy bottle,"
      ]

You need to call the object_info endpoint and parse the available nodes to determine what the values should be. The above code eventually becomes the following when sending to the API:

"6": {
    "inputs": {
      "text": "beautiful scenery nature glass bottle landscape, , purple galaxy bottle,",
      "clip": [
        "4",
        1
      ]
    },
    "class_type": "CLIPTextEncode"
  },

I propose that the input widget names are added to the exported JSON files to help build API calls. There would be several ways to do this, but the easiest for backwards compatibility would be to add a widgets_names array.

"widgets_names": ["text"],
"widgets_values": [
        "beautiful scenery nature glass bottle landscape, , purple galaxy bottle,"
      ]

Even better if it were changed to an object:

"widgets": {
  "text": "beautiful scenery nature glass bottle landscape, , purple galaxy bottle,"
}

That way the widget inputs don't have to rely on the index value anymore.

@comfyanonymous Let me know if this is something you're interested in supporting. Happy to submit a PR if you approve.

@philmaas
Copy link

+1
Collecting past Issues here for reference as this feature has been requested several times, should consolidate:

#2031
#1433
#1326

are there any related PRs in progress from someone?

@ecornbower
Copy link
Author

ecornbower commented Dec 13, 2023

@philmaas Thanks for collecting those issues. I believe they are mainly referring to the exported API JSON, whereas I'd like to add this data directly to the exported workflow json and image metadata. That way the workflow will always contain all of the information you'd need to call the API.

I think it makes sense to keep the API endpoints as simple as possible, and encourage users to work with the workflow files and then transform the data to the required API format.

I'm working on a Typescript / JS library to make it easier to parse the workflow files for external applications, if anyone is interested. But right now it requires you to pass in the object_info json in order to generate an API file.

dennwc added a commit to dennwc/ComfyUI that referenced this issue Jun 2, 2024
Currently, any external tooling will have a hard time converting workflow JSON files to the API format.

The main reason is that widgets_values is an array and mapping values from that array to widget names requires loading node types from the object_info endpoint as well. However, object_info depends on the plugins installed and thus may miss some of the nodes in the workflow.

This change adds widget_names to the JSON, allowing direct conversion of workflow files to API format without prior knowledge of all node types. This could also help with compatibility in the future.

Resolves comfyanonymous#2275
@dennwc dennwc linked a pull request Jun 2, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants