Porting any of Fooocus-MRE features into original code base? #689
Replies: 10 comments 55 replies
-
|
1、Preset switching, anime with real and much more，On the UI interface |
Beta Was this translation helpful? Give feedback.
-
|
@MoonRide303 YES right now we have under fooous separate executables for anime and realistic presets ... that should be under fooocus itself option where we could choose preset next to "genetare" button (some list after click on it ? - but must be made with sense ) plus custom presets that we could add. |
Beta Was this translation helpful? Give feedback.
-
|
Clip skip will be somewhat complicated to implement because we use same vector for base and refiner ( even when refiner is 1.5, and this is one reason why we use 1.5 dreamsharper rather than 1.5 counterfeit as refiner for Fooocus anime, cus dreamsharper works better for final hidden layer ( and actually dreamsharper 8 is still marginally better than counterfeit for refining images even with clip skip -2 in my tests. Another method is loading refiner's clip to GPU but this is not acceptable in my opinion for speed and smoothness. A more meaningful thing that should be considered before clip skip is changing vae if refiner is 1.5 (but most current 1.5 models has vae baked so .. ( but the baked vae in 1.5 counterfeit is pretty bad and this could be one reason to still have it Also keep in mind that the goal of Fooocus is to explore new mediums of thought and expand the imaginative powers of the human species. This is the key that will determine whether the project Fooocus will be more and more popular, or just die like many other previous projects. Reconsider features if some features will limit people’s willingness to consider new ideas and preventing people from trying novel prompting and typing new descriptions. Most users of Fooocus are normal people who do not write reviews about software, just like that I never write a review after I buy a bicycle or a laptop. Some story-telling or documentary film makers (or some social media video makers), magazine editors, or say some blog writers are using Fooocus because they need images and they find this software, and they do not have Github account and their voices will hardly reach to you. The most difficult part is to know their needs, based on “ambient” feedbacks. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I understand the goal and philosophy behind Fooocus, and that any contributions should stay aligned to that. I had a bit different target user group in case of MRE, but I tried to stick to the same ground rules. I also understand most of the users might be silent (no GitHub account, etc.), but listening to some of them might be still better option than listening to none - so I used feedback I had available, and filtered it through my own common sense. Not perfect (as I am pretty biased myself, far from being typical human species representative), but allows to keep feedback in the development loop in relatively easy way. Better solution would be probably working with experienced UX team, and letting them do the proper UX research - but that might be overkill for relatively small project like Fooocus :). As for adding / porting specific features, we can talk about them in rounds - and nice to see FreeU already added, as well as support for embeddings :). As for other features:
|
Beta Was this translation helpful? Give feedback.
-
|
@MoonRide303 @lllyasviel It is very useful for product poster designers. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a 'silent' user, but I appreciate the effort very much.+1111111 |
Beta Was this translation helpful? Give feedback.
-
|
It'd be great if we introduced standardized resolutions like 1920x1080. I found another post here with a config change that allowed it and worked great but it gets overwritten with the original resolutions. |
Beta Was this translation helpful? Give feedback.
-
|
My top 4 must-haves are:
|
Beta Was this translation helpful? Give feedback.
-
|
including that already realistic and anime ;) |
Beta Was this translation helpful? Give feedback.
-
|
Wildcards! I like being able to type CustomPlaces and automatically grab from my list of places and so on. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@Pdonor Added in v2.1.687. |
Beta Was this translation helpful? Give feedback.
-
|
@lllyasviel Could we get back to using seeded random for picking wildcards, instead of simple iterating? Not critical, but that change causes prompts using wildcards to yield different results in original, and MRE / Ruined. |
Beta Was this translation helpful? Give feedback.
-
|
previous method sometimes give me same colors in a batch of 2. The change is 1/n where n is length of wild card. |
Beta Was this translation helpful? Give feedback.
-
|
@lllyasviel That's how random functions should work: it allows duplicated choices in the series (like flipping coin twice with same result), and distribution will be going flat for larger number of samples. As long as same seed yield same result it's okay, and your way will also cover all the choices - but for longer wildcards list it won't properly distribute choices over whole population. Imaging long list of alphabetically sorted artists, let's say 1000 of them. If you'd generate 10 images using |
Beta Was this translation helpful? Give feedback.
-
|
simple iterating is good for batch prompt list as some requested. maybe modify a copy of wildcards for "batch prompts" |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, we hear your voice and added notes to developer tools |
Beta Was this translation helpful? Give feedback.
-
|
You should try some prompts with arms and legs. "a woman sitting on grass", seed 0, standard 1152x896 all compostions are kind of acceptable in my opinion
"a woman sitting on grass", seed 0, non-standard resolution 1280x720, note that SDXL is not trained on 1280x720 much more cropped contents, or back to viewer, or distortion
|
Beta Was this translation helpful? Give feedback.
-
|
@lllyasviel Both sets stay within "acceptable" quality range for me, so I probably just allow it (like in MRE). I am also aware that using resolutions from the officially supported list will give best results, so pre-defined resolution list should stay as it is. PS Another reason for allowing custom resolutions is support for SD base models, which give best results around 512x512. But support for SD and/or hybrid SD / SDXL workflows (SD base -> SDXL base + SDXL refiner, SD base -> SDXL refiner, etc.) is a bit broader topic, so we can leave if for another time (and using proper lower initial SD resolution could be done automatically in the background, if SDXL models would be used at later stages). |
Beta Was this translation helpful? Give feedback.
-
|
do note that the compositions from 1280x720 is much more "cropped" like, feeling that they are images cropped from a bigger image. Also, if you allow custom resolutions, many non-geeks will really use more "common" numbers like 1000x1000 or 800x800, which makes results significantly worse in my tests. |
Beta Was this translation helpful? Give feedback.
-
|
@lllyasviel Most casual users will probably just pick one of the predefined resolutions. And for the custom resolutions we could round it to nearest 16 / 32 / 64 px - it should solve 1000x1000 problem. |
Beta Was this translation helpful? Give feedback.
-
|
Also I need to make sure that I am talking to a guy who knows how positional encoding works, otherwise I am wasting my time. Basically, when a number, say “x”, is feed in to SDXL, the real vectors feed to model is not “x”. It is "f(x)" like f(x)=torch.tensor([sin(x*1), sin(x*2), sin(x*4), sin(x*8), sin(x*16), sin(x*32), sin(x*64), sin(x*128), sin(x*256), sin(x*512)]) so the difference between 1024 and 1023 is not 1/1024. f(1024) and f(1023) are almostly 100% different. |
Beta Was this translation helpful? Give feedback.
-
|
See also |
Beta Was this translation helpful? Give feedback.
-
About compact style selectionWe are aware that some people like to have something like this:
This only needs to modify one line of code and we clearly have tried it. The side effect is that new users are significantly less likely to try new styles. In an user study we did at the scale of 7 individuals before the Fooocus release, for current Fooocus UI (tested with 4 individuals, all first-time users), all 4 users try at least one styles and see what happens (1 user tried two styles and 1 user tried a lot). However, if the UI became like the above screenshot (tested with another 3 individuals, all first-time users), all 3 users ignore this selection (although 2 users still asked what is this, but 0 tried to change it). Although this design has some advantages, like easier removal of styles, the strong side effect prevents us from using it. Also, you can search page with Ctrl+F. Besides, loading style to prompt is not possible because Fooocus use neural network features to merge styles, rather than merging the texts. |
Beta Was this translation helpful? Give feedback.
-
|
One possible explanation of this phenomenon (from my understanding) is that: In the current UI, if a new user mistakenly turned a style off, one can click again at the exactly same position to turn that style on, this makes them “brave” enough to try edit it. However, in the screenshot, if a style is removed, user has to remember the name of removed style to restore it (not sure if Ctrl+Z works but this does not seem reliable). So users are afraid of messing things and they are less likely to edit it. |
Beta Was this translation helpful? Give feedback.
-
|
Compact style list with filtering allows you to quickly see all styles you might be interested in, like that: Which is (IMO) more convenient than searching for desired style using CTRL+F from browser. But that's just single and obviously biased user perspective ^^. Merging the styles should work exactly the same way as before - it's only about how to present style selection in the UI. As for the test on first-timers - question is what % of the first-time users should be assumed for that kind of tests. On one hand we want to have UI that's as much approachable as possible for new users, on the other - it should also be comfortable to use for people who already know the basics. Sadly those are sometimes contradictory goals, and it might be hard to balance it properly. It might be worth to perform tests on multiple groups with different levels of experience with computer graphics / generative art / Fooocus (first-timers, little experience, moderate experience, experts), and them aim for maximizing satisfaction of whole population (not just single group). |
Beta Was this translation helpful? Give feedback.
-
|
My suggestion is, why not show both? A search box plus the original. |
Beta Was this translation helpful? Give feedback.
-
About Custom Styleyes. |
Beta Was this translation helpful? Give feedback.
-
|
i wll consider turn it off if in any example it leads to side effects. |
Beta Was this translation helpful? Give feedback.
-
|
also this is your prompt "perfect sportcar" seed 1 empty negative current negative seems to help remove SDXL's blurry background problem in most other cases effects are minor and relative random but it has a trend to help adress some Xl problems |
Beta Was this translation helpful? Give feedback.
-
|
@lllyasviel My basic test case - "modern sports car", seed 0 (in v2.1.693). With current defaults (negative prompt "low quality, bad hands, bad eyes, cropped, missing fingers, extra digit") I get something strange on the mask, road and the background are messed up: vs clean negative prompt: |
Beta Was this translation helpful? Give feedback.
-
|
I do not think it really make sense to look too much at those seed-specific image details, but in most cases it can prevent background blur to some extent - that is already strong enough reason to have it |
Beta Was this translation helpful? Give feedback.
-
|
also I forget to mention that in Fooocus, the negative prompt and all styles' negative texts are encoded by CLIP independently so that their texts do not join each other - whether to use each negative prompts' tokens depends on SDXL attention layer's softmax weight. so you do not need to worry about these texts are joining styles' negatives. If the model does not need it, it will just ignore it by using zeros in softmax. |
Beta Was this translation helpful? Give feedback.
-
|
Glad to express my opinion here, I think "Save Metadata in Image" and "load prompt" are great features,Hope to join fooocus。Thanks！ |
Beta Was this translation helpful? Give feedback.
-
|
ouchhh ! i discover lately about even Fooocus (1 week now and really enjoying it) and the MRE one which seems a bit more dev adapted, i think about 2 kind generous persons able to get the best parts of their own engines: the comfy inside, which has some of the needed base modules here added, as metadata inside .png and the way easy to get a whole workflow in one .png deposit is so crazy cool !
Also is the ruinedFooocus too ! each has their goodies, but well philosophies too..
Cheers the devs ! MoonRide303 and lllyasviel and runew0lf too... |
Beta Was this translation helpful? Give feedback.
-
|
<3 |
Beta Was this translation helpful? Give feedback.
-
|
there is a fabulous thing with ComfyUI: it can replace the whole workflow just by putting an image on screen !
An other starred option is to put the styles from hidden/open tabs, as MRE integrated ! (yyeahahh) and "artstyles", those are really in categories (and then no way to put the MRE or artstyle on every button- this would shorten the long search for the lost styles
|
Beta Was this translation helpful? Give feedback.
-
|
@runew0lf May be as i review your Version as RuinedFooocus, you have integrated many of those asks ? - sshooww , an other foocus to install, even easy... but once more to install.
|
Beta Was this translation helpful? Give feedback.
-
|
Its a lot different nowadays, each of us had our own vision of where it should be going! |
Beta Was this translation helpful? Give feedback.
-
I was maintaining Fooocus-MRE for some time, and it got some fans (it was most popular fork until I archived the repo - over 500 stars), but having to re-write large parts of my code every time original Fooocus code base got bigger changes was too much for me - I was wasting a lot of my time on un-breaking things, instead of creating real value added. I guess that's the lesson about forking for me.
Most of the features I was missing in vanilla / original (like img2img, control over sampler / scheduler settings, or using recent ComfyUI backend) are already available in Fooocus v2.1 - and that's another reason I don't feel maintaining separate fork is that much needed.
I can still occasionally contribute to Fooocus, but I don't like wasting my time - so I'd rather contribute to original code base here, to avoid having to re-write same features multiple times.
So my question is: which - if any - of the Fooocus-MRE features could be a good fit for Fooocus? Some of those are already available in v2.1, but some are still available only in MRE (like CLIP Skip control, FreeU, and also small quality of life improvements - like support for JPEG, hotkey for starting generation, etc.). @lllyasviel please take a look on that list, and let me know if you'd like to see any of those features to be added into original code base - I can prepare pull requests adjusted to current Fooocus code base, if so.
Beta Was this translation helpful? Give feedback.
All reactions