Beiträge von Synonym

Nein, hier zumindest nicht. Ich habe eigentlich überall als SM-Bild ein anderes als Bilder im Artikel und das Gleiche auf allen Seiten. Das spielt zumindest hier nicht wirklich eine Rolle.

Bei der Halloween ist z.B. überall das "/bilder/webseite/happy-halloween-2.jpg". Bei anderen Domänen sogar ganz andere Bilder, die auf der Domain selbst nicht vorkommen und nur für FB, Pinterest, Twitter und Co gemacht sind (anderes Format). Ist bei mir quasi überall so, auf allen Domänen. Immer das gleiche Bild für SM-Dienste.

Du willst also die Description im Dashboard weg haben, aber im eigentlichen Forum soll sie angezeigt werden.

Wenn ja, dann wollen das anscheinend recht viele Leute. Scheint aber mit den Einstellungen vom Forum nicht zu gehen. Entweder immer weg oder immer da. Die anderen, wo das auch wollten, lösen das alles mit CSS und display:none.

Im Dashboard müsste die Klasse für die Beschreibung die "wbbBoardDescription" sein, während sie im Forum selbst dann die "contentHeaderDescription" ist. Müsste man also getrennt ansprechen können.

Aber ja, display:none ist nicht das Gelbe vom Ei.

Wobei, so sauber ist das auch nicht. Dann wären die Beschreibungen hier eine Ebene tiefer auch weg: "/forum/board/51-seo-forum/"

Ok, lässt sich mit CSS hinbiegen, man kann die alle einzeln über die Foren-ID ansprechen. CSS bleibt es aber dennoch.

Ich mache mal einen extra Fred auf, auch wenn es hier auch um Bilder geht.

Folgendes: Heutzutage werden ja Bilder in verschiedenen Formaten (Größe) und Typen (jpg, webp) ausgeliefert. Dazu genutzt wird ja meist ein SrcSet oder gleichwertige Methoden. Schön und gut. Nun fällt mir eine Sache auf. Gegengeprüft mit anderen Domänen ist es, also bei der hier kein Zufall.

So sehen die Abrufe laut Google der Bilder aus.

Bei mir auf der Seite gibt es in Sachen Bildern zwei verschiedene Konstellationen.

1. Mit Fallback von jpg zu webp und dann auch noch in verschiedenen Auflösungen, wie hier:

2. Kleines Bild direkt eingebunden und nur ein Fallback auf webp, keine andere Größen.

Den Daten von Google oben (stammen aus den WMT) kann man schon mal entnehmen, dass dort kein einziges der "400w" Bilder abgerufen wird. Auch kein webp. Gemeinsam haben die beide, dass die nur im "srcset" stehen. Eigentlich müsste der Google-Bot aber die 400w-Version bekommen, denn der kommt mit einer Auflösung von 411px auf die Seite.

Warum ich das nun hier schreibe? Weil mir nun die Gedanken durch den Kopf gehen. Ich habe im src das jpg und im srcset das webp. Eigentlich als Fallback für Browser, die srcset und webp nicht können. Dann steht im "src" immernoch ein Bild, das sie verstehen.

Wenn ich die beiden vertausche, dann müsste Google entsprechend das "700w.webp" abrufen.

Dann gibt es da noch das Thema Mobile-First. Also müsste man doch eigentlich das kleine Bild, das "400w" direkt in den src schreiben und nicht das 700w, oder? Dann würde aber der Bot das 400w abrufen und quasi das 700w nicht mehr kennen, so wie im ersten Bild, nur umgedreht. Irgendwie ist das alles doof.

Hier in meinen Fällen ist das ganz große Bild (das ohne w-Angaben) jeweils ganz normal verlinkt per a-Tag. Das wird auch abgerufen. So, nun gibt es aber auch Webseiten, wo das nicht der Fall ist, wo kein Link besteht zu einem großen Bild, die quasi nur srcset benutzen. Wie ist das denn dann mit denen? Wenn Google das dann genauso macht, und nur das abruft, was direkt im src ist, und das dann auch noch wegen "mobile first" das kleine sein muss, wie kommt Google dann an die großen Versionen?

Ich hoffe, man kann mir folgen....

So wie es ausschaut, ruft Google jedenfalls nur die Bilder aus dem A-Tag ab und die aus dem "src".

Interessant. Was genau meint der denn mit "im Div eingebunden" bzw. genauer "im src-Attribut eines Div? Ein Div hat doch kein src? Oder ist damit so was da gemeint:

