Initiatives

[myndxero]

TL;DR -
For now, the biggest two things I had in mind were defaulting a checkbox to on somewhere around the prompt box to enforce token balancing in some way with a simple mouse over on its purpose.
Secondly, a tool tip on why a 99 step cap is optimal to consider, I certainly didn't know any better until inquiring.

Foreword: seems reasonable to continue to repeat that Invoke AI seems to have a lot of appeal for its simplicity of use. I was thinking maybe there's a way to bring an 'easy' mode to Vlad and it would be a useful selling point for new people or lazy people. Plus, I like the idea of new features that sets SD.next apart from A1111 if they're considered valuable and useful. And with the thread about it/s and best practices developing, not just incorporating an "easy mode," but a mode that perhaps reinforces best practices.

My first two thoughts were in regards to prompt balancing, perhaps a check box to artificially enforce prompt balancing perhaps with a specially developed token for this purpose that would have minimal effect on output, but keep tokens balanced. Furthermore, perhaps a tool tip?

Secondly, regarding the cap of 99 steps. Enforcing the limit by default is neat, but perhaps a tool tip for it why as well.

There's mouseovers sure, but maybe a complete robust system of tool tips, to help inform a user and reinforce best practices with their prompting and use. A lot of these things are ancient Eqyptian to a lot of people that wanna get into the space, myself included, and many normies just don't care to spend the time on digging in.

Kinda goes along with Vlad's design philosophy of making SD.next easy and straight forward to install without hassle perhaps encountered with other UIs.

I think down the road, we could come up with a very complete and informative tool-tip system and popups to help new users to get started and experienced users could kinda choose to enable/disable them at the start.

I wouldn't mind doing legwork here to get an idea of the best things people should be informed on and working with the community in the other thread to get them fleshed out and accurate or something.

[vladmandic]

oh yes, i'm 110% for pretty much all you wrote. i'll come back to this and write a more detailed reply in a bit...

[myndxero]

I apologize for being MIA. Real life issues I've been dealing with. I'm glad this idea has really blossomed into something. Hopefully I can hop back in and help some later this week.

If there's anything I should update my OP with tag me. I'll catch on everything soon. Today's the first day I've turned my PC on and updated in a week or so.

[myndxero]

Take your time. I suspect this will end up being a time-consuming undertaking. Must pace.

…

On Thu, Jun 1, 2023 at 10:46 AM Vladimir Mandic ***@***.***> wrote: oh yes, i'm 110% for pretty much all you wrote. i'll come back to this and write a more detailed reply in a bit... — Reply to this email directly, view it on GitHub <#1246 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2755J4EFYKAUY25KT6Y3JTXJC2PHANCNFSM6AAAAAAYW6IYZI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[brknsoul]

I love this idea, especially if it could be implemented in Settings.
For example; the average user wouldn't have any idea what these settings do, as the labels aren't very informative;

or these (sigma? wtf?? ;-) )

Perhaps a little ❓ in each section to pop up a overlay with a simple explanation, and tooltips for more info.

Another option would be to have an "Expert Mode" toggle that would show/hide lesser used options.
But this might be against the grain of SD.Next.

[vladmandic]

ok, finally going back to this thread.
imo, there are multiple topics

simple ui

how to have something simple for non-expert user?
actually, im thinking out-of-the-box and instead of trying to simplify existing ui, why not have a completely new ui?
something very simple and based on pure HTML/CSS/JS - for example, something based on StableStudio.
that would also enable wider audiences as it can be easily hosted.
and when such a beginer user outgrows very basic ui, he transfers to full webui.

i'd love to spin up a project for this if there are interested contributors?

cleanup ui and add help

this applies to all labels and hints.
i've just started doing that and its going to be a non-trivial effort, but as a first step i've created a new uniform engine that can be used to

• change labels on-the-fly
• create localized versions
• add hints to any labels
  as of today, this is live as experimental.

to start, open html/locale_en.json and you'll see that each label has option for localized value and hint. and everything is sorted per section so its (somewhat) clear what-is-what

i'd love to have contributors to fill that file with all possible hints as well as to propose suggestions for better labels for some values.

restructure settings

issue is that a lot of server settings are not really server settings and should not be there, they should be local settings.
for example, sampler is local setting and its passed as parameter to generate and that generate can be executed,queued,stored,redirected,anything (in the future).
but if i change server setting like force latent sampler, well that is something that is read from inside generate function when its executing. so if you queue generate, then change it - guess what is going to happen when your queue executes?
also, imagine sending requests to different servers (why not have a pool of servers) and they don't have same server settings?
or imagine having multi-user ui? well, you cant if settings are global.

