Flux is the leading contender for a locally hosted generative systems in terms of prompt adherence, but the omnipresent shallow depth of field is irritatingly hard to get rid of.
I guess it's optimized for artsy images?
FLUX is fast and it's open source
31–40 of 127 posts
Re: FLUX is fast and it's open source
#32Text to image models feels inefficient to me. I wonder if it would be possible and better to do it in separate steps, like text to scene graph, scene graph to semantically segmented image, segmented image to final image. That way each step could be trained separately and be modular, and the image would be easier to edit instead of completely replace it with the output of a new prompt. That way it should be much easie…
The issue with this is there's a false assumption that an image is a collection of objects. It's not (necessarily). I want a picture of frozen cyan peach fuzz.
https://imgur.com/ayAWSKr
Prompt: frozen cyan peach fuzz, with default settings on a first generation SD model.
People _seriously_ do not understand how good these tools have been for nearly two years already.
Re: FLUX is fast and it's open source
#33Re: FLUX is fast and it's open source
#34I just cancelled my Midjourney subscription, it feels like it's fallen too far behind for the stuff I'd like to do. Spent a lot of time considering using Replicate as well as Ideogram.
I have been questioning the value beyond novelty as well recently. I’m curious if you replaced it with another tool or simply don’t derive value from those things?
Re: FLUX is fast and it's open source
#35> We added a new synchronous HTTP API that makes all image models much faster on Replicate. ooh why is synchronous fast? i click thru to https://replicate.com/changelog/2024-10-09-synchronous-api > Our client libraries and API are now much faster at running models, particularly if a file is being returned. ... thanks? just sharing my frustration as a developer. try to explain things a little better if you'd like it t…
I mean it literally explains why in the second paragraph. It returns the actual file data in the response rather than a URL where you have to make a second request to get the file data
thats not "making the image models much faster", thats just making getting the image back slightly faster
Re: FLUX is fast and it's open source
#36My favorite thing to do with Flux is create images with a white background for my substack[1] because the text following is amazing and I can communicate something visually through the artwork as well. [1] https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...
That example you gave is a good reason why artists get pissed off IMO. The LLM is clearly aping some artists specific style, and now missing out on paid work as a result.
Not sure I have an opinion on that, technology marches on etc, but it is interesting.
Re: FLUX is fast and it's open source
#37Text to image models feels inefficient to me. I wonder if it would be possible and better to do it in separate steps, like text to scene graph, scene graph to semantically segmented image, segmented image to final image. That way each step could be trained separately and be modular, and the image would be easier to edit instead of completely replace it with the output of a new prompt. That way it should be much easie…
That's essentially what diffusion does, except it doesn't have clear boundaries between "scene graph" and "full image". It starts out noisy and adds more detail gradually
That's true, the inefficiency is from using pixel-to-pixel attention at each stage. It the beginning low resolution would be enough, even at the end high resolution is only needed at the pixel's neighborhood
Re: FLUX is fast and it's open source
#38this comparison for the quantization effect is very nice https://flux-quality-comparison.vercel.app/ however i do have to ask.. ~2x faster for fp16->fp8 is expected right? its still not as good as the "realtime" or "lightning" options that basically have to be 5-10x faster. whats the ideal product usecase for just ~2x faster?
Funny, sometime I like the fast one better.
Re: FLUX is fast and it's open source
#39Flux is the leading contender for a locally hosted generative systems in terms of prompt adherence, but the omnipresent shallow depth of field is irritatingly hard to get rid of.
I guess it's optimized for artsy images?
They almost certainly did DPO it, so that would have an effect. It was also probably just trained more on professional photography than cell phone pics.
I’ve found it odd how there’s a segment of the population that hates a shallow depth of field now, as they’re so used to their phone pictures. I got in an argument on Reddit (sigh) with someone who insisted that the somewhat shallow depth of field that SDXL liked to do by default was “fake.”
As in, he was only ever exposed to it through portrait mode and the like on phones and didn’t comprehend that larger sensors simply looked like that. The images he was posting that looked “fake” to him looked to be about a 50mm lens at f/4 on a full frame camera at a normal portrait distance, so nothing super shallow either.
Re: FLUX is fast and it's open source
#40Text to image models feels inefficient to me. I wonder if it would be possible and better to do it in separate steps, like text to scene graph, scene graph to semantically segmented image, segmented image to final image. That way each step could be trained separately and be modular, and the image would be easier to edit instead of completely replace it with the output of a new prompt. That way it should be much easie…
Isn't this essemtially the approach to image recognition etc. that failed for ages until we brute forced it with bigger and deeper matrices?
It seems sensible to extract features and reason about things the way a human would, but it turns out its easier to scale pattern matching purely done by computer.