Spaces:
Running on Zero
Heavily modified local version
Hi again 👋
I wanted to give a clearer update on how far my modified local version has diverged, and also explain the direction I’m taking with workflow support.
First of all, thank you again for the original FLUX Prompt Generator — it has been a really useful foundation.
Since my earlier message, I’ve continued building on top of it for local use, and it has now become more of a full local prompt + ComfyUI workflow tool.
What has been added / changed
Local model support
- Reworked the prompt generation side to use LM Studio locally
- Added support for selecting locally loaded text models
- Added support for local vision-capable models for image captioning / image-to-prompt
Image captioning
- Replaced the earlier disabled / cloud-dependent caption path with local image captioning through LM Studio
- Added an optional image instruction field so I can guide the captioning result
Batch prompt generation
- Added a batch mode where multiple prompt lines can be processed at once
- Added an optional global instruction applied to the batch
ComfyUI integration
Added direct sending of generated prompts to ComfyUI through the API
Added:
- seed control
- random seed option
- incremental/walk seed option
- multi-image generation count
- preview / gallery return inside the UI
Output naming
- Added support for sending a custom output name into a workflow node so saved image names can be controlled from the app
Workflow management
- Added support for scanning a ComfyUI Workflow folder recursively and showing workflow JSON files in a dropdown
- This makes it easier to switch between workflows organized by model family or project
Persistence / saved state
Added saving and restoring of UI state, including:
- custom input prompt
- subject
- generated text
- seed settings
- selected workflow path
- output naming field
UI restructuring
- Reorganized the UI into clearer collapsible sections
- Added gallery display for generated ComfyUI images
- Improved copy behavior and general layout
Where I’m heading with workflow support
To make future workflows easier to support, I’m thinking of using a small consistent convention in my own ComfyUI workflows, for example:
- a dedicated node ID for the prompt
- a dedicated node ID for the output name
That way new workflows can be adapted to the app more easily without manually changing the Python every time.
What I want to ask
At this point, the project has diverged a lot from the original, but it is still clearly based on your work and I want to be respectful about that.
Would you be okay with me:
- keeping this as a personal/local fork only?
- sharing it privately with others?
- publishing it publicly with clear credit to you?
If you want, I can also send you the modified version for review, although it is spread across quite a few files and includes a lot of workflow-specific changes that may not be useful for the original project.
I’m happy to follow whatever preference or licensing direction you would prefer.
Thanks again for making the original tool — it has been a great starting point.
— Martin
You can publish it on another space no problem for me! I am big supporter of open source
Thanks! I’m still actively working on it and iterating as I go.
I have a few additional features in mind that I’d like to implement next.
One of them is resolution control — either as a dropdown with predefined values (with the option for users to extend it via a settings file), or possibly as a slider for more flexibility.
Another thing I’ve been thinking about is checkpoint selection. That one is a bit more complex. A simple dropdown isn’t really viable, since model locations vary per user, and even if a custom path is defined, there’s no reliable way to determine model type automatically (e.g., Flux.1D vs SDXL vs SD1.5 vs Pony, etc.).
Some users may also have very large model libraries, which adds another layer of complexity — selecting a mismatched model for a given workflow could easily break things.
At the moment, I’m leaning toward leaving checkpoint selection workflow-driven, meaning users would manage it within their JSON workflows instead of through the UI. That seems like the most robust and least error-prone approach, but I’m still exploring options.
I recommend finding some good small vision language models, it can help a lot. Currently qwen 3.5 is super good.