i've done the change so far to a single setting - i've moved clip_skip from global to local and i had to answer questions about it for the next week.

this is a big one as its extremely messy from dev side, but needs to be done sooner or later or we're heading to a wall.
and its going to cause a lot of stir - why is sdnext different than a1111.

[TheOnlyHolyMoly]

as I view it (and please correct me if I am wrong here): With every week that is passing SD.Next is getting less and less a fork of a1111. You are adding great tech and great functionality daily and you address the right matters in terms of what is "suboptimal in a1111 architecture". And with every step the difference between these two branches get bigger, it gets more challenging and code merging upstream/downstream becomes greater effort. There will be stirr but it is absolutely the right way forward getting those issues patched.
I am just wondering why a1111 is not saying "okay, before we deviate too much and have to reinvent things like torch 2 integration from scratch alone" we should rather fully align to the SD.next branch to be on the latest tech again and then take it from there... they have too many open issues anyhow...1.9k

[vladmandic]

tagging few more ppl here: @Aptronymist @Woisek @TheOnlyHolyMoly @DirtyHamster @mark-wd
(tag others that may be interested in contributing)

[TheOnlyHolyMoly]

sure, I am on this train! I guess I could help well with filling the hints and maybe also the localizations. Testing for sure. Let me know if you'd have anything else in mind where I could help. My coding is not excellent, though I can bring in thoughts for simplifying / default settings for the easy mode.

[vladmandic]

thanks - and hell yeah, i'm open for ideas!

[Woisek]

Yeah, count me in to what is needed.

[Aptronymist]

Ditto, I can't code anything complicated, but I get by with GPT and can tweak and make changes. Happy to do more grunty work as well, as I stated on the discord, I'm sick of no tooltips. I still have no idea what some of the options do and I plan on fixing it.

[mark-wd]

I believe it's pretty important to start creating more of an identity for this fork, seeing as it's hard to define right now what are its precise advantages. To me (and prob other active people) the advantage is being able to have an actual open source community around the software and participate in its evolution, but that's hard to quantify to most people. It needs to be more than "a fallback to 1111".

So what could it be? Easy Diffusion is the "for babies" version, so could SDNext be a middle ground? That could be it. It needs to be as powerful as 1111 but have them better presented. To me, by far the quickest way to do that would be to actually add explanations to what things mean. I consider myself moderately experienced with generative AI at this point, yet I still many times come here to ask "what is a quadratic this and that"?

A second thing would be to continue improving UI and UX towards something entirely new, because honestly even though SDNext is better, this whole gradio ecosystem seems to be a complete pain... it's the thing I see @vladmandic complaining the most about. Is there a way to abstract it more?

Just some initial thoughts.

[vladmandic]

seeing as it's hard to define right now what are its precise advantages

good point. perhaps someone less biased than myself can go over the release notes i've been writing and compile a top-ten(ish) that we can place in a readme and highlights?

so could SDNext be a middle ground

nope! :)

i want sdnext to be superset of a1111, but that doesn't mean that it should have "more options", it should have more features that matter. i've always been for picking best defaults and only exposing stuff that is actually useful, not every knob and button that nobody understands. but that doesn't mean less functionality.

for example, project is already well underway to bring whole diffusers ecosystem into sdnext and that would open a whole new world of possibilities.

A second thing would be to continue improving UI and UX towards something entirely new

thats what i spoke about before.

first, there is already a massive project ongoing to completely rehaul gradio ui. yes, its still massively complex and not-performant. but at least we can bring it to 21st century ui standards. fully dockable and customizable panels, theme editor, etc.
lets be honest with ourselves - there is sooo much gradio in webui, we're not getting away from it.
and remember one other thing - all extensions also draw their parts of ui by extending on gradio defined by webui.

so removing gradio would mean death of extension ecosystem and that is not something i want.

but i also believe we need a simple native html ui for the masses. and i think stablestudio would be a good starting point.
i can do all the necessary backend work to make it compatible, but someone needs to take a point for the project and actually get it off the ground, i have too much on my plate right now.

[Aptronymist]

first, there is already a massive project ongoing to completely rehaul gradio ui. yes, its still massively complex and not-performant. but at least we can bring it to 21st century ui standards. fully dockable and customizable panels, theme editor, etc. lets be honest with ourselves - there is sooo much gradio in webui, we're not getting away from it. and remember one other thing - all extensions also draw their parts of ui by extending on gradio defined by webui.

