MarblingTIXL - v2.0

31. Jan 2024

v2.0 ist keine bessere Version von MarblingTIXL. Einfach anders. v1.0 funktioniert weiterhin gut.

Durch die Änderungen in kohya stellte sich heraus, dass die Art, wie ich die erste Version dieses TI erstellt habe, nicht mehr funktioniert oder zumindest nichts wirklich Nützliches produziert.

Danke an @raken, der mich darauf hingewiesen hat.

Ich glaube weiterhin, dass SDXL Embeddings großes Potenzial haben, daher habe ich eine frische kohya_ss Installation (v22.6.0 zum Zeitpunkt des Schreibens) gemacht und mich durch verschiedene Parameter/Einstellungen gearbeitet, bis ich eine Kombination gefunden habe, die einem nah verwandt ist zum originalen MarblingTIXL.

Falls jemand Interesse an SDXL TIs hat (und ich weiß, dass da draußen mindestens 2 von euch sind!), habe ich meine Trainingsdaten und die kohya_ss Konfigurations-JSON beigefügt. Möglicherweise auch einige Notizen, falls mir etwas Nützliches einfällt.

Positiv ist, dass dieses TI schneller trainiert wurde... nachteilig ist, dass es nicht so konsistent ist wie das ältere TI. Oder vielleicht habe ich noch nicht genug damit experimentiert. Wer kann das bei dieser cutting edge Technologie schon genau sagen?!

Wenn jemand Fragen, Beobachtungen, Meinungen oder Weisheiten hat, bitte unten kommentieren. Es gibt momentan kaum verlässliche Informationen darüber, wie man TI-Stile erstellt... Ich habe viele widersprüchliche Ansichten gelesen/gesehen. Es ist aber machbar, und ich denke, es gibt Raum für bessere TIs als das, was ich bisher geschafft habe.

Wettbewerb für LoRAs? Nein, nicht wirklich - LoRAs fügen einem Checkpoint etwas hinzu, während TIs das nutzen, was schon im Checkpoint steckt. Soweit ich das verstanden habe, ermöglichen TIs den Zugang zu Bereichen im Möglichkeitsraum eines Checkpoints, die sonst schwer konsistent erreichbar sind. Also sind TIs und LoRAs verschieden für unterschiedliche Zwecke... die man zusammen verwenden kann. Also sind alle glücklich :-)

Es gibt technische Fachartikel dazu (was ein TI ist, wie man einen trainiert, Infos zu Text-Encodern etc.), aber ich bin meist schon nach der Hälfte der ersten Seite überfragt :-(

Soweit ich weiß, trainiert kohya_ss nur den ersten TE (Text Encoder) in SDXL. Das ist der von SD v1.x, der eigentlich in auto1111 SDXL Generation funktionieren sollte, aber nicht tut. (Einige berichten, dass SD v1.x TIs in Comfy funktionieren, aber die Erfahrung scheint uneinheitlich.) Den zweiten TE trainiert kohya_ss meines Wissens nach nicht (das ist der von SD v2.x). Oder vielleicht ist es eine Duplikation von TE1?

Ich habe es mit OneTrainer versucht (der Optionen für beide TEs hat), hatte aber keinen Erfolg bei einigen wenigen Versuchen, also bleibe ich vorerst bei kohya_ss.

Als Referenz verwende ich eine RTX-3060 mit 12GB in einem ordentlichen PC. Aktuelle kohya_ss Läufe übersteigen knapp die 12GB (+ weitere 6GB, wenn ich Samples generiere), daher ist es ressourcenintensiver als ein LoRA-Training. Ich dachte, TIs benötigen weniger (oder gleich viel) Ressourcen, deshalb bin ich etwas überrascht. Vielleicht wird bei TIs noch nicht stark optimiert? Noch nicht :-)

Das TI hier wurde trainiert auf:

sd_xl_base_1.0_0.9vae.safetensors

Die Showcase-Bilder wurden erzeugt mit:

crystalClearXL_ccxl.safetensors [0b76532e03]

Das heißt, ein TI, der auf dem Vanilla-Base trainiert wurde, sollte mit anderen Checkpoints funktionieren.

Bilder werden in a1111 v1.7.0 erzeugt, Hires.fix wurde verwendet, keine weiteren Adjustments.

Die zusätzliche Galerie unten zeigt Vergleichsbilder ohne/mit, damit man sehen kann, wie das TI einige ausgewählte Prompts beeinflusst. Label „xlmrblnh36-500“ bedeutet ohne, „xlmrblng36-500“ mit TI. Ich habe es so gemacht, damit die zwei Prompts so ähnlich wie möglich bleiben.

