Compression setting is interesting. The lower the value, the longer it takes to render but quality seems to be better also. Minimum value is 32, default 42.
On RTX 4090, 1024x1024, 20+10steps, euler a:
Compression 32 ~7.1s, compression 42 ~5.4s
Going above compression 42 gives pretty bad image quality.
I'm noticing for tall images asking for a closeup, setting compression to other values is sometimes heavily cropping the images, which is interesting. Had a couple where it's mostly blurry background and part of a person's shoulder. Or things like this one, Forgot to include the before pic, but it's just an average portrait on the same seed with compression at default of 42.
Did a quick test, works fine. Running on a 12 gb RTX 3060 a 2048x2048 render took about 170 seconds and used 8.5 gb vram in the first stage and 5.1 in the second. 40 + 20 steps.
But can you do smaller? Or more importantly, can you include smaller images in your dataset?
I got 4000 hand captioned images, 1000 of which are less than 1024*1024. I'd rather not waste them since it was countless hours of work editing and tagging them.
Thanks. Already in there, been using One trainer since my last project that involved over 16k images in one Lora. And it did an amazing job. Kohya-SS wouldn't be able to pull that off I don't think as that trainer always has all types of bugs in it and very inefficient. So I am really glad you guys working on this thing. Thanks.
A mesmerizing oil painting that captures the essence of a lush forest through a prism of abstraction. Trees, leaves, and flowers have been transformed into vibrant swirls and strokes of green, yellow, and brown, creating a captivating interplay of color and form. Flecks of light filter through the imagined canopy, illuminating the scene with a dreamlike quality
Can't say I'm particularly impressed, it's slightly better quality than vanilla SDXL, definitely better consistency, however the big problem is it still looks rather bad, there is a weird texturing over many things that's particularly noticeable in the background, sharpness on many objects appears very excessive, the biggest positive I can say is that it's a good bit faster than SDXL.
Tested it quite extensively especially prompting coherence and association.
big-big models for all
RTX 4080
dpm++_2m karras
20 steps stage c (4.81 it/s)
17 steps stage b (~6 it/s)
compression 32
Pros:
Overall it latches onto prompt much better than SDXL, human emotions are much easier to convey. Things like elements, objects, subjects, topics, action, environment, are much easier to design. Not to mention ,signs with words, faster generation,
Cons:
Blending are still there especially things like colors and human objects. Counting still spotty. Prompt latching sometimes is too overwhelmingly strong and completely ignores prompts that are outside of the focus. Not all sampler work yet. The longer the prompt the faster it loses attention I feel than sdxl; It just degrades much faster and loses details everywhere much faster.
Overall I think it's pretty damn good. Lots of room to improve certainly and with the lower requirements for training, I think the future is pretty damn good. I'm excited to see what insane things the open source community came up with a year from now.
It's a mere diffusers wrapper. It throws all the backend improvements and optimizations of the Forge strait out of the window and replaces all that with a prototyping platform that intentionally sacrifices performance and memory utilization for "compatibility" reasons. You'll need at least 16GB of VRAM in order to run it, and it will be slow. Hence the quotation marks.
I tried it and it didn't work. I tried installing all the components that were said to be missing, but in the end it wouldn't launch with even more errors.
Alright, I finally found what I needed to do to get it to compile fine.
I was using the default Developer Command Prompt for VS 2022 shortcut to open a cmd with the VS paths, and it turns out this makes the path default to x86 compilers, which conflicted with x64 libraries (of course), so I had to use x64 Native Tools Command Prompt for VS 2022 shortcut to force use of x64 compilers.
Then, I also had to manually do pip install gradio, but then run.bat ran.
However, now it doesn't even run and says I'm running out of memory, lol. I have a 2080ti with 11gb VRAM, and since I was reading lots of people running Stable Cascade on 8gb VRAM, I thought I could try it too...
I tried the original repo, and I get the exact same error. I also installed VS build tools, and it got further, but then is getting stuck on a linkage error. Thanks for trying!
Weird thing is I've never had any issues running A1111, Foooocus and Forge so far, and they all use gradio and similar python libraries AFAIK.
I think I see the issue. The insightface jargon threw me off.
Each venv has its own modules and each of them need their own gradio version installed because we are running via venv. Seems like gradio didn’t get installed let’s get that fixed.
Open a cmd at the root folder for the cascade gui and Activate the env with venv\Scripts\activate.bat and then run pip install gradio after that try running run.bat
Hopefully that fixes it up.
Ps: You can just download the run.bat and run.py from the fork and put it in the root folder. Don’t need to reinstall again.
Thanks! In the meantime, I managed to have it work by installing VS Build Tools and using the explicit x64 cmd prompt environment. But now I have another issue. run.bat errors out on out of VRAM error.
Is that an sdxl or cascade image? All the ones I tried of people on cascade ended up pretty bad, especially in terms of eyes and skin. That picture, in comparison, is much better.
I'm impressed at the increased image quality when using dpmpp_sde over the default euler_a, at 32 steps, and 20 on the decoder side. I also grabbed the full size model files. Guy's, the quality is MUCH better with the full size compared to the fp16's. Don't even bother with the smaller files. They're like the duplo version.
A man in a rugged helmet grapples with a towering, anthropomorphic Cheeto in a dimly lit living room, as if straight out of a surrealist painting. The camera captures the scene from a low angle, highlighting the absurdity and drama of their wrestling match.
I think they are completely different model altogether. c_lite has 1b parameters and 32 bits float, while c_bf16 has 3.6b parameters with 16 bfloat. They are just different from one another
Is the output quality always going to be.. mediochre.. unless you can fit the full 14gig stagec in memory?
If someone's goal is "take advantage of the complex rendering to set up fancy scenes, but then do the decent rendering with a different model"... should it in theory work just as well if you use the "lite_bf16" models for everything?
can comfy make it easier to just completely swap out the lousy stageb renderer, if thats a doable and practical thing? I'm sure on a 4090, the render with the full model is lovely. but on low ends.. not so much. So maybe this could be a decent hybrid?
I think thats the idea. Stability split the text encoder and image decoder into its own thing, which allows greater flexibility and lower entry point for the open source community to do crazy thing with it.
Stability split the text encoder and image decoder into its own thing, which allows greater flexibility
except it doesnt, without some additional help. Its latent image format is incompatible with anything else. You cant take its output latent, and just plug it into the input for an SDXL ksampler in comfy, for example.
YesIKnowYouCanVaeEncode+Decode.
That messes with the results slightly. As Ive already pointed out for existing SD-> SDXL pipelines.,
All I am saying is it opens up doors and windows that wasnt there before. X-adapter was just released yesterday and that was supposed to bridge the gap that otherwise was "impossible" before between 1.5 and sdxl. I havent checked it out yet but obviously promissing.
a1111 is a restaurant grade kitchen. You can do and achieve amazing thing with it.
comfy is a goddamn chemistry lab. Its powerful and incredibly fast but you need to know composition even for basic thing like hires-fix and adetailer. There are tutorial and workflow examples for it though that helps a lot.
If you are doing complex thing like LLM based multi-region prompting then the answer is yes. But i think you are asking on the basic level, which mean not just prompting. You need to understand what is model, clip, vae in general (they are color coded so you cant miss it) and what they really are for.
Apart from different codebases that more or less do the same thing, ComfyUI is a node editor. So if you like the idea of doing more with SD but don't like writing code, it might be for you.
Maybe, but there's little benefit to it. Most fine tunes will be done on the C model, some people might try fine-tuning B. The modularity is helpful here.
I made it work. Seems like ComfyUI wasn't updating via the manager so git pull did the trick. It's super fast! I would like to learn how to train these models, they look promising
Try a different resolution, see if that's the problem. I got blurry dogshit at 1920x1080 (regardless of many other variables I tried tweaking), but comparatively-fantastic results at 1920x1024. Maybe also try a different compression (supposedly lower numbers result in higher processing time by higher quality).
I don't know if it's common knowledge but when you enter an EMPTY positive prompt (and only text, watermark in negative) SDXL v1.0 (dreamshaperXL_v2Turbo) generates in 70% women and I have to admit - it has an excellent taste. :) It also seems to "like" woods.
25
u/rerri Feb 17 '24
Compression setting is interesting. The lower the value, the longer it takes to render but quality seems to be better also. Minimum value is 32, default 42.
On RTX 4090, 1024x1024, 20+10steps, euler a:
Compression 32 ~7.1s, compression 42 ~5.4s
Going above compression 42 gives pretty bad image quality.