so removing gradio would mean death of extension ecosystem and that is not something i want.

but i also believe we need a simple native html ui for the masses. and i think stablestudio would be a good starting point. i can do all the necessary backend work to make it compatible, but someone needs to take a point for the project and actually get it off the ground, i have too much on my plate right now.

Could there not be a conversion process worked up? To convert/adapt gradio extensions to any newer system so we aren't held back by gradio? Or at least guide for some of us so we can bring non-functional extensions into the SD.Next ecosystem?

Fixing up the install.py scripts, making them compatible with the alterations you've made, etc.
I'm sure we've all encountered extensions that don't work in SD.Next but work fine on auto1111, I'd like to see that go away if possible.

If users are going to have all the cutting-edge benefits of being under the SD.Next Vlad-Brella™️ then we should probably try to address things like that as well.
I'd personally like to see your work be the TOP SD app, not seen as a "fork".

[VStudioAI]

Guys, I'd like to weigh in here, AND i'd like to help. I have over 20 years in Web and UI design so I sort of know what i'm talking about.

IN GENERAL - SD/Invoke/VD, all of them use "tech speak" in the interface. I understand why but this is simply not fit for normal humans!

As was already mentioned above.. What the hell is Cross-Attention Layer Optimization or Enable Flash Attention, or SDP Disable Memory Attention, or Sigma Churn, or Noise Seed Delta.. etc etc etc? I'm a fairly advanced user but should I even have access to that?

I'm certain these are the technically correct terms, i'm simply suggesting they're not appropriate for normal humans.