Falls Interesse besteht: Das Trainingsdaten-Zip enthält alle gespeicherten TIs in 25-Schritt (*4 Gradient Accumulation = 100 normale Schritte) Intervallen.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

HINWEIS: Es gibt ein Problem mit SDXL in der aktuellen Version des automatic1111 WebUI (v1.6.0). Wenn man einen Refiner-Checkpoint benutzt, vergisst WebUI alle Embeddings, bis man einen anderen Checkpoint lädt und dann den ursprünglichen wieder oder WebUI neu startet. Ich habe das den Entwicklern gemeldet:

https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/13117

Und es wurde als Bug bestätigt.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

***ZUSAMMENFASSUNG***

Dieses Embedding wendet eine surreale/fantastische Ästhetik inspiriert von Vintage-Marmorpapier-Mustern an. Der Effekt variiert von gering bis extrem, je nachdem, wie „nah“ dein Prompt bereits an dieser Ästhetik ist.

Das Training für dieses TI beinhaltete keine Künstlerwerke oder Tags.

Kopiere die Generierungsdaten eines Showcase-Bildes und passe sie nach Geschmack an, oder starte mit einem Prompt wie diesem, der mit jedem Seed ein gutes Ergebnis liefern sollte:

preisgekröntes Art Nouveau xlmrblng15-1300, analog realistische Farbfoto einer japanischen Meerjungfrau sitzend auf einem Felsen inmitten brechender Wellen, sehr detailliert

Checkpoint: crystalClearXL_ccxl.safetensors [0b76532e03]

Sampler: DPM++ 2M Karras

Schritte: 40

CFG: 7

Höhe=Breite=1024

Dann variiere die Begriffe nach Belieben. Versuche, zwischen 3 und 5 Wörter vor „xlmrblng15-1300“ zu halten.

Die einfachsten Prompts, die einen Versuch wert sind, sind solche:

cybernetische Nonne, xlmrblng15-1300

fantasievoller Winterlandschaft, xlmrblng15-1300

Aber in der Regel braucht man mehr Worte für interessante Ergebnisse.

Nach viel Experimentieren fand ich die besten Ergebnisse mit Prompts zwischen 30 und 45 Tokens, ohne negative Prompts.

Ich habe einige Vorher/Nachher Bildpaare in den zusätzlichen Galerien unten bereitgestellt.

xlmrblnh15 = ohne dieses TI

xlmrblng15 = mit diesem TI

Wie du sehen wirst, tut dieses TI mehr als nur marmorierte Papiermuster hinzufügen :-)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

***WEITERE DETAILS & TRAININGSINFOS***

Dies ist ein TI (Textual Inversion) Embedding, das deine Bildgenerierungen anpasst, indem es marmorierte Papiermuster hinzufügt oder Dinge je nach Prompt in Richtung marmoriertem Papier anpasst. Durch die Funktionsweise des SDXL-Systems ist der Effekt bei längeren/komplexeren Prompts oft strukturell statt einfach.

Es ist der SDXL-Nachfolger meines MarblingTI für SD v1.5:

https://civitai.com/models/69768/marblingti

Wegen der vielen Änderungen in SDXL hatte ich viele Fehlstarts (20+), aber ich denke, dieses neue TI ist nützlicher als das alte... zumindest für die surrealen/illustrativen Sachen, die ich gern erstelle.

Der Wechsel von automatic1111 zu kohya_ss fürs Training war kein leichter Prozess. Mehr dazu weiter unten.

Das TI besteht aus 8 Vektoren (d.h. es benötigt 8 Tokens deines Prompts). Es ist überpowert für kurze/einfache Prompts. Das ist gewollt - ich habe einige subtilere Versionen gemacht, aber die waren für die längeren/komplexeren Prompts mit SDXL nicht hilfreich. Nach meinem Verständnis von Stable Diffusion sollten 4 Vektoren ausreichen, aber bei 4 Vektoren bekam ich keine konsistenten Ergebnisse.

Das Quellmaterial besteht aus Scans/Fotos von Vintage-Marmorpapier, die zu mehreren Vorläufer-TIs gemacht wurden, die dann genutzt wurden, um Hybridbilder zu erstellen, die die Eingaben für dieses TI wurden.

Für Prompts solltest du 3 bis 5 Tokens voranstellen.

z.B.

Porträt einer Frau, xlmrblng15-1300

statt

xlmrblng15-1300, Porträt einer Frau

