Replies: 1 comment 1 reply
-
I think this would be incredibly helpful in faithfully recreating the workflows of others. I was actually just researching the idea of a node to include model hashes into the workflow. I don't know how slow hashing a 4GB+ model might be but it would be great if this was stored/cached somehow by ComfyUI and added automatically. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Good day to everyone!
There have been previous discussions in the ComfyUI repository about how users could identify where to download models for their workflows. However, aside from using hashes, no practical solution was suggested. @huchenlei mentioned that creating a discussion here would be the best way to move forward.
I didn’t want to rush this, as I’ve been working on improving the model catalog for Visionatrix to enable one-click model additions while exploring what CivitAI can offer. This process has given me insights into how we can make things more convenient for users and what, from the perspective of a workflow creator and ComfyUI dev-ops/admin, I’d like to see in ComfyUI to simplify providing model information directly in workflows.
Now, I feel ready to share an idea:
Since it’s important to support hashes in both regular workflows and API-based workflows, I propose storing hashes within file names as part of the data structure. This approach minimizes changes to the backend and avoids significant structural expansion.
For example, in the API-based workflow format, we currently have:
And in the regular workflow format:
What if, instead of just strings, we add optional support for tuples where the second element contains the hash? For example:
This would allow users to conveniently search for models on platforms like CivitAI and enable tools or automation plugins to automatically download models for workflows with the click of a button.
On the ComfyUI backend, the required modifications should be minimal. Essentially, we’d need to handle cases where a tuple is used instead of a string:
What does everyone think? Does this idea look good and worth implementing? Are there any blind spots or better alternatives to consider?
Beta Was this translation helpful? Give feedback.
All reactions