Certainly a pop up tip should be written where it makes sense but generally speaking very smart people like Vlad.. ESPECIALLY developers don't use natural language, even when it's entirely possible (Though some times it just isn't).

Case in point... "Denoising". What is this really? At it's core it's a sensitivity slider.. as in "Hey Mr regular human.. if you slide this to the right you're gonna get VERY different image.. if you slide it to the left.. the image will stay rougly the same.. i,e, less sensitve". Same with Config Scale, and so on.

I know, I know, this software is simply to complex to make it dummy proof.. but I do love the idea earlier about a simple mode. Wouldn't have to be a whole new fork.. just something that hides Sigma Churn, Attention Layer Optimization, that sort of thing.

I'm quite certain Vlad knows what those may be. Generally speaking, if you don't know what it does, or how it might have a ripple affect on other parameters.. you probably shouldn't be touching it. I mean we already have a basic setup, i'm simply suggesting we have a Beginner mode where all the superflous stuff goes away but can be re-enabled later BY A NORMAL HUMAN. Simply hide it from the interface and make the default install simple mode so people don't become overwhelmed at first glance.

A normal human is simply not going to go in and edit the Config.json file for example. Lots of us here know how to do that, and we think it's simple. But if VD is going to reach mass adoption.. and I certainly think it could.. it has to be more human friendly.

Hell... most people don't even know how to use Git, or install Python, etc etc. Most people are just not that tech-minded.

Please forgive if i'm over simplifying, i'm not even close to the intelligence and abilities of Vlad but would it be possible for example to create an .exe installer or is that problematic? My grandmother can run an msi installer. You get my point.

This interface is far more slick than A1111, but it could be much much better. In fact.. i might mock something up just to give you an idea of how that might look.

Ok enough out of me.. sorry for the long post.

Vlad, I would be glad to help brother. And thank you so much for your hard work.

[Woisek]

@VStudioAI
Hi colleague, I'm in the same tech as you (20+ years in webdesign and webprogramming) and for the most parts, I can agree with you.
But for the simplification, I see it a bit different.
It should not be the task of the developer to simplify the operation of a tool down to the smallest detail. That cannot end well. That would also only annoy all "power users".
Rather it should be that the user has the possibility to learn the tool. Tooltips for all or most of the functions is one way. But it would be better IMHO if there would be a detailed help page, possibly as a separate tab. The advantage would be that on the one hand you could create a "reference book" for the user and which can be updated continuously and on the other hand you could motivate the user to get as deep into the material as he wants.
SD is complex and like every tool you have to deal with it a little bit if you want to use it. I have to take 3D software like Maya or modo also as they are and also had only the necessary, sparse help that was available 🙂.
What I want to say, SD:Next should not become a "baby program" that does not allow detailed settings, just for the "simplicity".

[ForgetfulWasAria]

I don't want to over-promise but I'll try to contribute something useful.

[TheOnlyHolyMoly]

I had looked through comfyui the other day and came across their newby tutorial (https://comfyanonymous.github.io/ComfyUI_tutorial_vn/). I am not saying I am recommending such thing as imho I found it too childish, but on a different page I kind of liked the idea of taking people through the parameters with increasing complexity in a guided manner.

looping in @derspanier, good knowledge and sharp mind.

[vladmandic]

actually a really good point. and i don't think we should go into details of tutorial that covers every setting - that's what hints should be for.
but a good high level that covers - hey, this section of ui is about xxx and this section is about yyy.

[derspanier1]

@TheOnlyHolyMoly "sometimes" sharp mind :P
i saw this through coincidence, but for a relevant reason:
"Enable full-depth cuDNN benchmark feature" like many other things in the gui are, for someone like me that comes from the Art Department, secrets that feel they are unsolvable "what is it ?" "what does it" "do i need it?" "didnt vlad say something about 2070 are a bit shit and they benefit from this feature?" "oh i have a 2070" "DOES IT GIVE ME MORE PERFORMANCE?"

so yeah i am all for having some sort of tool tip. most of the time a single sentence is enough to explain a feature. or something that for example prusa slicer does, 3 different tiers, beginner, advanced, expert. most complex settings are hidden when using it in beginner mode.

ill follow the discussion and if i see something that actually is within my area of "expertise" i will jump in an help as much as possible

@vladmandic i know i havent done anything on the lora training, but that is actually a good thing because i completely switched my way of training to LYCORIS, because it is so much easier and faster also. ill see if i can type a short summary on the Kohya settings that i use for small datasets and larger datasets.

cheers everyone.

[vladmandic]

yes, that is a very good example why we need tips :)
btw, this setting used to be "enable cudnn benchmark" and it was pretty much necessary to "wake up" rtx 1xxx/2xxx gpus to be able to work in fp16. now i do that by default so you don't need this and this setting is now "full-depth" meaning let cudnn analyze all possible ways to compute something and pick best one. typically results in few % performance gain at the cost of a pretty significant delay at the start of first generate (while its doing analysis).

re: lyco training.
well, in my book lyco is just a network type within lora ecosystem, so its totally applicable.
and afaik, there are 4 different sub-types as well and i don't have a clue what's the difference: locon,loha,lokr,ia3

[derspanier1]

Thanks for the explanation. Yeah i have even less clue, when i read the scientific papers about Lora Training i seriously ask myself how humans are able to do stuff like that. All those formulas and that math makes me feel what i am....a lover of colors and shapes :P

ill open a ticket with an issue i am observing, its niche and no need to hurry, i can dance around the issue.

[vladmandic]

ok, so we all agree that we need better & more-detailed tooltips
we can start on that today - see html/locale_en.json and start filling hints and proposing label changes!

i've placed the copy in wiki so you can start with live editing right now without any special tools or thinking how to commit changes:
https://github.com/vladmandic/automatic/wiki/UI-JSON

regarding labels, i get what @VStudioAI is saying, but...in the main ui we should not change labels that have clear industry naming - for example, denoising/sampler/cfg scale/etc.

regarding simplified ui, i see some ideas how to simplify existing one. my question (not decision) is - is that really the path to go?
and i don't see anyone replying to my earlier idea? so lets consider:

top-down approach:

consider that existing ui is massively complex and creating simple mode out of it is likely equally complex task,
especially since gradio is anything but friendly to that effort.

yes, we could have a switch that throws css { display: "none" } to a lot of elements, but is that a solution or yet-another-bandaid?

and how far can we take gradio when it comes to enabling scale? can i make it truly multi-user? can it be used for cloud/hosted solutions? sure --listen works, but that is for single deployments only. etc.etc.
gradio ui has and always will have a 1:1 relationship with server it lives on.

also, any restyling proposal right now would be in conflict with development of new gradio ui which is currently under way.
once that is done, sure, we can talk how to further enhance it.

bottom-up approach:

clean-up gradio ui with clear labels/hints, but don't try to massively oversimplify it.

instead have second ui based on pure html/css/js - no gradio.
first version would have very few settings - only what we choose. and we can call them there anything we want since we don't have to cater to legacy. and we add only what is necessary for beginers.

and (possibly) stablestudio is a good starting point? this is pretty much it https://beta.dreamstudio.ai/generate

think of this analogy - photoshop is best, but for most online version of canva is more than enough :)
so we'd have gradio for advanced users and online ui that any beginner can use.

[TheOnlyHolyMoly]

