Live data from Hacker News

FLUX is fast and it's open source

replicate.com

121–127 of 127 posts

Re: FLUX is fast and it's open source

#121
post #99
post #96

Earlier quoted context omitted.

Thanks for the links Im glad there are people who are experts at character design. For my untrained eyes it just looks like all of the characters are muddy coloured ( washed out greens brown etc ) AND they are pretty much all incredibly ugly. I think I saw one that atleast looked fashionable, the black sniper female. The older I get the more concerned I get that the larger the team that makes decisions the worse the…

Bureaucracy and hierarchy are much more damaging to good products than a large team. The flat structure and long timelines are how they overcame the limitations of a large team.

Thanks for the reply, I guess thats the secret

Re: FLUX is fast and it's open source

#122

Non-commercial is not open-source, because if the original copyright holder stops maintaining it, nobody else can continue (or has to work like a slave for free). Open-source is about what happens if the original author stops working on it. Open-source gives everyone the license to continue developing it, which obviously means also the ability to get paid. Don't call it open-source if this aspect is missing. Only the…

Doesn’t open source mean the source is viewable/inspectable? I don’t know any closed source apps that let you view the source.

As I said above: Open-source is about what happens if the original author stops working on it. Having the code viewable/inspectable is a side effect of that - can't sustain a project if all you have are blobs. Famously, Richard Stallman started GNU because he wanted to fix a printer: "Particular incidents that motivated this include a case where an annoying printer couldn't be fixed because the source code was withheld from users." https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...

Re: FLUX is fast and it's open source

#125
post #10

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

You're right -- this wasn't clear. Added another paragraph to explain what you had to do before.

Re: FLUX is fast and it's open source

#126
post #39

Earlier quoted context omitted.

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…

As a DoF "hater", my problem with it is that DoF is just the result of a sensor limitation (when not used artistically etc.), not some requirement of generating images. If I can get around that limitation, there's very little motivation to maintain that flaw. In the real world, if I see a person at the beach, I can look at the person and see them in perfect focus, I can then look at the ocean behind them and it is al…

If you have the camera focus on the person, they'll be in perfect focus. If you then have the camera focus on the ocean, it'll be in focus.

Our eyes work the same way. Of course, just like the camera's aperture can be set our pupils will be pretty contracted on a beach.

Of course, you should be able to tell the AI to generate it how you want - that's the goal, after all. Having at least a somewhat shallow depth of field by default makes sense though.

Re: FLUX is fast and it's open source

#127

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 guess the inefficiency is obvious to many, it's just a matter of time until something like this will come out. and yeah, as others said, you might lose info a-to-b that's needed for b-to-c, but you gain more in predictability/customization
Post reply on HN