One of the things they seem to be emphasizing here is the UX around being able to place specific elements where you want them in an image. If the positions of the components in the overall composition are very important, this seems to make that a lot easier and kind of reminds me of InvokeAI.
Ideogram V4, an open-weight model released back in June can also do this [1], but you have to use a relatively cumbersome JSON structure to describe all the different bounding boxes. So it’s definitely a bit of a hassle.
I'll probably be waiting until it goes open-weight (hopefully soon) like they did with Flux.2 / Klein.
I always hated Comfy's node based UI, but agents make it tolerable. Now I just have them set up a workflow and I go in and tweak it manually if the results aren't where I want them. I even have agents cherry doing multiple runs and cherry picking the best outputs, models have gotten good enough that it's a real time saver, assuming you have references they can and a rubric to check against.
Awhile back I built a project which reads comfy's API and builds a typescript sdk from it. Much nicer to work with and still benefits from node caching and the comfy ecosystem. Perhaps I should clean it up and open source it, though I haven't looked around and there may already be other projects doing this out there.
Using AI for the ComfyUI API or workflows worked pretty well for me even early this year.
However, today I don't see a reason to use ComfyUI at all.
For Qwen Image 2.1, I had Opus 5.5 create a backend outside of ComfyUI and it was able to make generation take 20% less time with some optimizations.
The optimizations it implemented were caching the text computation in Qwen Image 2.1 rather than including it in every step, fusing projections into a larger matrix multiplication, and decoding the VAE in horizontal bands or something like that.
If there was anything interesting in ComfyUI nodes, I imagine I could just have the AI adopt the relevant code instead of dealing with ComfyUI or custom nodes.
vunderba · · focus · HN ↗
Ideogram V4, an open-weight model released back in June can also do this [1], but you have to use a relatively cumbersome JSON structure to describe all the different bounding boxes. So it’s definitely a bit of a hassle.
I'll probably be waiting until it goes open-weight (hopefully soon) like they did with Flux.2 / Klein.
[1] - <a href="https://docs.ideogram.ai/using-ideogram/getting-started/prompting-guide/4.-json-prompting-ideogram-4.0" rel="nofollow">https://docs.ideogram.ai/using-ideogram/getting-started/prom...
kranke155 · · focus · HN ↗
CuriouslyC · · focus · HN ↗
swiftcoder · · focus · HN ↗
It's one of the most uniquely hostile user experiences I've ever had the (dis)pleasure of working with
bavell · · focus · HN ↗
user43928 · · focus · HN ↗
However, today I don't see a reason to use ComfyUI at all.
For Qwen Image 2.1, I had Opus 5.5 create a backend outside of ComfyUI and it was able to make generation take 20% less time with some optimizations.
The optimizations it implemented were caching the text computation in Qwen Image 2.1 rather than including it in every step, fusing projections into a larger matrix multiplication, and decoding the VAE in horizontal bands or something like that.
If there was anything interesting in ComfyUI nodes, I imagine I could just have the AI adopt the relevant code instead of dealing with ComfyUI or custom nodes.