sorry if asking dumb questions, but how do I get to edit view in that wiki?

[Aptronymist]

I'm very much in favor of both of those things actually.

I think getting the new gradio "UX" interface going should be done as a near-top priority, if possible including multi-user and cloud/hosted, sure, but the UI improvement and performance makes it a no-brainer and that would make an excellent base UI going forward.

After that's going well and bugs and kinks are worked out, I'm all for splitting it into two parts, the backend server that does the gruntwork and then a light and flexible interface, much like the two repos I showed you the other day on discord, where the guy not only improved the API's features on his fork but also created a front-end in unity that works just fine with SD.Next as is.

They're ultimately two separate things and should be separated IMNSHO. Being tied to gradio has benefits, sure, but it also clearly has downsides and its own bugs that seem to be a frequent problem.

Is a pure Python interface doable, since the entire rest of the app is already Python?
What about Electron or other similar existing frameworks?
I've seen Streamlit, and it seems to be designed for this kind of thing, is that an option? It's pure python already.

[vladmandic]

sorry if asking dumb questions, but how do I get to edit view in that wiki?

ah, it was restricted, my bad, should be editable now

[vladmandic]

Is a pure Python interface doable, since the entire rest of the app is already Python?
I've seen Streamlit, and it seems to be designed for this kind of thing, is that an option? It's pure python already.

yes, but that kind of defeats the point since all python interfaces at the end generate html/js/css.
streamlit is too different to be used instead of gradio and i don't want to have new interface based on similar tech, no matter how good it seems to be. especially since there is no reason why not use pure html/js/css to start with
.

What about Electron or other similar existing frameworks?

once we have html interface, that's just a question of packaging. so yes, that would be doable.
(and yes, again, if you use any python framework to generate html/js/css then this would NOT be possible since you need actualy python interpreter to run and generate those pages on the fly)

[VStudioAI]

Vlad,

All good points. Your reference to software like Blender and Photoshop are spot on. I'm an advanced Photoshop user, but you can see how it would be overwhelming to a new user. I guess I've forgotten how long its taken me to master that... I'm a daily user for nearly 20 years - and its far more complex than VD.

Oh. And I still don't know every single feature, now there's even more to know with the new Beta introducing AI features. VERY slick by the way if you haven't experienced that. (I'm talking about the native AI features, the stable diffusion plugin sucks).

Blender and its like are at least 3X more complicated than Photoshop.

I suppose I was thinking how to minimize the "Holy Crap" initial impression when a new user comes on board. Lose them there and they'll never adopt the software.. we just lost a user for life. Preventing that is the road to mass adoption.

Think on how we can transition simple Midjourney/Lexica users from a stupid simple interface to VD. Those people could be users but currently it is like going from kindergarten to college in one move. Of course some of those people aren't that serious about it and that's okay but mass adoption opens the doors to all sorts of possibilities.

Those type of sites are what we refer to in marketing speak as " The smell outside the bakery" it gets them in the door and interested in the tech. For those who are serious about it they're going to want something more and we need to be that something more. I would say that it almost never happens where somebody starts their AI journey with something like stable diffusion or VD.

They need to understand the basics before they up their game. They first need to be interested enough to want to know more. That is exactly the path I took to get here and i'm guessing it's true of most of you here.

Even Photoshop has a lite version; Photoshop Express. Google Adwords the same and I can think of countless others that provide a lighter, easier to use, less overwhelming version. To Vlads point though, there is no "Easy Mode" button, they are typically a completely different install. Theres probably a reason for that.

Love the idea of a pure CSS interface, that opens the door to entirely new possibilities. C'mon Vlad, you're wasting 6 hrs a night sleeping brother, step it up and get that done? Lol.. just kidding.

We've all been into the SD settings page, I dont know what a lot of those functions are - (which PROBABLY means I shouldnt be messing with them). Just a thought, could we in each section have a BASIC settings and ADVANCED that is hidden/collapsed by default?

Again the idea is to minimize that initial holy crap moment a new user might experience as well as to prevent them from flipping a switch that breaks the platform and then they leave in frustration. Regardless, an extensive help/tool tips is an essential need, even for us propellor-heads.

Of course, developers are the worst guys to task with that, they think every feature is essential. (Thats a programmer mentality, not specific to Vlad - no offense intended). They simply know too much to be objective, they KNOW how its "supposed" to work.

Put on the glasses of your average Joe though, he doesnt understand that if i check this box here, it breaks that over there. Your average user has no experience with Beta testing. (They are typically used to working with mature ready to run software).