<div>< img src=""></div>

Also img im Div? Wenn ja, dann kann ich das bei mir völlig ausschließen. So sind bei mir alle bzw. 99,9% der Bilder eingebunden und zwar auf den Reiseportalen. Die sind dort alle in einem Div, weil ich da float und flex, grid, cover und Co brauche.

Ok, der meint das wirklich so, mit <div src="">. Dass das nicht geht, ist doch eigentlich kein Wunder. Alles andere wäre Googles Sache, aber dieses Konstrukt von <div src=""> ist ja noch nicht mal gültiger HTML-Code

Im Grunde ist das Konstrukt ja nur ein Versuch, die URL-des Bildes zu verheimlichen (wird nicht öffentlich angezeigt) und dann zu testen, ob Google der URL dennoch folgt und indexiert. Macht es nicht, das war eigentlich klar. Im anderen Fall, mit Javascript und als Reintext folgt Google. Bei JS ist es gültiger Code und das Bild könnte ja zum Script gehören. Google folgt da allen Links, daher werden die ja auf auch verschleiert oder zerhackstückelt, damit es nicht passiert. Passiert aber dennoch.

Im Reintext macht es Google definitiv, die URL ist dann auf der Webseite auch sichtbar. Erinnert Ihr euch an Pagespeed? Da waren die Bild-URLs auch als Reintext in einer Liste aufgeführt. Google hat die brav als Bild der "Pagespeed" indexiert, obwohl die URL ja eine fremde Domain war. Selbst als nur noch der Pfad da stand, keine Domain mehr, hat google es versucht. Dann allerdings beim Abruf einen Fehler verursacht, weil die Domain dann ja fehlte und Google die falsche nahm. Das macht Google prinzipiell überall. Alles, was irgendwie nach einer URL oder einem Pfad ausschaut und sichtbar ist oder Bestandteil eines JS, wird von Google abgerufen.

Was mir auch aufgefallen ist, Zufall oder nicht, keine Ahnung. Am Tablet gibt es in der Bildersuche eine Auswahl "HD". Ob es die bei Smartphone auch gibt, keine Ahnung, beim Desktop ist die jedenfalls nicht zu finden. Am Tablet habe ich z.B. 16 Bilder im Index. Aktiviere ich da dann "HD", dann sind es nur noch 15, obwohl alle 16 die gleichen Abmessungen haben. Beim Desktop sind es immer 15. Genau das eine, das bei "Tablet mit HD" fehlt, fehlt auch immer am Desktop.

Bei der Seite war es sehr überschaubar, im Ferien-Netzwerk nicht mehr zu zählen. Wenn ich da auf "HD" umschalte, fehlt gefühlt die Hälfte aller Bilder.

Könnte es also eventuell sein, dass Google bestimmte Bilder per Desktop erst gar nicht anzeigt?

Bei der "Deko" schaut es aktuell so aus:

Bild 1

war vorher ein anderes, war im Index, Kopie von Pixabay

nun neues Bild, neuer Dateiname, Img-Sitemap, nicht im Index

Bild 2

Gab es vorher nicht

neues Bild, Img-Sitemap, im Index nach 4 Tagen

Bild 3

war vorher ein anderes, war im Index, Kopie von Pixabay

nun neues Bild, ALTER Dateiname, Img-Sitemap, im Index geblieben, aber mit falschem Thumbnail

Beobachterwert ist hier auch, dass die Großansicht in Google hier nicht geladen werden kann. Warum auch immer. Das ist die gleiche Datei wie vorher auch, nur eben ein anderes Bild.

Bild 4

Gab es vorher nicht

neues Bild, Img-Sitemap, nicht im Index

Bild 5

Gab es vorher nicht

neues Bild, KEINE Img-Sitemap, im Index nach 5 Stunden

Und das sehe ich gerade im Ferien-Netzwerk:

Die Bilder da waren alle schon im Index, so ca. 10 Jahre. Der Kunde hat die dann am 20.9. durch neue ersetzt. Seit 2 Tagen sind die neuen im Index. Und ja, das ist wieder eine der Bildergalerien.

also das muss man echt verstehen. Dein Bild mit den grauen Kürbissen ist das fünfte Bild auf der Seite. Das ist seit 4 Stunden im Index. Das zweite Bild auch. Die anderen drei fehlen.

Zitat von catcat

Meine Bilder sind alle leicht unscharf, wie weichgezeichnet

Achso. Ich dachte immer, das liegt an den seidenweichen Stoffen, die wie ein Hauch an Nebel durch die Luft schweben

