It looks like your account has been using HN primarily for promotion. This is against HN's rules - see https://news.ycombinator.com/newsguidelines.html:

"Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity."

A bit of advice...stop. Blatent self promotion of commercial products is a hard no here. We dont want it, and its against the rules. Delete this, and the other posts before they get deleted for you along with account closure.

Before you waste your time, this is a commercial product and you need to pay $30 to buy their model to run it.

What does it mean to be "partially uncensored"?

Okay... what's the downside?

In terms of, what's the tradeoff for the time decrease?

Apples to oranges, they're comparing 11 hours on a Raspberry Pi Zero to:

- 10 seconds on Intel i7-13700

- 3 seconds on Intel i9-9990XE

- 5 seconds on Ryzen 9-5900X

Additionally, the 2048 is accomplished by using RealESRGAN to 2x, which isn't close to what a native 2048 diffuser's quality would be.

It does look interesting and is an achievement, in terms of, it's hard to write this stuff from scratch, much less in pure C++ without relying on GPU.

Ah. I use RealESRGAN (or one of its descendants, rather) as a first pass upscaler before high-resolution diffusion. If you skip the diffusion step, of course it'll be faster.

Unrelated, but now I'm curious about how much would it take on RPis 4 and 5.

yeah me too...I've been very negative about the edge, it got overhyped with the romanticization of local LLMs, but there's a bunch of stuff coming together at the same time...Raspberry Pi 5...Mistral 7B Orca is my 20th try of a local LLM...and the first time it handled simple conversation with RAG. And new diffusion, even every 2 hours, is a credible product, arguing about power consumption aside...

Also $29 to get pre-trained model assets to run code.

Why does this one needs pretrained models? Can't we use any of the thousands of already available ones?

These are mostly Stable Diffusion architecture models, but its not the only game in town.

Hard to tell since there is zero documentation in regard to models.

I see you're opting for AGPL on a codebase that is designed to be embedded as a library. Genuine question, what kind of user did you have in mind when you decided on this license?

Are those 2048 x 2048 images still sensible? SD 1.5 is best used at 512x512 and may produce sensible images upto 768. It generates monstrosities above that. Similarly SD XL is good upto 1024.

These are limitations of a single text-to-image gen, which is the least interesting way to use those models. When guided by a previous low-res generation, it won't fall apart at arbitrary resolutions, that's how all diffusion upscalers work. Just don't expect being able to fit every detail in one pass, use multiple ones (that's how detailers work).

> Are those 2048 x 2048 images still sensible? SD 1.5 is best used at 512x512 and may produce sensible images upto 768. It generates monstrosities above that. Similarly SD XL is good upto 1024.

You can do significantly higher resolutions with various tricks like tiled diffusion, which is also a memory efficiency hack. (The stable-diffusion-webui tiled diffusion extension uses 2560×1280 direct [no upscale step] generation with an SD 1.5-based model as one of its examples.)

Up scaling the image in chunk creates loads of semantic issues. For example, bottom of tree might look further in the mountains but it's top will be near you. You don't see problems like these in non scaled images.

> Up scaling the image in chunk creates loads of semantic issues.

No, tiled upscaling generally does not have that problem significantly (compared to direct generation at native model-supported size, which doesn't completely avoid that kind of issue), since the composition on that level is set before the upscale (direct tiled generation does, if you aren’t using something like controlnet to avoid it.)

> You don’t see problems like these in non scaled images.

You actually occasionally do, but its fairly rare.

It's conditioned on the lowres input, so if it doesn't have semantic discontinuites it doesn't happen. It will eventually happen if you continue doing this indefinitely, but with reasonable size to tile ratio (say <6x) it works well. With manual or object detection-assisted tiling and proper conditioning (controlnets sidechannel, especially if it's a custom trained controlnet/t2i) it can be pushed further.

> Similarly SD XL is good upto 1024.

I don't think that's right. SD xl is good starting from 1024. Anything lower generates a useless mess.

SDXL native trained resolution for 1:1 aspect ratio is 1024x1024 like SD 1.5’s is 512x512. Like SD 1.5, you can go a bit below or above that without too much problem; unlike SD 1.5, SDXL also has significant training in a fairly wide set of other resolutions (ranging from 2048x512 to 512x2048) with approximately 1 mebipixel resolution, and they can be treated as starting points as easily as 1024x1024 can. I think SDXL has a narrower (proportionate) range of viable resolutions around its starting points, but that’s offset but having more than one “starting point”.

Maybe next time shamelessly mention that you sell models for $29 and there is no instructions to convert from vanilla SD.

I can't believe this is still the top comment. I wish I didn't edit down my reply, shoulda just said "this is stupid, you're comparing your desktop to a raspberry pi"

ONNX streaming is way cooler and more impressive than another commercial wrapper around SD. Doesn't deserve this.