Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FLUX is fast and it's open source

replicate.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: FLUX is fast and it's open source

#101

Post by jsemrau »

slig wrote: post #84
jsemrau wrote: post #30

My 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_...

Could you share the prompt? Thanks.

The prompt is actually not that interesting.

"A hand-drawing of a scientific middle-aged man in front of a white background. The man is wearing jeans and a t-shirt. He is thinking a bubble stating "What's in a ReAct JSON prompt?" In the style of European comic book artists of the 1970s and 1980s."

Finding the right seed and model configuration is the more difficult part.

Re: FLUX is fast and it's open source

#102

Post by smrtinsert »

miki123211 wrote: post #73
sorenjan wrote: post #23

Text 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…

In general, it has been shown time and time again that this approach fails for neural network based models. If you can train a neural network that goes from a to b and a network that goes from b to c, you can usually replace that combination with a simpler network that goes from a to c directly. This makes sense, as there might be information in a that we lose by a conversion to b. A single neural network will ensure…

It's my understanding an a-c will usually be bigger parameter wize and more costly to train

Re: FLUX is fast and it's open source

#103

Post by ruthmarx »

jsemrau wrote: post #54
ruthmarx wrote: post #50

Earlier quoted context omitted.

Yeah, I get that completely, I'm the same way. I just think it's interesting. It's kind of the same argument as piracy, since most people wouldn't pay for what they download if it wasn't free.

I'd rather think it's the same argument as open-source and public domain. Currently, I am researching an agent that ReAct's through a game of TicTacToe. I am using a derivative of the open-source transformer's prompt

> I'd rather think it's the same argument as open-source and public domain.

In the context of the point I made, it's definitely more similar to piracy, since the point was about taking advantage of something that if not free people would not pay for.

Re: FLUX is fast and it's open source

#104

Post by smrtinsert »

earthnail wrote: post #65
jsemrau wrote: post #41

Earlier quoted context omitted.

I understand your point, but in 0% of all cases would I hire an artist to create imagery for my personal blog. Therefore, I would think that market doesn't exist.

However, the blogs or newspapers or print outlets that used to hire them hired them because you couldn’t- it was a differentiator. That differentiator is gone, and as such won’t pay for it anymore. They’ll just use the same AI as you. This destroys the existing market of the artist. To be clear, my comment isn’t meant as a judgment, just as market analysis.

This is about as realistic as replacing coders with ai tools today. High level content organizations demand creative precision that even models like Flux can ape but not replace. Maybe to a non-artist it would be comparable, but to a creative team its not close.

Re: FLUX is fast and it's open source

#105

Post by nuancebydefault »

stoniejohnson wrote: post #100
nuancebydefault wrote: post #75

Earlier quoted context omitted.

If I would take the Lesson literally, we should not even study text to image. We should study how a machine with limitless cpu cycles would make our eyes see something we are currently thinking of. My point being, optimization or splitting up int subs, before handing over the problem to the machine, makes sense.

I think the bitter lesson implies that if we could study/implement "how a machine with limitless cpu cycles would make our eyes see something we are currently thinking of" then it would likely lead to a better result than us using hominid heuristics to split things into sub-problems that we hand over to the machine.

The technology to probe brains and visual related neurons exists today. With limitless cpu cycles we would for sure be able to do make us see whatever we think about.

Re: FLUX is fast and it's open source

#106

Post by stoniejohnson »

nuancebydefault wrote: post #105
stoniejohnson wrote: post #100

Earlier quoted context omitted.

I think the bitter lesson implies that if we could study/implement "how a machine with limitless cpu cycles would make our eyes see something we are currently thinking of" then it would likely lead to a better result than us using hominid heuristics to split things into sub-problems that we hand over to the machine.

The technology to probe brains and visual related neurons exists today. With limitless cpu cycles we would for sure be able to do make us see whatever we think about.

I'm not really familiar with that technology space, but if you take that as true, is your argument something like:

- We don't have limitless CPU cycles

- Thus we need to split things into sub-problems

If so that might still be amenable to the bitter lesson, where Sutton is saying human heuristics will always lose out to computational methods at scale.

Meaning something like:

- We split up the thought to vision problem into N sub-problems based on some heuristic.

- We develop a method which works with our CPU cycle constraint (it isn't some probe -> CPU interface). Perhaps it uses our voice or something as a proxy for our thoughts, and some composition of models.

Sutton would say:

Yeah that's fine, but if we had the limitless CPU cycles/adequate technology, the solution of probe -> CPU would be better than what we develop.

Re: FLUX is fast and it's open source

#109

Post by portaouflop »

teh_infallible wrote: post #43
sorenjan wrote: post #23

Text 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…

I am hoping that AI art tends towards a modular approach, where generating a character, setting, style, and camera movement each happens in its own step. It doesn’t make sense to describe everything at once and hope you like what you get.

You can already do that with comfyui - it’s just not easy to set up

Re: FLUX is fast and it's open source

#110

Post by nuancebydefault »

stoniejohnson wrote: post #106
nuancebydefault wrote: post #105

Earlier quoted context omitted.

The technology to probe brains and visual related neurons exists today. With limitless cpu cycles we would for sure be able to do make us see whatever we think about.

I'm not really familiar with that technology space, but if you take that as true, is your argument something like: - We don't have limitless CPU cycles - Thus we need to split things into sub-problems If so that might still be amenable to the bitter lesson, where Sutton is saying human heuristics will always lose out to computational methods at scale. Meaning something like: - We split up the thought to vision proble…

I think Sutton is right that if we had limitless cpu, any human split up would be inferior. So indeed since we are far away from limitless cpu, we divide and compose.

But i think we're onto something!

Voice to image indeed might give better results than text to image, since voice has some vibe to it (intonation, tone, color, stress on certain words, speed and probably even traits we don't know yet) that will color or even drastically influence the image output.

Post reply on HN