This is almost never true with Photoshop as an example but of course its much more mature software. I suppose thats exactly what we're attempting to do here though isn't it?

QUESTION: To that point, Vlad can you point me to the best, most up to date resources that explain in detail what every function is/does? I can start working through the settings categories and make an attempt at writing some simple explainers.

I'm up for the challenge. I can gain a deeper understanding all while contibuting to this astonishing software.

Last thought, let's not forget everybody the million and one things that Vlad has done right so far. It's easy to focus on just what's wrong. Speaking entirely for myself, I am freaking blown away with what he has built here.

Well done Vlad!

[Aptronymist]

I agree with you for the most part, but I'd say that would be a lot easier to do after the new gradio UI is complete and put into use, that would likely make creating an "easy mode" a lot simpler, it seems much more modular with UI components, and built-in theming. Perhaps it could come down to just having a 2nd .html/css/.js package that is activated with a flag?

[vladmandic]

Even Photoshop has a lite version; Photoshop Express. Google Adwords the same and I can think of countless others that provide a lighter, easier to use, less overwhelming version. To Vlads point though, there is no "Easy Mode" button, they are typically a completely different install. Theres probably a reason for that.

that's exactly what i'm referring to.
but my goal is not only to have an alternative simple mode, its also to enable workflows which are not possible with gradio as gradio is tightly coupled with server it runs on. you cannot use gradio ui to control some other server. you cannot have separate ui and server (other than --share which is not what i mean), etc. having a simple html/css ui would also unlock possibilities where i can have a server farm and full multi user environment where each user doesn't even know where his jobs are being executed - he doesn't care. there are tons of online services doing just that, why not enable it out-of-the-box.

We've all been into the SD settings page, I dont know what a lot of those functions are - (which PROBABLY means I shouldnt be messing with them). Just a thought, could we in each section have a BASIC settings and ADVANCED that is hidden/collapsed by default?

ahhhh. would be nice, but...settings page is auto-generated from all possible settings, there is no distinction between them and there is no special rendering for any of them.

and even if i introduce a basic/advanced flag and go over built-in settings, any extension that has its settings will go where? basic or advanced? i cannot decide that. so it would quickly deteriorate up to a point, is it worth it?

and which one is advanced? i'd argue that things like changing cross-attention method is advanced since its not easy to explain to users what that is. but its one of the first things to direct users to when troubleshooting anything. so users would end up in advanced view in no time.

QUESTION: To that point, Vlad can you point me to the best, most up to date resources that explain in detail what every function is/does? I can start working through the settings categories and make an attempt at writing some simple explainers.

to my knowledge, no such resource. that's why ask for this community effort to fill all the hints. if there was a single source, i'd just fill everything right now. but its a question of searching through issues/prs/discussions/wikis here and original a1111.

and another problem - sd is a community effort and a lot of settings are result of someone contributing. for example, "hey, i have a new method for xxx that works really cool and you can tweak every math parameter". for example, i love unipc, but do i know what are exact differences between bh1 and bh2 variants? no clue. i can probably take a look at the code and deduct that after some sturdying if i needed to, but it doesn't mean i know every setting nor that every setting is document anywhere.

moving forward, i can ask anyone contributing new stuff to fill labels/hints nicely. but i cannot trace every contribution done during the past year.

[VStudioAI]

Vlad, when working on the tool tips, modifying thr eson file, how can we reference the source info we use to write those tool tips? So any one who wants to can eyeball that?

[vladmandic]

Hmmm...I just created a separate wiki page you can use to note that kinda stuff: https://github.com/vladmandic/automatic/wiki/Reference-Sources

[TheOnlyHolyMoly]

quick question @vladmandic : What information should we actually capture under localization?

[vladmandic]

Basically, suggestions for changing actual labels in UI.
If I agree with those, I'll update UI itself and bring localization back to empty. End goal for that field is so it's used for UI localizations to different languages.

[TheOnlyHolyMoly]

Was just reviewing / filling in some wiki content, trying to make this a daily excercise.

Noticed this in Text2Image Workflow
{"id":"","label":"Denoising strength","localized":"","hint":"Determines how little respect the algorithm should have for image's content. At 0, nothing will change, and at 1 you'll get an unrelated image. With values below 1.0, processing will take less steps than the Sampling Steps slider specifies"},

The phrase "At 0, nothing will change" is correct for I2I but not quite fitting for T2I imho..., I was then looking for the label in I2I and it wasnt there..?

