Hello everyone,

Version 0.2.0 has been released.

Can people comment on how much time it is taking to generate one image for both versions. Also please mention your system specs and OS version. Thanks.

Link to 0.1.0: https://github.com/divamgupta/diffusionbee-stable-diffusion-ui/releases/download/0.1.0/DiffusionBee-0.1.0-arm64.dmg Link to 0.2.0: https://github.com/divamgupta/diffusionbee-stable-diffusion-ui/releases/download/0.2.0/DiffusionBee-0.2.0-arm64.dmg

In the new 1.4.0 build on Intel and macOS Ventura:

Here is the full error:

Backend quit unexpectedly. /AppleInternal/Library/BuildRoots/810eba08-405a-11ed-86e9-6af958a02716/Library/Caches/com.apple.xbs/Sources/MetalPerformanceShadersGraph/mpsgraph/MetalPerformanceShadersGraph/Runtimes/MPSRuntime/Operations/GPUStitchedOps.mm:76: failed assertion `should be static because stitched op is static'

Thanks for bringing back the Intel build by the way!

Problem

The app build is not running on ealier MacOS versions with M1. Building from source takes too much time. Tested on MacOS Monterey 12.3.

Solution

Expand support for Mac folks who haven't received an 12.5.1 update 🙂

This resolves #11.

We are a few people interested in writing and maintaining documentation for DiffusionBee. This is an issue for discussing the form for that documentation.

Current idea

Idea: Keep documentation in a separate GitHub repository, until DiffusionBee development has slowed down enough to make it reasonable to have the docs in the main project.

Why: @divamgupta is (rightly) focusing the energy on moving DiffusionBee forwards. This also means that there is not enough time to review issues concerning documentation. Keeping the docs in a separate repo allows others to maintain the docs, while divamgupta can focus on his awesome magic.

Some other thoughts

• The docs repo would ideally be owned by @divamgupta, with docs writers added as co-maintainers (with commit access). But it could also be owned by someone else.
• If the docs is deemed good enough, it would make sense to have a link from the GitHub landing page for DiffusionBee, and probably also at diffusionbee.com.

Other ideas

• Put the documentation in a Google Doc (plus possibly keeping non-trivial issues for the docs in this issue queue). Is this a better option, just to get going?
• Keep the documentation in a wiki on the DiffusionBee project on GitHub. (That would require open up access for more people. Uncertain of what permission.)
• Keep the documentation in markdown files in the DiffusionBee repository. (That would require commit access for more people.)

I'm as far from a coder as one can be but I love creating images with Diffusion Bee (THANK YOU DIVAM!!!!) and would love to inject my stupid face into the AI images. Alas I don't know how to install Dreambooth... =(

This app is awesome, but this is an important lacking feature. Some of us would love to re-train the model to make it able to generate ourselves (for which there are easy options, like some public google colab notebooks). I think that it would be fairly easy to enable, so I hope it's added in the next version

Anyway, thanks for the app and keep on the great work 🙌

Provides a clone of the conversion script, no_pickle_convert_model.py, that uses the also new no_pickle_fake_torch.py; the cloning script is otherwise identical.

no_pickle_fake_torch.py uses Fickling to decompile the pickle file in a .ckpt file. From the decompiled instructions, it enumerates all the Stable Diffusion keys and loads in the relevant weight for each in exactly the same way that fake_torch.py does, returning to the conversion script the dict of weights it is expecting.

Converted .tdict models checksum to the same values as ones done using fake_torch.py and (unsurprisingly) work fine in DBee.

Have successfully tested with Stable Diffusion 1.4 Stable Diffusion 1.5 pruned Classic Animation Redshift Diffusion Anything V3 F222 (per issue #307) PaperCut V1 Mdjrny V4

Fixes the missing prompt and seed values in default save image boxes. Also ensures the default file name length won't be above OS restrictions, and that multibyte characters like é don't cause problems in the future with the same.

Closes #210 Closes #201 Closes #118

Resolves the issue https://github.com/divamgupta/diffusionbee-stable-diffusion-ui/issues/216

It would be amazing if you can add the "HACKTOBERFEST-ACCEPTED" label to the PR (that way it'll count toward my Hacktoberfest PRs https://hacktoberfest.com/participation/ 😅 )

If I get it right (but please correct me if I am wrong) currently the app runs python in the background which is very bad from performance perspective.

I would suggest to convert some (e.g. PyTorch) or even all models to CoreML and use the more native implementation on a M1/M2 Mac. I hope this would use better the Neural engine. Any comments from the experts?

I have a 48-core GPU and 2-core CPU in my M1 Ultra Mac Studio. The first built (the only other i've tried) would leave the CPU cores alone when running for the most part but max out the GPU cores. I fired up the new version today and told it to make 4 images, 512x768, 50 steps, 7.5 i think... anyway the GPU isn't doing anything and all the CPU cores are maxed out while running in Activity monitor. Also it's using 4GB ram where it used to used 45GB for a similar (single image) prompt. I'm guessing these changes make it behave better on lower spec'd machines but it's a downgrade in speed on mine for sure.

If this is a deliberate change can there be a preference, or can it use both CPU and GPU?

Thanks :)

EDIT: Oh wow, I thought it would be making four files at once, no it's one after the other. It is WAY slower than before then, very considerably so.

Just like we already have "send to" for image-to-image and inpaint, I'd love to see an option to send to outpaint, as this would safe several workflow steps.

I would like to be able to remove the current 100-image limitation (DiffusionBee version 1.5.1) so that I can let the app run all night without wasting computer idle time.

I know Divam (the dev) must be extremely busy; is it possible for a layperson to do that easily without having to wait for him to implement this feature some day?

Intel macOS 12.6.2 by the way.

Thanks!

It would be nice of DFBee could throttle back when it's taking up too much CPU/GPU time My one issue is that it makes the mouse cursor disappear when trying to multitask and I can't even click stop when it overloads the mac.

5/10 times I get black outputs on Text prompt and all the time for Inpainting

Bit annoying to re-run and re-run generations to not get anything

Running MacOS Monterey

Generated images get randomly overwritten by new ones when the prompts are identical. It happens mainly while generating tons of images from the same prompt. I counted that up to 1% was overwritten. I first noticed the issue while comparing the number of images in the history against the smaller amount available in the image output folder on the disk. Then I got the evidence by searching for and founding duplicate image file names in the history (while copying and parsing the html).

Can someone please clarify if there's a folder where new models are installed to? I mean once you install a several Gigas model, where is this data stored? Can you remove models?