For landscapes with architecture and for environment concepts inspired by the style of Maxfield Parrish, this will bring unpredictable variety to your images and enrich them with intricate details.
(!) If you use FLUX in Forge - setting Diffusion in Low Bits - Automatic (fp16 LoRA) sometimes gives more interesting results. I recommend experimenting.
Description
More training images and learning steps. A trigger word activates additional, broader possibilities that go beyond the style of Maxfield Parrish
FAQ
Comments (9)
Umm, isnt "Diffusion in Low Bits - Automatic (fp16 LoRA)" actually the only way Flux Loras work at all in Forge?
In general, all LoRAs work for me in simple automatic mode, the "automatic (fp16 LoRA)" setting sometimes just allows me to achieve more interesting results. I accidentally learned from Chromesun that this does not apply to everyone.
Curious. I'm gonna test this again
Edit: Alright. Automatic does something now, as opposed to a few months ago, but it completely tanked performance. I went from 3-4 seconds/iteration to 30+ seconds/iteration, even after restarting Forge to make sure it wasn't some memory leak or something. I guess it is safe to say that simple Automatic is still very much not advisable. ^^
The only way Forge is guaranteed to get the maths mostly correct. Before this option was added, some LORAs worked fine, making me think the ones that did not were my fault- so many lost hours.
@OneViolentGentleman The issue you see is a simple consequence of bad memory management, an issue with both Forge and ComfyUI. The FAULTY Forge LORA mode tried to adjust the entire model with the LORA values before iterating, the mostly correct mode applies the LORA at the time of each iteration. The two methods have differing memory footprints, that can trigger memory thrashing in your VRAM! The irony is that if you see 2 secs per iteration or worse, your computer has time to keep moving all the input data (model and LORA) from RAM to VRAM each iteration, in VRAM friendly memory blocks.
It is WRONG to demand model data resides in VRAM for Flux (unless you have a 4090, and are using one of the super-optimised render methods). Of course, for SD, this isn't true, since SD usually gets many iterations per second.
@blobby99, @OneViolentGentleman, I did a little testing - https://civitai.com/images/40065533 I have a weak video card and little video memory. In my opinion, the problem may be in the lack of updates, xformers, Python library, perhaps the video card driver.
@Marielle I don't think so. I'm pretty much up to date with everything, I think and it looked similar on my end. Automatic image was different, but only very slightly so versus Automatic fp16. Also thanks for the explanation @blobby99
The more fantasy/SF landscape LORAs, the better. Ever notice (in that one example image) how both Flux and SD have the annoying habit of generating that same SINE-WAVE river feature in so many pictures?
Since the models are Turing-Complete (can function as full blown computer programs), it is a shame we cannot explicitly demand randomness in our prompts- hopefully the next version of Flux will address the 'sameness' issue for a given prompt- which one sees even when trying to generate landscapes.
Of course, I noticed the monotony of the composition in Flux, but LoRAs help to cope with it a little. You can also complicate the settings, mix several models at once, there is a way out.😊
Details
Available On (1 platform)
Same model published on other platforms. May have additional downloads or version variants.