[vladmandic]

you mean label is is not in i2i section? i only list label first time it appears - if i list every duplicate label, entire file would be 4x bigger for no reason.

[brunogcar]

Denoising strength on T2I would be for Hires fix and its description is correct cos from my understanding it works as I2I

[TheOnlyHolyMoly]

my bad, had a wrong thought. Should be sleeping a bit more I guess, sorry for the confusion

[vladmandic]

making some nice progress updating https://github.com/vladmandic/automatic/wiki/UI-JSON
i've incorporated first set of changes and wrote a short validator
you can see where hints are missing and also where labels are considered too long and should be broken down into shorter label + hint

cli/validate-locale.py html/locale_en.json

Section: icons                entries=11 localized=0 long=0 hints=11 missing=0
Section: prompts              entries=2 localized=0 long=0 hints=2 missing=0
Section: tabs                 entries=6 localized=0 long=0 hints=6 missing=0
Section: action panel         entries=6 localized=0 long=0 hints=6 missing=0
Section: extra networks       entries=3 localized=0 long=0 hints=3 missing=0
Section: gallery buttons      entries=10 localized=0 long=0 hints=10 missing=0
Section: extensions           entries=11 localized=0 long=0 hints=11 missing=0
Section: txt2img tab          entries=24 localized=0 long=0 hints=23 missing=1
Section: process tab          entries=15 localized=0 long=0 hints=10 missing=5
Section: settings menu        entries=7 localized=0 long=0 hints=0 missing=7
Section: settings sections    entries=20 localized=0 long=0 hints=0 missing=20
Section: img2img tabs         entries=6 localized=0 long=0 hints=0 missing=6
Section: img2img tab          entries=21 localized=0 long=0 hints=8 missing=13
Section: train tabs           entries=11 localized=0 long=0 hints=0 missing=11
Section: train tab            entries=74 localized=0 long=0 hints=11 missing=63
Section: settings             entries=248 localized=0 long=45 hints=20 missing=228
Section: scripts              entries=54 localized=0 long=2 hints=8 missing=46

[brknsoul]

I've noticed the locale_en.json file updated with new hints, but I don't seem to be seeing any tooltips when hovering over UI elements.
Is this just the groundwork being laid before implementing the tooltip system?

(bda28dc, win10, chrome)

[vladmandic]

fixed. i tried some js loading optimization and as a result hints were being applied before ui even initialized.

[nCoderGit]

Regarding the question if there's some single resource... Maybe this is helpful?
https://www.sdcompendium.com

I bookmarked the site two months ago, as it does cover quite a lot of info about SD. Well, and some other AI-related stuff like LLMs, links to some research papers etc.
They even have a weekly and monthly news section about the latest development. The last post in that section was on April 28th, though.

I have no clue how accurate or up to date the site actually is. But it looks like an awesome resource and should at least provide a few infos for tooltips and stuff.

[nCoderGit]

More info on the various settings would be awesome, and I think @VStudioAI has some great points.
But I think the focus shouldn't be too much on complete beginners. SD.Next doesn't have to be the "first contact" to be a popular distro.

While UX is an important part as a bad user experience can scare first-time users off for good, there will always be some apps that just don't work for you, whether you're part of the target group or not.

I think I would take an approach where every UI block (e.g. seed + seed variation) has their own question icon. When clicked it will show a lightbox with a quick explanation what it does - if possible even with a screenshots to visualize the impact this setting can make and a link to the wiki. Kinda like in a game when you're introduced to a new game mechanic and an info card pops up.
Personally, I would limit the usual mouseover tooltips to the settings tab (and UI blocks that don't have a question icon dialog yet) only, as they tend to pop up by accident on controls that you pass over frequently. But that's completely subjective.

I started off with InvokeAI in late 2022. It had an easy interface and was a great "first contact" but it didn't take long until it felt a bit too limiting. So I switched to 1111 and used that for a few months.
About three weeks in when auto went awol for the second time and people were afraid the project was dead, I saw a reddit post mentioning vlad's fork so I gave it a try... This whole project was like the next step up. A bit more "mature" somehow with the whole UI theme stuff, planned UI collab with Anapnoe, more settings etc, and the transition couldn't have been easier because the whole layout was so familiar. Also, SD.Next immediately felt like an active, evolving, awesomely managed project with a capable and open-minded maintainer. Imo this is what this repo can really emphasize.

Well, and maybe something to kickstart first-time contributors. Like a first-timer-friendly label for easier issues that don't require much coding knowledge or some kind of list what exactly is needed and what you can actually do right now to contribute or how?

[vladmandic]

IMO (and this is IMO, not set-in-stone), having additional icon next to each control would be:
a) a lot of coding as each icon has to be manually placed
b) create extremely busy ui, no matter how tiny the icon is