Wenn du einen kurzen/einfachen Prompt benutzt, bekommst du wahrscheinlich nur ein Vintage-Marmorpapier-Muster. Okay, aber langweilig. Außerdem kann das TI bei kurzen Prompts einen leichten Grünschleier in Bildern verursachen. Warum, weiß ich nicht; die Trainingsbilder haben keinen solchen Farbton.

Gewichtung/Fokus: von 0,81 bis 1,33 je nach Prompt verwendbar. Ich finde, konsistentere Ergebnisse bekomme ich, wenn ich das TI-Token verschiebe statt Gewichtungen zu nutzen.

Alle Bildgenerierungen für dieses TI erfolgten in automatic1111 webui v1.6.0. Die einzige Nicht-Bordmittel-Erweiterung, die ich nutze, ist Dynamic Prompts (installiert via Extensions Tab). Ich habe weder Hires.fix noch In-/Outpainting, Detailiers oder andere TIs oder LoRAs benutzt, damit man an den Showcase-/Galeriebildern sehen kann, ob sich ein Versuch mit diesem TI lohnt.

https://github.com/AUTOMATIC1111/stable-diffusion-webui

https://github.com/adieyal/sd-dynamic-prompts

Ich nutze meist den CrystalClearXL:

https://civitai.com/models/122822?modelVersionId=133832

oder SDXL FaeTastic

https://civitai.com/models/129681?modelVersionId=157988

Checkpoints für SDXL Bildgenerierung, aber dieses TI funktioniert mit jedem SDXL Checkpoint, den ich probiert habe.

Wegen der Funktionsweise von Prompts, wenn du die Effekte mit/ohne TI sehen willst, ändere nur einen Buchstaben.

z.B.

MIT: cybernetische Nonne, xlmrblng15-1300

OHNE: cybernetische Nonne, xlmrblnh15-1300

Du kannst das Trigger-Wort ändern, indem du die heruntergeladene Safetensors-Datei umbenennst. PROBLEM: Wenn du das Trigger in ein Wort änderst, das SDXL „kennt“, wie marbling, erhältst du unerwartete Ergebnisse. Selbst wenn du Wörter zusammenfügst wie newmarbling, erkennt SDXL „new“ und „marbling“ und macht, ähm, Dinge mit denen statt mit dem TI.

Der Name, den ich verwendet habe, sagt mir, dass es ein SDXL TI ist, es geht um marbling (mrblng) und es ist die 1300 Schritt Iteration der Version 15.

Ich nutze oft eine Kunstrichtung am Anfang meiner Prompts, z.B. Art Nouveau, entweder so oder gewichtet auf ca. 0,3 bis 0,5. Anlaufstellen zu Kunstrichtungen:

https://de.wikipedia.org/wiki/Liste_von_Kunstrichtungen

https://de.wikipedia.org/wiki/Zeitalter_der_Moderne

Wenn das für Puristen nicht passt, probiere z.B. „award-winning illustrative“. Für mich bedeutet das Hinzufügen einer geliebten Kunstrichtung, dass ich den Rest des Prompts nicht so stark anpassen muss, um einen ähnlichen Effekt zu erzielen. Die kurze Liste meiner Lieblings-Kunstrichtungen steht in einer txt-Datei im Dynamic Prompts Wildcards-Ordner, sodass ich nur __Art_Movements__ verwenden muss.

Als Regel nutze ich keine Künstlernamen, außer gelegentlich posthum, um einen ganz bestimmten Effekt zu erzielen, z.B. René Lalique

https://de.wikipedia.org/wiki/Ren%C3%A9_Lalique

Ich nutze kohya_ss (v21.8.9) für TI-Training, da automatic1111 wohl kein SDXL-Training ins WebUI einbauen wird.

https://github.com/bmaltais/kohya_ss