Aber ja, da passt das gut.

Bei dem Zaun-Bild kann ich nicht sagen was es genau war, das war dynamisch per JPG-Panda, dürfte aber in die Richtung 75 bis 80 gehen. Aber just eben hatte ich es wieder. Ein Bild von Halloween. Das konnte problemlos um 80% komprimiert werden (aus JPG 100), also Dateigröße 80% kleiner. Gut, das Ding hat auch nicht viele Farben.

Was mir dabei aber auffiel ist, dass die Einsparungen prozentual immer kleiner werden, je kleiner die Bilder werden. Die 80% waren bei 1344 px. Bei 700 px waren es nur noch knapp 40% und bei 300 px lediglich 15%.

Wie gesagt, von Q100 aus JPG ausgehend. Wenn das nun ein JPG mit 90 gewesen wäre, dann wären die letzten 15% wahrscheinlich auch auf 1-2 zusammengeschrumpft. Und das sind ja eigentlich genau die Bildgrößen, mit denen ich arbeite und die überall angezeigt werden. Wenn da einer auf eine Lightbox klickt und dann die Datei größer ist, ist mir das wurscht. Die, die direkt angezeigt werden, sind wichtig. Aber genau bei denen ist da nicht viel möglich.

Alex, skaliert sind die Bilder schon. Die müssen nur in ein anderes Datei-Format, Und ja, so um die 96 / 97 sind die Bilder hier auch sehr gut, nur da wird dann halt nichts mehr kleiner im Vergleich zu JPG 90, also zumindest nicht so viel, dass es den Mehraufwand rechtfertigen würde.

Kommt natürlich auf das Original-Bild an. Wenn man da Bilder hat wie bei den "Zäunen", wo die quasi völlig unkomprimiert als JPG vorliegen, da macht webP mit 96 schon einen großen Unterschied, würde JPG aber auch tun. Das ist hier aber nicht der Fall, die Bilder sind schon komprimiert.