tooltips as-is depend on how "title" tag is executed by browser - some are more and some are less agressive.

i could replace that with a custom js handler, but remember that would have to get registered and executed for every component, i'm worried about load on browser itself - gradio is already slow, this would make it even slower. maybe its worth it. i'll try it out (placing idea in my backlog)

Well, and maybe something to kickstart first-time contributors. Like a first-timer-friendly label for easier issues that don't require much coding knowledge or some kind of list what exactly is needed and what you can actually do right now to contribute or how?

thats a good idea. lets kick it around for a bit - what would be an example of a good first-time item? then we can build on that.

[nCoderGit]

I have no experience with gradio, but can't you just add a "label for=..." tag that is created along with the slider or whatever, and hide/show them via css by adding/removing a "show-hints" class on a parent element? A custom JS handler sounds a bit overkill to me 🤔

Well, and maybe something to kickstart first-time contributors. Like a first-timer-friendly label for easier issues that don't require much coding knowledge or some kind of list what exactly is needed and what you can actually do right now to contribute or how?

thats a good idea. lets kick it around for a bit - what would be an example of a good first-time item? then we can build on that.

Most stuff related to documentation and localization, really. Anything that is unlikely to break something and allows you to jump in without (too) much background knowledge, just to get a foot in the door on the whole Github thing. And if it's just something like this:

---

I added a new sampler (UniPC) and could use some help with documentation. Any help appreciated, so feel free to contribute whatever you can.

• a short entry for the wiki, describing what it is and what it is good at on a basic level
• one or two XYZ grids (steps & cfg scale) to showcase the output for a simple example prompt
• a mouse-over tooltip that is shown to the user (easy language)
• a more technical explanation for the glossary (bh1 vs bh2, info on parameters)

---

I don't know what it means to be a product owner or maintainer, how practical it would be for this project or if it would just cause too much overhead.
But I'm sure even just a simple "good first issue" label with an accessible task like this would lower the hurdles. I think there are quite a lot of hobbyist programmers and enthusiasts who would love to contribute but feel like it's all out of reach.

[vladmandic]

I have no experience with gradio, but can't you just add a "label for=..." tag that is created along with the slider or whatever, and hide/show them via css by adding/removing a "show-hints" class on a parent element? A custom JS handler sounds a bit overkill to me 🤔

labels are used for, well, labels. if label is replaced with a (much longer) hint, it would cause entire ui to re-layout due to overflows, etc.
right now hints are displayed using standard html title attribute an how title is displayed is up to browser - there is no styling for titles.

[Aptronymist]

I'm getting some documentation done for the cli utilities written (especially train.py), with use examples, assuming I can keep on track, I'll submit those today.

[vladmandic]

nice!

[vladmandic]

i've just completed update to https://github.com/vladmandic/automatic/wiki/UI-JSON - lets do a push to add more hints?

here are the current per-section stats:

Section: icons                entries=11 localized=0 long=0 hints=11 missing=0
Section: prompts              entries=2 localized=0 long=0 hints=2 missing=0
Section: tabs                 entries=6 localized=0 long=0 hints=6 missing=0
Section: action panel         entries=6 localized=0 long=0 hints=6 missing=0
Section: extra networks       entries=3 localized=0 long=0 hints=3 missing=0
Section: gallery buttons      entries=10 localized=0 long=0 hints=10 missing=0
Section: extensions           entries=11 localized=0 long=0 hints=11 missing=0
Section: txt2img tab          entries=24 localized=0 long=0 hints=24 missing=0
Section: process tab          entries=15 localized=0 long=0 hints=15 missing=0
Section: settings menu        entries=7 localized=0 long=0 hints=7 missing=0
Section: settings sections    entries=20 localized=0 long=0 hints=0 missing=20
Section: img2img tabs         entries=6 localized=0 long=0 hints=0 missing=6
Section: img2img tab          entries=21 localized=0 long=0 hints=8 missing=13
Section: train tabs           entries=11 localized=0 long=0 hints=0 missing=11
Section: train tab            entries=74 localized=0 long=0 hints=11 missing=63
Section: settings             entries=243 localized=0 long=0 hints=54 missing=189
Section: scripts              entries=54 localized=0 long=0 hints=8 missing=46