Es gibt viele Einstellungen/Konfigurationen in kohya_ss und ich verstehe noch nicht mal die Hälfte davon :-( Dennoch versuche ich hier Infos, die Leuten helfen könnten, SDXL Textual Inversion Stile mit kohya_ss zu trainieren. Ich habe kein SDXL TI Objekt ausprobiert und bekomme kein LoRA-Training mit kohya_ss zum Laufen (es startet entweder nicht oder bricht ab).

Ich kann nur die Settings beschreiben, die auf meinem PC funktioniert haben, hoffe aber, dass sie auch für ähnliche PCs relevant sind. Also...

Mein PC:

Nvidia 3060/12GB (nicht Ti), MSI X570 Board, Ryzen 7-2700 (8c/16t), 64GB RAM, mehrere SSDs, Win10pro.

Ordnerstruktur:

XLmrblng15

\--img

\--\--50_XLmrblng15 style

\--log

\--model

Trainingsbilder:

Ich erstellte 45 Bilder mit 1024x1024 und legte sie im Ordner „50_XLmrblng15 style“ ab. Dann eine .caption-Datei für jedes Bild. Beispiel:

cliff with waterfall.png

cliff with waterfall.caption

Caption-Dateien sind reine Textdateien, ich nutzte einfach einen Texteditor. Inhalt jeder .caption folgt folgendem Muster:

xlmrblng15, cliff with waterfall

Das ist der Name des TI, ein Komma, ein Leerzeichen und der beschreibende Dateiname.

Ich nutze keine Captioning-Utilities.

Wenn weiter unten kein Parameter erwähnt, habe ich ihn auf Standard gelassen.

Im Haupt-Tab „Textual Inversion“ bei kohya_ss:

Reiter Source Model:

Model Quick Pick = custom

„Save trained model as“ = safetensors

Pretrained model name or path = G:/stable-diffusion-webui-master/webui/models/Stable-diffusion/SDXL/sd_xl_base_1.0_0.9vae.safetensors

SDXL model = angehakt

Reiter Folders:

Image folder = G:/KOHYA/TRAIN/XLmrblng15/img

Output folder = G:/KOHYA/TRAIN/XLmrblng15/model

Logging folder = G:/KOHYA/TRAIN/XLmrblng15/log

Model output name = xlmrblng15

Parameter (basic) Tab:

Token string = xlmrblng

Init word = pattern

Vectors = 8

Template = caption

Mixed precision = bf16

Save precision = bf16

Number of CPU threads per core = 1

Cache latents = angehakt

Cache latents to disk = angehakt

LR Scheduler = constant

Optimizer = AdamW8bit

Learning rate = 0.001

Max resolution = 1024,1024

No half VAE = angehakt

Parameter (advanced) Tab:

VAE = G:/KOHYA/sdxl_vae.safetensors

Save every N steps = 100

Gradient checkpointing = angehakt

Memory efficient attention = angehakt

Max num workers for DataLoader = 4

Parameter (samples) Tab:

Sample every n steps = 100

Sample prompts =

ein analog realistisches Foto eines prächtigen Krug auf einem Tisch mit Gläsern, sehr detailliert, komplex, xlmrblng15 --w 1024 --h 1024

xlmrblng15, ein analog realistisches Foto einer prächtigen englischen Dame in viktorianischem Badeanzug, sehr detailliert, komplex, --w 1024 --h 1024

Mit all den genannten Einstellungen lag die Trainingszeit bei ca. 6s/Iteration. Variabel, weil ich den PC nebenbei für andere (einfache!) Dinge nutzte, während kohya lief. Das xlmrblng15-1300 wurde ca. nach 2 Std 10 Min produziert.

Während des Trainings lag die GPU RAM Nutzung knapp innerhalb der 12GB meiner 3060. Beim Sample-Generieren und Speichern des TIs alle 100 Schritte kamen aber ca. 7GB dazu (also 19GB gesamt). Diese 7GB stammen aus dem "Shared GPU Memory", also dem Hauptsystem RAM. Nach der Sample-Generierung fiel die Nutzung zurück auf nur die 12GB GPU RAM.

Das Verlangsamen bei Nutzung von "Shared GPU Memory" war etwa 10-fach. Sehr ärgerlich :-(

Die Samples von kohya sind im Vergleich zur Benutzung des Basis SDXL Modells in automatic1111 webui qualitativ sehr schlecht. Ich habe sie trotzdem drin gelassen, denn so konnte ich wenigstens grob sehen, ob das Training in die richtige Richtung geht.

Selbstverständlich ist dein Trainingsdatensatz sehr wichtig. Ich probierte viele Kombinationen aus generierten und realen Bildern, bis ich einen Satz hatte, der das TI auf dieser Seite ergab.

Für 45 Bilder und Batchgröße 1 (Standard) sagt der spezielle Ordnername „50_XLmrblng15 style“ kohya, die Bilder 45 Mal zu durchlaufen. 45 * 50 = 2250 Schritte gesamt. Nach Testen der verschiedenen gespeicherten TIs bei 100, 200, 300 Schritten usw., entschied ich, dass der bei 1300 Schritten am besten arbeitete.

Im Parameters-Basic Tab gibt es ein Feld „Init word“. Ich fand, dass das Training sehr empfindlich ist, was ich hier nutze. In diesem Fall nutzte ich „pattern“, ein 1-Token-Wort aus SDXL-Sicht. Theoretisch hätte ich eine 8-Token-Phrase nutzen müssen (kohya gibt Warnung, wenn Vectors und Init Tokens nicht übereinstimmen). Bei einigen Läufen nutzte ich mehr Tokens und erhielt interessante TIs, aber nicht das, was ich suchte.

Die Nutzung von „pattern“ hat einen Nachteil: je nach Prompt kann es zu vielen Wiederholungen kommen - wie ein sich wiederholendes Muster auf Tapete oder Geschenkpapier.

„marblng“ oder „paper marbling“ funktionierte nicht: Im Vergleich zu SDv1.x kennt SDXL viel mehr über Marmorierung. Probiere es in deinen Prompts! Fordere Marmor/Marmorierung/marmorierte Dinge an und SDXL macht so viel besser als SDv1.x. Immer wenn ich ein TI mit init word marbling oder einem verwandten Begriff gemacht habe, bekam ich eher das eingebaute Marmorieren von SDXL, nicht das Training meines Datensatzes. :-(

Ich untersuchte die Geschichte des marmorierten Papiers und probierte Begriffe wie „ebru“, die türkische Variante von marmoriertem Papier. Das funktionierte auch nicht gut. Am Ende gab mir der sehr breite Begriff „pattern“ das meiste, was ich wollte.

Kohya_ss hat die Option eines „style“ Templates im Parameters-Basic Tab. Ich hatte einige ordentliche Ergebnisse mit „style“ bei einigen meiner nicht veröffentlichten SDXL TIs, aber beim marmorierten Papier waren die Ergebnisse nicht gut.

Textual Inversion vs. LoRA

Ich konzentriere mich auf TIs, weil (a) ich kein LoRA erfolgreich trainieren kann und (b) ich den Inhalt in SDXL nutzen möchte, statt mehr Daten darüberzulegen. Ich bin nicht gegen LoRAs - ganz im Gegenteil! Ich habe viel Spaß mit LoRAs von konyconi und anderen. Tolles Wow!-Ergebnis :-)

Aber ich fühle mich momentan mehr zu TIs hingezogen. Wie ich es sehe, erlauben TIs die Anpassung der Prompts in SDXL-Bereiche, die einfache Worte nicht erreichen können, während LoRAs neue Inhalte auf SDXL legen, die man dann über Prompts „mischt“.

Das ist sehr vereinfacht, aber ich will hier keine Diskussion über den vollen Sampleraum von SDXL vs. dessen Wahrscheinlichkeitsraum und Supersets starten. Das ist für mich ein Hobby, kein Job :-)

Als letztes noch, ich nutze das Wildcard-System von Dynamic Prompts stark. Meine typischen Prompts mit diesem xlmrblng15-1300 TI sehen so aus:

(__Art_Movements__:0.5) xlmrblng15-1300, reifer __Nationalities__ (__Character_MF__) reitet ein __BW_Animals__ in einer weiß getönten __Landscapes__, __Metal_Color__ Filigran-Einlage

Konkrete Prompts (also nach Ausführung von Dynamic Prompts) sind meist zwischen 30 und 45 Tokens lang.

Wenn ich ein generiertes Bild in den „PNG Info“ Tab von automatic1111 webui ziehe, ist ein typisches Ergebnis dieses dynamischen Prompts 34 Tokens lang:

(Surrealismus:0.5) xlmrblng15-1300, reifer schwedischer (männlicher Vampir) reitet einen Dalmatiner in weiß getünchten Wattflächen mit scharlachroten Kranichen, schwarzer Filigran-Einlage

Warum Nationalitäten einbauen, wenn SDXL da in längeren Prompts wenig drauf achtet? Weil SDXL voreingenommen ist und kleine Extras je nach Nationalität hinzufügt. Das kann z.B. rote Haare bei "schottisch", Pyramiden bei "ägyptisch" oder den Mt. Fuji bei "japanisch" sein. Funktioniert auch bei anderen Dingen; Kontextverknüpfungen/Assoziationen sind in SDXL stärker als bei SDv1.x. Es ist schwierig, das zu kontrollieren :-(

Auflösungen für SDXL nutze ich üblicherweise 1024x1024, 960x1344 und 1344x960. Empfohlene Auflösungen im Netz schlagen vor, die Basis von 1MP (1024x1024) und andere Auflösungen nahe 1MP zu nutzen. Also sollte ich bei 1344 Breite 768 Höhe nehmen. Das probierte ich, empfand die Qualität von 1344x768 als deutlich schlechter als bei 1024x1024 oder 1344x960. Außerdem skaliert 1344x960 exakt auf mein 7"x5" Foto-Papier. Also das :-)