Ich nutze ja gerne für meine eigenen Bilder den JPG-Panda (https://tinyjpg.com/). Der komprimiert ja nicht mit einem festen Wert, sondern dynamisch, damit das Bild am Ende unverändert ist. Bei meinen Bildern kommt der da auf 40-80%, je nach Inhalt und Farben. Bei WebP ebenso.

Nutze ich da aber eines der Bilder der Kunden, also die mit JPG 90, dann sind das plötzlich nur noch 1-4% und teilweise auch dort dann schon mit fehlenden Details. Wenn ich pauschal mit WebP 90 speichere, dann sind die deutlich kleiner, keine Frage, aber eben auch deutlich unschärfer in den Detailbereichen.

Bei Lighthouse gibt es ja unter anderem so Angaben wie "Bilder in modernem Format bereitstellen, würde z.B. von 120 kB dann 45 kB sparen". Wenn ich da genau das Bild nehme und in WebP umwandle, so lang neu teste, bis ich dann eines habe, das die besagten 45 kB kleiner ist, dann ist das Bild einfach nur Mist. Ich habe noch kein einziges Bild gefunden (von den Kundenbildern), wo ich ansatzweise an diese genannten Werte rankomme und das Bild dann gleich bleibt. Ich habe sogar sehr selten welche, die sind als webp größer als als jpg.

Aber genau das wird ja für WebP behauptet. Gleiche Qualität bei deutlich kleinerer Dateigröße.

Ausgehend von einem unkomprimierten Original ist das alles korrekt, da sind die Qualitätsstufen dann ähnlich gut bei gleichen Werten, also 90 zu 90 oder 75 zu 75, aber welche Bilder heutzutage sind im Netz schon unkomprimiert?

Genau genommen müsste man ja sogar noch sagen, dass ein jep 90 Bild, das ich da dann umwandle in webp 90, quasi schon komprimiert ist. Das ist ja nicht mehr das gleiche Ausgangsbild. Das jpg hat dann ja nur "90", das webp aber "90 und davon dann noch mal 90".

Man kommt von einer Kompression ja nicht mehr zurück. Wenn das Ding 90 hatte, dann hat das 90, auch wenn man es auf 100 stellt und neu speichert. Fatal wird nur, dass dann in den Bildinformationen 100 hinterlegt wird, was es aber nicht hat. Hinterlegt wird halt nur der letzte Wert, der genutzt wurde, der Inhalt selbst ist dann aber dennoch komprimiert. Damit kann man also noch nicht mal auslesen, was das Bild nun wirklich an Faktor hat, denn man sieht ja nur den letzten. Das geht nur, wenn man sicherstellen kann, das Bild wurde nur einmal bearbeitet und gespeichert, denn dann ist der letzte Wert und der erste der gleiche.

Mal als Vergleich. Das Bild von Dir mit dem Gartenzaun, das hast Du ja schon komprimiert und umgewandelt in WebP. Das bekomme ich aber problemlos von 100 kB runter auf knapp unter 40 kB, ohne sichtbare Änderungen.

Da hat selbst der rote Fleck oben links noch die gleiche Form.

Nehme ich ein Bild der Kunden mit 100 kB, dann komme ich ohne Qualitätsverlust maximal auf 95 kB runter und das ist den Aufwand nicht wert. Wenn ich da auf einen Wert gehe, der mir eben auch 60% einspart, dann ist der rote Fleck zwar immer noch da, eber eher ein Punkt oder Oval, also andere Kontur.

ok, dann machst Du das ja quasi wie ich, nur dass ich den Upload dann mit Q90 speichere. Das macht ja PHP selbst. Gleube nicht, dass es da Unterschiede in PHP zwischen 7.4 und 8 gibt.

Wobei ich aber eben, wie gesagt, nicht weiß, was das Bild vorher hatte. Mache Kunden schieben da Bilder direkt von der Cam hoch, mit Q100, bei anderen habe ich eher das Gefühl, das ist schon nur noch Q50. Teilweise werden die ja auch mehrfach überarbeitet. Also von der Cam zum Webmaster -> auf die eigene Seite -> zu einem anderen Portal -> dort dann Download und dann Upload bei mir. Das natürlich nicht alles jeweils vom Original, sondern immer als Upload und Download.

Meine Bilder hier sind alle in Auflösungen

von 75x75

über 300x200

400er

500er

1024er

1600er

1920er

Und das dann teilweise auch noch mit fixierter Breite oder fixierter Höhe. Denn das Upload-Bild hat ja 100 verschiedene Formate und Verhältnisse.

Bei den großen Bildern sehe ich da auch nicht viele Unterschiede, aber bei denen so um 300 bis 500 schon. Ein Garten ist einfach nur ein Garten, fertig, aber wenn es ins Detail geht, dann wird es ungenau. Ich würde noch nicht mal sagen "unscharf", aber eben ungenau. Sieht man dann, wenn man auf Zoom geht.

Ja, mit Irfan geht das wunderbar. Aber auch nur mit meinen eigenen Bildern oder von der AI. Wenn ich da so ein Kundenbild nehme, dann wird das da auch nicht wirklich besser. Hatte das damals mal versucht. Die Einsparung aller Bilder per Batch durchgelaufen war gerade mal 4,7%, dafür hat sich das Datenvolumen aber quasi fast verdoppelt, wegen Doppelspeicherung eben. PlugIn habe ich da auch, glaube das heißt einfach nur WebP-Plugin....

So, ich teste dann mal wieder damit und komme zum gleichen Ergebnis wie schon vor 4 Jahren.

Bilder, die ich selbst erstelle und hochlade funktionieren mit WebP ganz gut, also das ist nicht das Problem. Mein Problem ist der Upload bei PHP und die Verarbeitung dort.

catcat wie machst Du das denn zum Beispiel? Hast Du Bilder, die das System umwandelt oder machst Du das alles selbst?

Mein System erzeugt hier Bilder aus den jeweiligen hochgeladenen Quellen. Diese liegen in der Regel als JPG vor, in riesigen Auflösungen.

Die skaliere ich dann zu den von mir benötigten 8 Formaten und speichere die als JPG. Kein Problem, geht alles. So, nun habe ich den Testlauf eben wieder gemacht und die skalierten Bilder als JPG und WebP gespeichert. Kompression lag bei 90%, die ich schon immer verwende.

Die Bilder werden als JPG also so gespeichert

imagejpeg($img_jpg, TMP_UPLOAD_PATH.'hauptbilder/1024/'.$img_jpg, 90);

Wenn ich das nun aber mit WebP mache als

imagewebp($img_webp, TMP_UPLOAD_PATH.'hauptbilder/1024/'.$img_webp, 90);

dann sind die WebP-Bilder zwar 30-50% kleiner als vorher, was gut ist, aber die Qualität leidet deutlich. Vieles ist quasi wie identisch, aber Kleinigkeiten, die doch wichtig sind, sind deutlich schlechter. Z.B. bei ner Sonnenblume auf dem Tisch erkennt man innen noch "schwarz", aber nicht mehr die Kerne. Man erkennt am Boden noch das Parkett, aber nicht mehr das Stäbchenmuster. Andere Dinge im Bild, wie Schrank, Bilder, Deckenlampe, TV, Couch sehen identisch aus.

Und nun kommt mein Problem. Ich spielte beim WebP nun ja schon mit anderen Stufen rum, also nicht 90, sondern 92, 95, 97. Erst bei 97 kann ich wirklich sagen, dass die Bilder identisch aussehen und auch die kleinen Details erkennbar sind. Nun sind aber die Dateigrößen nahezu identisch. WebP ist nur noch ca. 1% kleiner als JPG vorher. So macht das keinen Sinn, das alles doppelt zu generieren und auf dem Server zu speichern. Sind bei jedem Bild ja dann 8 extra für WebP. Zudem kommt dann so viel extra HTML-Markup dazu, dass selbst der schon größer ist, als die 1% Einsparung bei dem Bild selbst.

Wir reden hier in der Regel von Bereichen wie

34,57 kB bei JPG (Q90)

34,29 kB bei WebP (Q97)

22,82 kB bei WebP (Q90)

Das sind die "kleinen" Versionen, die auf meinen Seiten zu 80% verwendet werden.

Hat einer einen Tipp?

Das mit JPG und 90 mache ich auch nur, weil ich die Ursprungsqualität nicht kenne. Die Bilder stammen ja nicht von mir, sondern von den Kunden. Wenn das gute Bilder sind, dann reicht da sogar 80 oder gar 75 und das schaut immer noch gut aus. Da ich aber nicht weiß, was hochgeladen wird, mache ich das eben mit 90.

Meine eigenen Bilder mache ich eigentlich alle mit 100. Da ist WebP klar überlegen, aber das geht nicht mit 100.000en Bildern der Kunden.

Ja, das mit dem "ähnlich sind" war nur eine Vermutung, denn das könnte hier bei mir halt passen. Auf "Geranien überwintern" sind halt 20 Bilder zu Geranien im "Winterrückschnitt bzw. beim Eintüten".

In den Galerien sind es unterschiedliche zu einer Wohnung, zumindest mehr Variation als bei den Geranien, Halloween, Silvester oder Regions-Artikeln, wo dann 5 Landschaftsbilder drinnen sind.

Aber, hab das gestern noch mal etwas durchgeschaut. Zumindest das mit den Landschaftsbilder kann ich hier nun selbst verneinen. Die sind fast alle im Index. Das sind aber keine eigenständigen Artikel, sondern eben die neuen Artikel mit "Produktliste oben mit 20 Produkten und am Ende der Seite 1000 Wörter Text". Hier werden die großen Bilder vom Ende aufgenommen.

Bei anderen, reinen Contentseiten habe ich auch den Zustand, dass das erste Bild genommen wird, egal was das ist und ob es passt. Auf einer Seite ist es sogar ein Bild einer Werbung, also völlig falsch, aber das Erste. Ebenso bei einer weiteren. Dort auch das erste Bild, ein winziges von Flicker mit gerade mal 200x100 Pixel Dann kommen ca. 1200 Worte Text mit verteilt weiteren 4 Bildern a 700px und am Ende noch ein großes mit 1920. Alle größeren interessieren Google nicht.

Bei der "Halloween" auf der Startseite sind 4 Bilder. Im Index ist 1, 2 und 4. Auf der "Bedeutung" sind 3. Zwei mit 300x200 und am Ende eines mit 1920. In Index ist 1 und 2. Bei der "Bräuche" waren es zwei. Erst eines mit 300x200 und dann wieder eines mit 1920. Im Index ist das Erste.

Aber, dass Google immer das erste Bild nimmt, kann ich dennoch nicht bestätigen. Das ist sehr sehr oft der Fall, aber nicht immer. Die Silvester-Seite hat ja den Schwerpunkt Bilder und genau dort ist es so, dass Google eigentlich nicht das erste Bild nimmt, sondern eines viel weiter hinten. Auch das ist dort ein Problem, denn, das ist so aufgebaut "oben Bilder 2023, dazwischen zeitlose, am Ende Bilder von 2022". Google nimmt die Bilder von 2022. Aktuell sind bei der Domain mehr Bilder von 2018 im Index, als aktuelle. Bei der "Geschichte" sind es drei. Dort im Index aber 2 und 3, das erste Bild fehlt. Bei der "Rezepte" wird es interessant. Da waren 4 Bilder drauf. Allesamt von Flicks und winzig. Im Index war nur das erste Bild. Die vier Bilder habe ich alle durch neue aus der AI ersetzt und weitere 9 eingebaut, also nun 13 in "groß". 2 Tage später war das alte Bild verschwunden und das neue im Index, wieder das Erste. Physisch wäre das alte Bild aber noch da, liegt auf dem Server, nur eingebunden ist es nicht mehr. Das neue hat einen neuen Dateinamen.

Wobei ich dann hier bei der Silvester-Domain auch wieder den anderen Punkt feststelle, wodurch Alex immer einen riesigen Vorteil hatte. Verteilung auf unterschiedliche URLs. Alex hatte das ja mit mehreren Blogposts. Jeweils winziger, oft sinnloser Text, dann eine Handvoll Bilder. Die waren indexiert. Ich habe große und lange Seiten, dafür aber nur eine oder eben zwei. Da fehlten die meisten Bilder. Auch jetzt wieder, und da dachte ich dann wieder an "Ähnlichkeit". Ich habe da vier Bilder mit so einer Glitzerschrift am Nachthimmel. Das sind alles völlig unterschiedliche Bilder, aber eben von der Art her gleich. Glitzerschrift, auch wenn andere Schriften, Arten und andere Hintergründe. Im Index ist davon eines und das auch noch genau das schlechteste der vier.

Spannend finde ich auch die Geranien-Shop-Seite. Da sind ja bis zu 200 Produkte drauf, je nach Saison. Alles Produkte aus dem Affiliate, also kopierte Texte. Wird dann mit den 200 Produkten sehr lang. Die Bilder dazu stammen auch aus Affiliate, werden lokal im Server-Cache gespeichert und eingebunden. Also bis zu 200 Bilder, die alle jeweils 200x200 Pixel haben und wohl tausendfach verwendet werden, bei anderen Seiten. Die waren so gut wie ALLE im Index. Am Ende der ganzen Artikel habe ich noch eine FAQ mit 2 oder 3 eigenen großen Bildern, die waren nie im Index. Habe dann die Produktbilder von Affiliate per HTTP-Header auf noindex gesetzt und weg waren sie. Die drei am Ende der Seite von mir kamen aber nie rein.

stimmt, ich auch. Normales img, als Figure mit und ohne figcaption oder als verschiedene Versionen mit picture und srcset.

wegen jpg. Scheint keine Rolle zu spielen. Ich habe hier eine mit nur jpg, eine mit nur webp und zwei mit beiden Versionen. Wobei das auch die einzigen mit webp sind. Die anderen Domänen mit den Galerien haben nur jpg.

Was ich mir verstellen könnte wäre, dass Bilder in so langen Texten oft sehr ähnlich sind. Z.b. 5 verschiedene Autos in einem Autoartikel. In den Galerien hier sind alle unterschiedlich. Andere Zimmer, mal innen mal außen, mal Garten, mal Winter.

Bei meiner geranien beobachte ich das schon lange. Da kann man auch was wie AI ausschließen. Bei der sind teils von 20 bis 30 Bildern pro Seite nur 3 oder 4 im Index. Gemein haben sie aber, dass sie sehr ähnlich sind.

Leider habe ich keine Ahnung, hätte heute Morgen aber fast den gleichen Post hier gestartet. Hier schaut es eigentlich genauso aus. Bildergalerien mit kleinen Thumbnails und kein Text auf der Seite sind fast vollständig im Index. Bilder in längeren Texten hingegen nicht, egal ob die kleinen als Thumbnail + Verlinkung oder direkt als große Version. Wenn ich Glück habe, ist von 5 Bildern auf einer Seite, eines im Index, aber nur mit Glück. Die Domain, wo ich aktuell beobachte, hat an die 50 Bilder verteilt auf 10 Seiten, im Index sind insgesamt 8 Bilder. Die 10 Seiten sind aber alle drinnen.

Hier kann ich zumindest ausschließen, dass es sich um eine bestimmte Domain handelt, denn das Verhalten haben alle 4 Content-Domänen und das schon seit etlichen Jahren. Eine davon hat sogar eine eigene IMG-Sitemap, das bringt aber auch keine Besserung.

Es scheint aber dennoch nicht unbedingt an langem Content zu liegen. Die beiden hier (die ersten im Bild) habe ich nachträglich in den Thread eingebaut und die sind im Index. Aber ok, das ist ein Forum und kein "Blog", vielleicht macht das auch noch einen Unterschied.

Hier gibt es sogar ein Video dazu. Laut seinen Angaben war er Alpha-Tester von Dall-E 3. Die Alpha konnte damals auch andere Formate, bis hin zu 16:9. Sind ein paar Bilder im Video, vor allem auch welche mit Text.

Hände Das hört sich doch mal gut an. MidJourney arbeitet da wohl auch dran, soll mit Version 6 besser werden.

Bin mal gespannt, wann Dall-E 3 dann bei Microsoft kostenlos sein wird bzw. eben so wie jetzt, mit X kostenlosen Bildern pro Monat (halt nur die 2er Version aktuell).

Die Aussage des Entwicklers ist ja eigentlich vielversprechend:

Zitat

According to Mikhail Parakhin from Microsoft, Bing Image Creator is already using DALL-E 3 model in the backend for some users.

Das hört sich auch gut an:

Irgendwie geht das Bild nicht, also als Text:

Zitat

If you haven’t seen DALL-E 3 images yet, you might be amazed at how good Bing Image Creator will become. Microsoft announced Bing will use OpenAI’s latest AI image generator, and this advanced technology is rolling out soon.

Schön wäre allerdings auch mal ein anderes Bildformat, dieses quadratisch wüsste ich beim besten Willen nicht, wo ich das gebrauchen könnte.

Interessant ist das aber schon. Mal so gesagt, der Eiffelturm bei Nacht darf kommerziell nicht fotografiert werden. Muss man eine Lizenz für erwerben. Nun gibt es aber Tausende von Nachtaufnahmen in Netz, in Bilddatenbanken etc, die das alles zur gewerblichen Nutzung freigeben und dann sogar noch unter CC0 setzen. Die KI wurde von solchen Bildern angelernt, bin ich mir sicher. Jetzt habe ich eben mal ein Bild erzeugt, von einer Bild-KI, deren Bilder, laut eigenen Bedingungen kommerziell genutzt werden dürfen. Darauf zu sehen ist ein sehr detaillierter Eiffelturm bei Nacht. Richtige (neue) Beleuchtung (geschützt ist ja nur die ab den 90ern, die vorher nicht), jede Strebe passt, Anzahl der Etagen passt, Querstreben an der richtigen Stelle, Plattformen korrekt etc. Das ist 100% der Eiffelturm bei Nacht.

So, nun stellt sich die Frage. Fotografieren für gewerbliche Zwecke darf man nicht. Das Bild stammt aber nun aus der KI, ist also nicht "fotografiert". Man kann aber auch nicht behaupten, das ist einfach ein Turm, nee, da stimmt jedes Detail, als wäre es selbst aufgenommen. Genau genommen dürfte man das KI-Bild also nicht benutzen, auch wenn die KI in ihren Bedingungen sagt JA und die Quellen (Bilddatenbanken) auch sagen JA.

Und das war nun nur der Eiffelturm mit dem passenden Bild drumrum. Wenn ich den aber in die Wüste stelle, dann ist es dennoch der Eiffelturm. Geschützt ist ja nicht die Lage, sondern die Inszenierung der Lichter. Die sind also in Paris geschützt, als auch in der Wüste, wenn man dort einen hinstellen würde.

Und letztendlich kann das halt bei jedem Element passieren. Bei meinen Halloweenbildern aktuell kann ich auch nicht ausschließen, ob vielleicht einer der Kürbisse, der links unten in der dritten Reihe, nicht vielleicht eine Kopie aus einem Comic ist. Oder es werden Schriftzüge nachgebildet. Schriftarten, die man aber eigentlich gar nicht hat, wenn man die Font nicht vorher teuer kaufte. Gut, ist nicht 100% identisch, aber sehr sehr ähnlich.

Ein Stück weit gehen die Anbieter wohl aber auch in die Richtung. Also nicht direkt, dass da was zusammengeklaut ist, sondern dass ein entstandenes Foto von der KI stammt. Sollte es also rechtlich an sich kein Problem sein, das zu erstellen, dann kann man darüber zumindest auch klarstellen, dass das keine direkte Kopie ist, sondern die KI es erstellt hat.

Alle Bilder, alle der großen Anbieter wie Stable Diffusion, Adobe, Microsoft, Midjourney, OpenAI etc., enthalten nämlich digitale Wasserzeichen. Sinn ist da aber erstmals primär, Deep-Fakes aufspüren zu können. Und bevor es kommt. Es ist egal, ob lokal erzeugt, das digitale Wasserzeichen ist dennoch da, zumindest bei den offiziellen Modellen.

Adobe geht sogar mit seiner KI noch weiter, wenn man ein eigenes Bild nachträglich überarbeitet. Da wird sogar hinterlegt, was genau durch die KI ersetzt wurde und was "Original" war.

Das ungefragt Sammeln ist eine Sache, die Daten dann aber auch zu verwenden und kommerziell weiterzugeben ist eine andere.

Andere Lösung? Es dürfen nur Bilder und Texte zum Anlernen genutzt werden, die entsprechend eine Lizenz haben oder eben lizenziert wurde.

Die ganzen Stock-Anbieter könnten z.B. Ihren Fotografen eine angemessene Zahlung leisten und dann die Bilder zum Anlernen eines eigenen Modells benutzen. Dann hätten sie nur Daten benutzt, die von ihrem Portfolio selbst sind und eben auch bezahlt wurden.

"Ist halt die Zukunft" ist keine Antwort auf so ein Thema. Wenn bei euch jeder hergeht und sich in der Küche selbst bedient, das über Monate so geht, sagst Du dann auch, "ist halt die Zukunft"? ISt es die Zukunft, dass in gewissen Großstädten 5 von 10 Fahrrädern geklaut werden? Aktuelle Sachlage ist es, aber wird daraus "die Zukunft", weil "ist halt so"?

Hatte Dir ja mal das Beispiel mit der Fototapete geschrieben, auch wenn das nichts mit KI zu tun hat. War halt auch doof, wenn man die fotografiert und postet, aber die Nutzungsrechte nur für die privaten Räume bestehen bzw. eben nur der Fototapeten-Fotograf die fotografieren und das Motiv nutzen darf.

Und das Spiel kann man überall weiter machen, auch bei Text-KI und Code-Erstellung. Die Codes gibt es in der Regel schon irgendwie. Ob die einfach genutzt werden dürfen steht ungeklärt im Raum. Selbst wenn sie "frei" sind, dann haben die in der Regel eine Lizenz, MIT, Apache oder sonst was. Die KI nennt die Lizenzen dazu aber nicht, die spuckt nur den Code aus.

Was Du immer mit Deinem "lokal erzeugt" willst verstehe ich nicht. Das ist nämlich völlig wurscht, die nutzen die gleichen Quelle, es seidenn, Du lernst lokal Dein eigenes Modell an. Dazu brauchst aber erst mal verdammt viele Bilder, denn die "Base" dürfteste ja eigentlich nicht nutzen.

Naja, hat schon Nachteile. Wenn man den nur sporadisch mal braucht, zahlt man halt einen Monat, obwohl er da vielleicht nur zu 5% genutzt wird. Übrig gebliebenes Kontingent verfällt. Auch hat man eigentlich nie die Gewissheit, was das Tool dann in 5, 10 oder 15 Monaten kostet.

Ich bin froh mein Editor-Studio damals gekauft zu haben, auch wenn es viel Geld war. 1400 USD gegen 180 USD jährliche Subscription. Bin froh, das dennoch gemacht zu haben, denn mittlerweile kostet die Subscription fast 450 USD im Jahr. Seit einigen Jahren kann man das aber auch nicht mehr kaufen, die wissen schon warum. Subscriptions sind immer besser für den Anbieter.

Wenn ich ein Cookie-Dingens brauch, dann kann man das auch nur mieten. Mit dem Problem, dass ich da ein Paket bräuchte, das den maximalen Traffik pro Monat abdeckt (bei Jahres-Abo), obwohl dieser extreme Peak nur in 2 Wochen im Jahr entsteht. Ich würde also 50 Wochen lang viel zu viel bezahlen, nur damit das Ding dann in 2 Wochen das tut, was es soll. Eben auch da, weil das übrige Kontingent am Monatsende verfällt und nicht übertragen wird.

Und gerade so Tools aus dem KI-Bereich eignen sich eigentlich sehr gut, die einmalig zu kaufen. Wegen mir auch ohne Updates. Dann nutzt man halt eine ältere Version. Und wenn man dann was "neues" will, dann macht man halt alle paar Jahre ein Upgrade.

Diese ganzen Subscriptions, wenn das Produkt ohne dann nicht mehr nutzbar ist, sind Mist. Es sei denn, die sind so günstig, dass es quasi egal ist, aber das ist ja meist nicht der Fall und benötige Funktionen wie z.B. gewerbliche Nutzung bei KI-Tools oder eben IAB bei Cookie-Teilen nur in teuren Plänen enthalten.