receyuki / comfyui-prompt-reader-node

The ultimate solution for managing image metadata and multi-tool compatibility. ComfyUI node version of the SD Prompt Reader
MIT License
289 stars 22 forks source link

[FEATURE REQUEST] - Some limitations when using the Prompt Saver #76

Closed lfarrell20 closed 5 months ago

lfarrell20 commented 5 months ago

Summary

I wasn't sure if this is a feature request or bugs. Placing in feature request because there are workarounds to each issue or I'm just an edge use case.

First, thank you so much for your work. I can't imagine my workflows without Parameter Generator and Prompt Saver. I've come across a few use cases where I struggled to achieve a desired result. Not sure if it's user error or inherent limitations. So apologies before hand if I'm missing something obvious.

  1. When running a batch and saving out, each metadata file contains the same seed even though each generation is iterating on said seed. To recreate a specific image from a batch (that is not the first image) I don't have access to the actual seed. This also happens if using %seed in the name. I'm pulling directly from the Parameter Generator into the Saver. Workaround, using a preview gate where I can pause the generation and choose what to pass through.

  2. The VAE_NAME input works just fine when connecting directly from the Parameter Generator ----> Prompt Saver. However if using a reroute (RG3) or Get/Set node the Prompt Saver will refuse the input connection. The output on the Get node says "COMBO" if that helps. Workaround, using your Extractor to create a Set variable which the Saver accepts without issue.

  3. My instance of Comfy lives on a different drive than my save location. The Prompt Saver preview does not like this and cannot show previews. I'm thinking this might be user-side setting causing an accessibility issue, but wanted to raise the concern. Even though an error gets thrown in the console, does not impeded the generation in any way. Workaround, using a generic previewer laid on top of the Saver

File "C:\Users[username]\AppData\Local\Programs\Python\Python310\lib\ntpath.py", line 807, in commonpath raise ValueError("Paths don't have the same drive") ValueError: Paths don't have the same drive

Basic Example

  1. Seed Not sure the details on how one would go about grabbing the proper seed. It feels like once the prompt is executed an INT value is sent through the PG into the Saver and that value is used for every instance. I did try using the extractor but, again, just generating a single INT value.

  2. VAE_NAME Might be more tied to the other nodes involved than with these specific ones as they work fine when directly connected. Might have to find out how Get/Set/RG3 nodes are interpreting the output from the PG

  3. Directory shrug emoji

Reference Issues.

No response

receyuki commented 5 months ago

Thanks so much for your support. Regarding the issue you’ve raised, I’ll do my best to resolve it.

  1. Other users have also brought up similar issues, but I haven’t found a solution yet. Many people have posted similar questions on ComfyUI’s issues about "how to find the seed from an image generated in a batch" but it seems you can only regenerate the same image through batching and you can’t get the second or third image individually. (Honestly, I have no idea why either.)
  2. You’re right, VAE_NAME is a special COMBO type (much like a complete list of VAEs), while Get/Set/Reroute changes this into a regular COMBO. My Extractor can convert any type to a special "Any" type, which can connect to anything. The Extractor wasn’t designed for this, I didn’t expect it being useful that way. I might add the same feature to Type Converter, which will turn any type into an Any type.
  3. This is an issue caused by ntpath.commonpath(), but it doesn’t seem to come from my code, so I’m not sure how to fix it. But perhaps you can map your save path to your ComfyUI directory via symbolic links.

https://www.howtogeek.com/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

lfarrell20 commented 5 months ago

Thanks for your reply! I figured I might be bringing up things that may have been mentioned, so hope I'm not creating extra threads for you.

  1. Honestly, it's good to hear that I'm not the only one facing this, felt like I was taking crazy pills. If I want to recreate/up-level a specific image from a batch I simply regenerate the whole batch using a preview gate to pause the workflow, sending only that specific image(s) to my other workflows. Not ideal, but pretty low calorie.

  2. Now I think I should be using the Type Converter. The reason I'm using get/set is because I have about 10 of your Savers in a single workflow to save out images at each step of the process (if needed). Working great right now. Below is a simplified version of what I'm doing. The output ends up looking like this: VAE hash: c6a580b13a, VAE: vae-ft-mse-840000-ema-pruned Screenshot 2024-06-06 091000

  3. Yea, I was getting the feeling it might have to do with external factors on this one. Love the symbolic link idea, clever workaround.

Again, thank you for your thorough and thoughtful responses. Keep doing your amazing work, the Comfy community appreciates you!

receyuki commented 5 months ago

If I want to recreate/up-level a specific image from a batch I simply regenerate the whole batch using a preview gate to pause the workflow, sending only that specific image(s) to my other workflows. Not ideal, but pretty low calorie.

I think Latent Form Batch is what you need. https://blenderneko.github.io/ComfyUI-docs/Core%20Nodes/Latent/batch/LatentFromBatch/

I just updated the Type Converter node, please give it a try.

lfarrell20 commented 5 months ago

That works too, though I find myself using chrisgoringe's image picker. https://github.com/chrisgoringe/cg-image-picker

Just tested out the Type Converter and it's working like a charm 🌟 Saves me from doing that send->convert->resend flow I had going on. Thanks for the updates!

receyuki commented 5 months ago

Bad news, I just reverted the commit about Type Converter node because of #78. Instead of modifying the Type Converter node directly and facing compatibility issues, I'll create a new node called Any Converter.