Du besitzt zwei Bilddateien.

Bild A:

1200 × 800 Pixel

Bild B:

6000 × 4000 Pixel

Beide zeigen exakt dasselbe Foto.

Welche Datei ist besser?

Die spontane Antwort lautet vielleicht:

Natürlich Bild B. Es hat viel mehr Auflösung.

Das kann stimmen.

Muss aber nicht.

Wenn das Bild auf einer Website nur 600 Pixel breit dargestellt wird, kann Bild B unnötig groß sein.

Wenn du daraus dagegen ein großformatiges Poster drucken möchtest, könnte die zusätzliche Auflösung sehr wertvoll sein.

Die entscheidende Frage lautet deshalb nicht:

Wie viele Pixel hat das Bild?

Sondern:

Wie viele Pixel brauche ich für diesen konkreten Einsatzzweck?

Genau darum geht es bei Bildauflösung.

Ein Rasterbild besteht aus Pixeln

Wie im Artikel über Bildformate fürs Web beschrieben, bestehen Rasterbilder aus einzelnen Bildpunkten.

Diesen Punkten:

Pixeln.

Vereinfacht:

■ ■ ■ ■ ■
■ ■ ■ ■ ■
■ ■ ■ ■ ■
■ ■ ■ ■ ■

Jeder Pixel enthält Informationen über seine Farbe.

Zusammen ergeben Millionen solcher Pixel:

ein Foto,

einen Screenshot,

eine Illustration.

Was ist ein Pixel?

Das Wort Pixel stammt aus:

Picture Element.

Also:

Bildelement.

Ein Pixel ist vereinfacht die kleinste adressierbare Einheit eines Rasterbildes.

Ein Bild mit:

1000 × 500 Pixel

besteht aus:

1000
×
500
=
500.000 Pixeln

Breite mal Höhe ergibt die Pixelzahl

Beispiel:

1920 × 1080

ergibt:

2.073.600 Pixel

also gut zwei Millionen Pixel.

Ein Bild mit:

3840 × 2160

besitzt:

8.294.400 Pixel

also mehr als acht Millionen.

Mehr Pixel bedeuten mehr räumliche Bildinformation

Grundsätzlich kann ein Bild mit mehr Pixeln feinere Details enthalten.

wenige Pixel
↓
weniger räumliche Information

viele Pixel
↓
mehr mögliche Details

Das Wort mögliche ist wichtig.

Ein unscharfes Foto bleibt auch mit 40 Megapixeln unscharf.

Pixelzahl ist nicht dasselbe wie Bildqualität

Ein Bild kann sehr viele Pixel besitzen und trotzdem schlecht aussehen.

Zum Beispiel durch:

Bewegungsunschärfe,

falschen Fokus,

starkes Rauschen,

schlechte Optik,

Kompressionsartefakte.

Darum gilt:

hohe Pixelzahl
≠
automatisch hohe Bildqualität

Auflösung ist nur eine Dimension von Qualität.

Was sind Megapixel?

Mega bedeutet eine Million.

Ein Megapixel entspricht ungefähr:

1.000.000 Pixel

Eine Kamera mit 24 Megapixeln erzeugt also Bilder mit ungefähr 24 Millionen Bildpunkten.

Beispiel

Ein Bild mit:

6000 × 4000

besitzt:

24.000.000 Pixel

also:

24 Megapixel

Megapixel sagen wenig über die benötigte Websitegröße aus

Eine moderne Kamera kann 24, 40 oder noch mehr Megapixel liefern.

Eine typische Artikelabbildung auf einer Website benötigt davon nur einen Bruchteil.

Wenn ein Bild beispielsweise maximal:

1200 Pixel

breit dargestellt wird, braucht der Browser nicht zwangsläufig eine 6000-Pixel-Datei.

Originalauflösung und Auslieferungsauflösung sind zwei verschiedene Dinge

Das ist einer der wichtigsten Grundsätze.

Kamera
↓
6000 × 4000
↓
Master

für die Website:

Master
↓
1600 × 1067
↓
Webversion

Das hochauflösende Original bleibt erhalten.

Die Website erhält eine passend dimensionierte Ableitung.

Auflösung ist nicht Dateigröße

Ein häufiger Irrtum:

Ein Bild mit doppelt so vielen Pixeln ist automatisch doppelt so groß in Megabyte.

So einfach ist es nicht.

Die Dateigröße hängt zusätzlich ab von:

Bildformat

Kompression

Bildinhalt

Farbtiefe

Metadaten

Zwei gleich große Bilder können völlig unterschiedliche Dateigrößen besitzen

Beispiel:

Beide Bilder:

1920 × 1080 Pixel

Bild A:

einfache Grafik mit großen einfarbigen Flächen.

Bild B:

Foto eines Waldes mit tausenden Blättern und feinen Details.

Die Komprimierbarkeit kann sehr unterschiedlich sein.

Auch das Format spielt eine Rolle

Dasselbe 1920 × 1080 Bild könnte beispielsweise als:

PNG,

JPG,

WebP,

AVIF

sehr unterschiedliche Dateigrößen besitzen.

Das haben wir unter Bildformate fürs Web ausführlich behandelt.

Pixelabmessung beschreibt die Bilddimension

Wenn jemand sagt:

Das Bild ist 1600 × 900 Pixel groß.

ist damit die Pixelabmessung gemeint.

Nicht:

die Dateigröße auf der SSD.

Nicht:

die physische Druckgröße.

Diese Begriffe sollte man auseinanderhalten.

Drei verschiedene Größen

Ein digitales Bild kann gleichzeitig besitzen:

Pixelabmessungen
→ 1600 × 900 Pixel

Dateigröße
→ 240 KB

und vielleicht eine gespeicherte Druckinformation wie:

300 PPI

Das sind drei unterschiedliche Eigenschaften.

Was ist PPI?

PPI steht für:

Pixels Per Inch.

Also:

Pixel pro Zoll.

Ein Zoll entspricht:

2,54 Zentimetern

PPI beschreibt, wie viele Bildpixel bei einer bestimmten physischen Darstellung beziehungsweise Druckinterpretation auf einen Zoll verteilt werden.

Warum taucht PPI bei Bildern auf?

Ein Bildbearbeitungsprogramm kann beispielsweise sagen:

3000 Pixel breit

und:

300 PPI

Daraus lässt sich eine gedachte physische Breite ableiten.

3000 Pixel
÷
300 Pixel pro Zoll
=
10 Zoll

Also rund:

25,4 cm

Bei 150 PPI wäre dasselbe Pixelbild doppelt so breit

3000
÷
150
=
20 Zoll

Das Bild besitzt immer noch:

3000 Pixel

Es wird lediglich anders auf eine physische Größe bezogen.

Die PPI-Zahl erzeugt keine neuen Pixel

Das ist entscheidend.

Ein Bild:

3000 × 2000 Pixel

bleibt:

3000 × 2000 Pixel

egal, ob in seinen Metadaten steht:

72 PPI

oder:

300 PPI

solange das Bild nicht tatsächlich neu berechnet wird.

Was ist DPI?

DPI steht für:

Dots Per Inch.

Also:

Punkte pro Zoll.

Der Begriff stammt primär aus der Druckausgabe.

Ein Drucker setzt physische Punkte auf Papier.

Drucker
↓
Dots
↓
Papier

DPI beschreibt daher eigentlich die Punktdichte eines Ausgabegeräts beziehungsweise Druckprozesses.

DPI und PPI werden häufig verwechselt

Im Alltag liest man oft:

Das Bild hat 300 DPI.

Gemeint ist bei einer Bilddatei häufig eigentlich:

300 PPI

also eine Relation zwischen Bildpixeln und einer gedachten physischen Größe.

Beim tatsächlichen Druck kann der Drucker wiederum mit einer anderen DPI-Zahl arbeiten.

Für Webbilder ist DPI normalerweise nicht die entscheidende Größe

Das ist einer der häufigsten Mythen rund um Webgrafiken.

Jemand sagt:

Für Web braucht man 72 DPI.

Diese Aussage ist als allgemeine Regel irreführend.

Für die Darstellung eines Rasterbildes auf einer Website sind vor allem seine:

Pixelabmessungen

entscheidend.

Beispiel

Bild A:

1200 × 800 Pixel
72 PPI

Bild B:

1200 × 800 Pixel
300 PPI

Wenn beide auf einer Website mit:

600 CSS-Pixel Breite

angezeigt werden, besitzen sie grundsätzlich dieselbe verfügbare Pixelinformation.

Die PPI-Metadaten machen Bild B im Browser nicht automatisch schärfer.

72 DPI ist keine magische Webauflösung

Die historische Zahl 72 begegnet noch häufig in:

Grafikprogrammen,

alten Tutorials,

Designworkflows.

Für moderne Webdarstellung sollte man stattdessen fragen:

Wie viele Bildpixel besitzt die Datei?

und:

Wie groß wird sie im Layout dargestellt?

Das sind die relevanteren Fragen.

Ein Browser denkt primär in CSS-Pixeln

Im Webdesign verwenden wir beispielsweise:

width: 600px

Das bedeutet:

600 CSS-Pixel.

Das ist zunächst eine logische Layoutgröße.

Sie muss nicht exakt einem einzelnen physischen Displaypixel entsprechen.

Und genau hier wird das Thema interessanter.

CSS-Pixel und Gerätepixel sind nicht dasselbe

Moderne Displays besitzen teilweise deutlich mehr physische Pixel als die logische Weblayoutgröße vermuten lässt.

Ein Smartphone kann beispielsweise physisch:

sehr viele Pixel

besitzen.

Der Browser stellt die Website trotzdem in einer kleineren logischen CSS-Breite dar.

Warum?

Wenn ein Browser jedes physische Pixel direkt als CSS-Pixel behandeln würde, wären:

Text,

Buttons,

Navigation

auf hochauflösenden Displays winzig.

Deshalb existiert eine Abstraktion.

CSS-Pixel
↓
Browser
↓
ein oder mehrere Gerätepixel

Was ist Device Pixel Ratio?

Das Device Pixel Ratio, kurz DPR, beschreibt vereinfacht das Verhältnis zwischen CSS-Pixeln und physischen Gerätepixeln.

Bei:

DPR 1

entspricht ein CSS-Pixel ungefähr einem Gerätepixel.

Bei:

DPR 2

können für eine logische CSS-Dimension doppelt so viele physische Pixel in jeder Richtung verfügbar sein.

Beispiel mit DPR 2

Ein Bild wird angezeigt mit:

600 CSS-Pixel Breite

Auf einem Display mit:

DPR 2

kann eine Quelle mit etwa:

1200 Bildpixel Breite

die verfügbare physische Auflösung besser ausnutzen.

Deshalb kann eine 600-Pixel-Datei auf einem Retina-Display etwas weicher wirken

Layout:

600 CSS px

Quelle:

600 Bildpixel

Display:

DPR 2

Vereinfacht fehlen nun Bildpixel, um jeden verfügbaren Gerätebereich vollständig mit Originalinformation zu versorgen.

Der Browser muss das Bild skalieren.

Eine 1200-Pixel-Quelle kann dort schärfer wirken

600 CSS px
×
DPR 2
≈
1200 Bildpixel

Das ist die Grundidee hochauflösender beziehungsweise sogenannter Retina-Bilder.

„Retina“ ist kein eigenes Bildformat

Das ist wichtig.

Ein Retina-Bild ist nicht:

.jpg-retina

oder:

.webp-retina

Es ist einfach eine Rasterdatei mit ausreichend hoher Pixelauflösung für eine Darstellung auf einem hochauflösenden Display.

2x-Bilder

Früher beziehungsweise in Designworkflows begegnet häufig die Bezeichnung:

@2x

Beispiel:

logo.png

für normale Auflösung

und:

logo@2x.png

mit doppelten Pixelabmessungen.

Das Prinzip:

Anzeige 200 × 100 CSS px

Quelle:

400 × 200 Pixel

Heute können responsive Bildmechanismen diese Auswahl automatisieren

Statt manuell nur:

1x

und:

2x

vorzuhalten, kann der Browser aus mehreren Bildgrößen wählen.

480
768
1200
1600
2400

und je nach:

Layoutbreite,

Displayauflösung

eine geeignete Datei laden.

Genau dafür sind responsive Images so wichtig

Wie unter Responsive Webdesign beschrieben:

Browser
↓
kennt Viewport
+
DPR
+
Layout
↓
wählt passende Bildquelle

Das ist effizienter als allen Nutzern immer die größte Datei zu schicken.

Größere Quelle ist nicht unbegrenzt besser

Angenommen:

Bild erscheint:

600 CSS px

auf:

DPR 2

Eine:

1200-Pixel-Quelle

ist plausibel.

Eine:

6000-Pixel-Quelle

bringt dort meist kaum zusätzlichen sichtbaren Nutzen.

Sie erhöht aber:

Dateigröße,

Downloadzeit,

Dekodierungsaufwand.

Pixelüberschuss wird nicht automatisch sichtbar

Ein Display besitzt nur eine begrenzte physische Auflösung.

Sobald genügend Bildinformation vorhanden ist, können zusätzliche Pixel nicht einfach beliebig mehr Detail zeigen.

ausreichende Quelle
↓
Display ausgeschöpft

Mehr Daten darüber hinaus können reine Verschwendung sein.

Die ideale Bildgröße hängt vom tatsächlichen Layout ab

Ein Hero:

volle Contentbreite

braucht eine größere Quelle als:

kleine Card

Dasselbe Motiv sollte deshalb nicht überall mit derselben Pixelgröße ausgeliefert werden.

Beispiel Hero

Desktoplayout:

1440 CSS px breit

Auf DPR-2-Displays könnte theoretisch eine deutlich größere Bildquelle sinnvoll sein.

Aber:

Kompression,

Dateigröße,

tatsächliche Darstellung,

Crop

müssen ebenfalls berücksichtigt werden.

Es ist nicht automatisch sinnvoll, jede Hero-Datei exakt doppelt so breit anzubieten.

Beispiel Card

Card-Bild:

360 CSS px

Eine:

720-Pixel-Quelle

kann auf hochauflösenden Displays bereits sehr gut funktionieren.

Eine 4000-Pixel-Datei wäre normalerweise unnötig.

Beispiel Thumbnail

Darstellung:

120 × 80 CSS px

Quelle mit:

240 × 160 Pixel

kann bereits mehr als ausreichend sein.

Deshalb sollten Bildgrößen aus Komponenten entstehen

Nicht:

Alle Bilder 1920 Pixel breit.

Sondern:

Hero
→ eigene Größenklasse

Card
→ eigene Größenklasse

Thumbnail
→ eigene Größenklasse

Das verbindet Bildauflösung mit dem Designsystem.

WordPress arbeitet genau deshalb mit mehreren Bildgrößen

Ein Upload kann in mehreren Pixelvarianten gespeichert werden.

Konzeptionell:

Original
↓
Thumbnail
Medium
Large
weitere Größen

Damit muss beispielsweise eine kleine Card nicht das riesige Original laden.

Die Anzahl sollte trotzdem sinnvoll bleiben

Wenn für jedes Bild 25 unterschiedliche Größen erzeugt werden:

wächst der Speicherverbrauch.

Bei:

100 Bildern

noch überschaubar.

Bei:

100.000 Bildern

kann daraus eine sehr große Dateimenge werden.

Bildgrößen sollten reale Layoutbedürfnisse widerspiegeln

Beispiel:

thumbnail
card
article
hero

Das sind nachvollziehbare Rollen.

Nicht:

347px
463px
591px

nur weil irgendwann irgendein Seitenelement so breit war.

Komponenten können mehrere responsive Größen verwenden

Card:

Small
Medium
Large

je nach Raster.

Hero:

Mobile
Desktop
Wide

Das kann bereits genügen.

Was ist Downscaling?

Downscaling bedeutet:

Ein Rasterbild wird auf weniger Pixel verkleinert.

Zum Beispiel:

6000 × 4000
↓
1500 × 1000

Dabei werden viele Ausgangspixel zu weniger Zielpixeln zusammengeführt.

Beim Verkleinern gehen Details verloren

Das ist gewollt.

Die kleinere Datei braucht sie nicht mehr.

24 MP
↓
1,5 MP

Für eine Website kann diese reduzierte Auflösung vollkommen ausreichend sein.

Downscaling kann ein Bild sogar schärfer wirken lassen

Kamerabilder enthalten beispielsweise:

leichtes Rauschen,

feine Unschärfen.

Beim guten Verkleinern werden viele Informationen zusammengeführt.

Das Bild kann dadurch in seiner Zielgröße sehr sauber aussehen.

Verkleinerung ist normalerweise unproblematischer als Vergrößerung

Denn beim Downscaling existiert bereits mehr Bildinformation als benötigt.

viele Pixel
↓
weniger Pixel

Beim Upscaling dagegen fehlen Ausgangsinformationen.

wenige Pixel
↓
mehr Pixel

Diese müssen interpoliert oder generiert werden.

Was ist Upscaling?

Upscaling bedeutet:

Ein Bild wird auf höhere Pixelabmessungen gebracht.

Beispiel:

800 × 600
↓
3200 × 2400

Nun besitzt die Datei viermal so viele Pixel pro Dimension?

Nein.

Die Breite und Höhe wurden jeweils vervierfacht.

Damit steigt die gesamte Pixelzahl sogar um Faktor:

4 × 4
=
16

Woher kommen die neuen Pixel?

Ein klassischer Algorithmus berechnet sie aus den vorhandenen Nachbarpixeln.

Verschiedene Interpolationsverfahren können unterschiedliche Ergebnisse liefern.

Zum Beispiel:

weicher,

schärfer,

detailreicher.

Aber:

Sie kennen das verlorene Original nicht.

Klassisches Upscaling erzeugt keine echte ursprüngliche Information

Aus:

8 × 8 Pixel

lässt sich nicht mathematisch sicher rekonstruieren:

wie das Motiv ursprünglich bei 8000 × 8000 Pixeln aussah.

Die Information ist nicht vorhanden.

KI-Upscaling

Moderne KI-Verfahren können beim Hochskalieren plausible Details ergänzen.

Zum Beispiel:

Haarstrukturen,

Stofftexturen,

Kanten,

Oberflächen.

Konzeptionell:

kleines Bild
↓
KI-Modell
↓
plausibel hochaufgelöstes Bild

„Plausibel“ ist das entscheidende Wort

KI kann Details erfinden.

Sie kann nicht garantieren:

So sah das ursprüngliche Detail tatsächlich aus.

Das ist bei:

künstlerischen Bildern

oft unproblematisch.

Bei:

Dokumentation,

Beweismaterial,

wissenschaftlichen Aufnahmen

kann es kritisch sein.

KI-Upscaling eignet sich besonders für visuelle Nutzung

Zum Beispiel:

alte Illustrationen,

KI-generierte Bilder,

Fotos für redaktionelle Zwecke,

Texturen.

Dabei zählt:

sieht das Ergebnis überzeugend aus?

Für exakte Information muss man vorsichtig sein

Ein Kennzeichen.

Eine Seriennummer.

Feiner Text.

Ein medizinisches Detail.

KI kann daraus plausibel aussehende, aber falsche Informationen erzeugen.

Upscaling ist hier keine Wahrheitsmaschine.

Upscaling und Inpainting unterscheiden sich

Upscaling:

gesamtes Bild
↓
höhere Auflösung

Inpainting:

bestimmter Bereich
↓
generativ verändern

Beide Verfahren können kombiniert werden.

Beispiel KI-Bildpipeline

Text-to-Image
↓
1024 × 1024
↓
Auswahl
↓
Inpainting
↓
Upscaling
↓
Webvarianten

Das ist oft effizienter, als jeden Kandidaten sofort extrem hochaufgelöst zu erzeugen.

Warum?

Angenommen, du erzeugst vier Bildvarianten.

Nur eine wird verwendet.

Wenn jede sofort sehr hoch aufgelöst berechnet wird:

4 × hohe GPU-Kosten

Stattdessen:

4 Vorschauen
↓
1 auswählen
↓
nur diese hochskalieren

Das spart Rechenleistung.

Webauflösung und KI-Generierungsauflösung sind zwei verschiedene Dinge

Ein Bildmodell erzeugt vielleicht:

1024 × 1024

Die Website braucht für einen breiten Hero:

1800 × 1000

Dann kann der Workflow:

Outpainting,

Upscaling,

Cropping

verwenden.

Die Zielauflösung sollte aus dem Layout kommen.

Was ist Resampling?

Wenn sich die Pixelabmessungen eines Bildes verändern, muss die Bildinformation neu auf ein Raster verteilt werden.

Das bezeichnet man als:

Resampling.

altes Pixelraster
↓
Berechnung
↓
neues Pixelraster

PPI ändern ohne Resampling

Ein Bildbearbeitungsprogramm kann unter Umständen nur die PPI-Metadaten ändern.

Beispiel:

3000 × 2000 Pixel
72 PPI

wird zu:

3000 × 2000 Pixel
300 PPI

Die Pixelmenge bleibt identisch.

Nur die gedachte physische Größe verändert sich.

PPI ändern mit Resampling

Wenn zusätzlich eine feste Druckgröße beibehalten werden soll, kann das Programm tatsächlich neue Pixel berechnen.

Dann verändert sich die Pixelabmessung.

Das sind zwei völlig unterschiedliche Vorgänge.

Genau deshalb entsteht viel DPI-Verwirrung

Menschen ändern im Bildprogramm:

72
↓
300

und glauben:

Das Bild habe nun mehr Qualität.

Wenn die Pixelzahl gleich blieb:

hat es keine zusätzliche Bildinformation erhalten.

Beispiel

Vorher:

1200 × 800 Pixel
72 PPI

Nachher:

1200 × 800 Pixel
300 PPI

Für den Browser:

praktisch dasselbe Rasterbild.

Wenn dagegen resampled wird

Vorher:

1200 × 800

nachher eventuell:

5000 × 3333

Nun sind tatsächlich mehr Pixel vorhanden.

Diese wurden allerdings berechnet.

Nicht aus echter neuer Kameraaufnahme gewonnen.

Die richtige Frage für Web lautet daher fast immer

Nicht:

Wie viel DPI?

sondern:

Welche Pixelabmessungen?

und:

Welche Darstellungsgröße?

Wie groß sollte ein Websitebild sein?

Es gibt keine universelle Zahl.

Die richtige Größe hängt davon ab:

Layoutbreite

Device Pixel Ratio

Crop

Kompression

Bildtyp

Beispiel Artikelbild

Angenommen, die Textspalte ist maximal:

900 CSS-Pixel

breit.

Dann ist eine Quelle mit deutlich mehr als:

900 Pixel

nicht völlig unnötig, weil hochauflösende Displays existieren.

Aber eine:

6000-Pixel-Datei

ist normalerweise überdimensioniert.

Ein praktischer Ansatz

Für jede Bildkomponente wird festgelegt:

maximale Darstellungsbreite

Dann erstellt man mehrere sinnvolle Quellgrößen.

Zum Beispiel:

480
768
1200
1600

Der Browser kann wählen.

Damit muss man nicht exakt eine perfekte Zahl erraten

Responsive Images lösen dieses Problem elegant.

kleiner Client
→ kleine Quelle

größerer Client
→ größere Quelle

Was ist srcset?

srcset erlaubt vereinfacht, mehrere Bildressourcen mit ihren Breiten anzubieten.

Konzeptionell:

bild-480.webp
bild-768.webp
bild-1200.webp
bild-1600.webp

Der Browser erhält Informationen darüber, welche Varianten existieren.

sizes

Zusätzlich kann angegeben werden, wie breit das Bild im Layout voraussichtlich dargestellt wird.

Dadurch kann der Browser besser entscheiden:

Welche Quelle passt?

Warum der Browser entscheiden sollte

Er kennt unter anderem:

Viewport,

Device Pixel Ratio,

Layoutbedingungen.

Dadurch kann er eine sinnvollere Auswahl treffen als ein starrer Server, der nur sagt:

„Mobil oder Desktop“.

Responsive Images sind keine reine Desktop-vs-Mobile-Lösung

Es gibt:

kleine Smartphones,

große Smartphones,

Tablets,

kleine Laptops,

große Monitore,

unterschiedliche DPR-Werte.

Eine flexible Auswahl skaliert besser.

Was ist sizes konzeptionell?

Beispiel:

Auf Desktop nimmt das Bild:

50 % der Viewportbreite

Mobil:

100 %

Diese Information hilft bei der Quellenwahl.

WordPress kann srcset automatisch erzeugen

Wenn passende Bildgrößen vorhanden sind, kann WordPress responsive Quellinformationen in die Bildausgabe integrieren.

Damit ist ein großer Teil der Infrastruktur bereits vorhanden.

Aber nur, wenn:

passende Größen erzeugt

und:

korrekt verwendet

werden.

Das Original darf nicht versehentlich die einzige Quelle sein

Wenn ein Theme immer hart:

full

verwendet und keine sinnvollen Größen berücksichtigt, können unnötig große Dateien ausgeliefert werden.

Theme-Entwicklung und Bildauflösung gehören zusammen

Das Theme weiß:

Wie breit sind:

Hero,

Card,

Artikelbild,

Thumbnail?

Diese Informationen sollten die Bildgrößen bestimmen.

Layoutänderungen können neue Bildgrößen erforderlich machen

Relaunch:

Cards werden statt:

280 px

nun:

520 px

breit.

Bestehende kleine Derivate könnten zu unscharf sein.

Dann kann man aus den Masters neue Größen generieren.

Deshalb Master erhalten

Wieder zeigt sich der Wert dieser Architektur:

Master
↓
neues Theme
↓
neue Derivate

Ohne Master müsste man kleine Bilder hochskalieren.

Wie erkennt man ein zu kleines Bild?

Typische Symptome:

weich

pixelig

unscharfe Kanten

Details fehlen

Besonders sichtbar bei:

Text im Screenshot,

feinen Linien,

Gesichtern.

Ein zu großes Bild sieht dagegen nicht unbedingt sichtbar besser aus

Es lädt nur:

langsamer

und benötigt:

mehr Daten.

Das Problem ist eher Performance als Darstellung.

Was bedeutet Pixel Density?

Pixel Density beschreibt die Dichte physischer Pixel eines Displays.

Häufig wird dafür ebenfalls PPI verwendet.

Hier bezeichnet PPI tatsächlich:

physische Displaypixel pro Zoll.

Das ist wieder ein anderer Kontext als die gespeicherte PPI-Angabe in einer Bilddatei.

Ein Smartphone kann sehr hohe Display-PPI besitzen

Weil viele physische Pixel auf kleiner Fläche liegen.

Ein großer Desktopmonitor kann bei ähnlicher Auflösung deutlich weniger Pixel pro Zoll besitzen.

Hohe Display-PPI macht Pixel schwerer sichtbar

Das Bild wirkt:

feiner,

glatter,

schärfer.

Genau deshalb verwenden moderne Geräte Skalierungsmechanismen.

Physische Display-PPI und Bild-PPI nicht verwechseln

Bilddatei:

300 PPI Metadaten

Display:

physisch beispielsweise hohe Pixeldichte

Das sind verschiedene Konzepte.

Der Browser übersetzt über CSS-Layout und Geräteskalierung dazwischen.

Warum 300-PPI-Webbilder keinen besonderen Vorteil haben

Wenn zwei Dateien beide:

1200 × 800 Pixel

besitzen, aber unterschiedliche PPI-Metadaten:

72 PPI

und:

300 PPI

ist die verfügbare Rasterinformation identisch.

Der Browser kann beide mit derselben CSS-Breite anzeigen.

Für Print ist PPI dagegen wichtig

Nun besitzt das Bild eine physische Zielgröße.

Beispiel:

3000 Pixel

Breite.

Bei:

300 PPI

ergibt das etwa:

10 Zoll

Bei:

150 PPI

etwa:

20 Zoll

Je größer das Bild gedruckt wird, desto weniger Pixel stehen pro Zoll zur Verfügung.

Betrachtungsabstand beeinflusst notwendige Druckauflösung

Ein kleines hochwertiges Fotobuch wird aus kurzer Distanz betrachtet.

Ein großes Werbeplakat aus mehreren Metern Entfernung.

Das Plakat braucht deshalb nicht zwangsläufig dieselbe Pixelzahl pro Zoll wie ein Fotoabzug.

300 PPI ist auch im Druck keine universelle Naturkonstante

Es ist ein verbreiteter Wert für bestimmte hochwertige Druckanwendungen.

Die tatsächliche sinnvolle Auflösung hängt ab von:

Druckverfahren,

Papier,

Betrachtungsabstand,

Motiv.

Für Web und Print deshalb getrennte Derivate

Master:

hochwertig.

Dann:

Webversion
→ Pixelabmessungen fürs Display

Printversion
→ Pixelabmessungen passend zur physischen Größe

Dasselbe Original kann beide bedienen.

Was ist Seitenverhältnis?

Auflösung und Seitenverhältnis werden häufig verwechselt.

Bild:

1920 × 1080

hat Verhältnis:

16:9

Bild:

3840 × 2160

ebenfalls:

16:9

Die Auflösung ist unterschiedlich.

Die Form gleich.

Seitenverhältnis bestimmt den Bildausschnitt

Ein:

1:1

-Bild ist quadratisch.

16:9

breit.

4:5

hochformatiger.

Für Websitekomponenten ist das Verhältnis oft wichtiger als eine einzelne exakte Pixelzahl.

Beispiel Card

Designsystem:

Card Image
→ 3:2

Nun können verschiedene Pixelgrößen erzeugt werden:

450 × 300

900 × 600

1350 × 900

Alle besitzen dasselbe Ratio.

Auflösung und Ratio gehören gemeinsam ins Media-Preset

Zum Beispiel:

{
  "preset": "article-card",
  "ratio": "3:2",
  "widths": [480, 768, 1200]
}

Das System weiß nun:

Form

und:

Quellgrößen.

Ein Hero kann ein anderes Ratio besitzen

{
  "preset": "hero",
  "ratio": "16:9",
  "widths": [768, 1200, 1600, 2000]
}

Die konkreten Werte sind nur ein Beispiel.

Das Prinzip ist wichtig.

Mobile kann eine andere Komposition benötigen

Desktop:

16:9

Mobil:

4:5

Dann reicht nicht nur eine kleinere Auflösung.

Man braucht möglicherweise einen anderen Crop.

Das ist Art Direction

gleiches Motiv
↓
anderer Bildausschnitt
↓
anderes Gerät

Damit bleibt das Motiv auf kleinen Displays sinnvoll.

Automatisches Center Crop kann scheitern

Foto:

Person steht ganz rechts.

Automatisches quadratisches Crop:

Mitte.

Ergebnis:

Person verschwindet.

Deshalb braucht ein gutes Asset-System:

Fokuspunkt

oder:

separate Crops.

Focal Point

Ein Bild kann speichern:

wichtiges Motiv befindet sich hier

Dann kann automatisches Cropping stärker darauf Rücksicht nehmen.

Das ist besonders für:

Menschen,

Produkte,

Objekte

nützlich.

KI kann Fokusinformationen unterstützen

Ein Vision-System könnte erkennen:

Wo ist das Hauptmotiv?

Dann:

Motiverkennung
↓
Focal Point
↓
Crop

Aber wichtige Assets sollten trotzdem überprüft werden.

Automatische Erkennung kann Fehler machen.

Bildauflösung und Text in Bildern

Ein Screenshot oder eine Infografik enthält möglicherweise Schrift.

Wenn die Datei zu stark verkleinert wird:

wird Text unlesbar.

Solche Bilder brauchen oft höhere Auflösung als rein atmosphärische Fotografie.

Deshalb nicht nur Pixelzahl nach Fläche bestimmen

Bildinhalt zählt.

Foto
→ kleine Detailverluste oft tolerierbar

Screenshot mit 12-Pixel-Text
→ Detailverlust kritisch

UI-Screenshots besser passend aufnehmen

Wenn möglich:

Screenshot in sinnvoller Ausgangsgröße erstellen.

Nicht:

kleinen Screenshot später massiv hochskalieren.

Screenshots auf Retina-Displays

Ein Screenshot kann physisch mehr Pixel besitzen als seine logische CSS-Größe.

Das kann für Dokumentation sehr nützlich sein.

Wird er im Artikel kleiner dargestellt, bleibt Text scharf.

Aber Dateigröße beachten

Ein kompletter 5K-Desktop-Screenshot als PNG:

kann enorm groß sein.

Besser:

relevanten Bereich zuschneiden

und:

passend exportieren.

Crop vor Resize

Wenn nur ein kleiner Bereich benötigt wird:

großer Screenshot
↓
relevanten Bereich croppen
↓
dann skalieren

Das erhält mehr Detail im wichtigen Bereich.

Bildauflösung und Logos

Ein Rasterlogo in:

200 × 80 Pixel

kann auf großen oder hochauflösenden Displays unscharf wirken.

Deshalb ist für Logos häufig SVG die bessere Lösung.

Vektoren besitzen keine feste Pixelauflösung

Ein SVG beschreibt Formen.

Der Browser kann daraus:

100 Pixel,

500 Pixel,

2000 Pixel

breite Darstellungen rendern.

Deshalb entfällt das klassische Auflösungsproblem weitgehend.

Trotzdem gibt es bei SVG Darstellungsgrößen

Ein SVG kann im Layout:

200 CSS px

breit sein.

Aber seine interne Geometrie ist nicht auf ein fixes Raster beschränkt.

Rastereffekte innerhalb von SVG

Ein SVG kann theoretisch eingebettete Rasterbilder enthalten.

Dann gelten für diese Teile wieder normale Pixelgrenzen.

Nicht jedes .svg ist automatisch vollständig vektorbasiert.

Bildauflösung und Icons

Für einfache UI-Icons:

SVG.

Das vermeidet:

1x,

2x,

3x

Rastervarianten.

Gerade für Designsysteme ist das sehr praktisch.

Wann Rastericons noch sinnvoll sein können

Zum Beispiel:

pixelbasierte Kunst,

komplexe gerenderte Symbole,

bestimmte Markenassets.

Aber für einfache Linienicons ist Vektor meist flexibler.

Bildauflösung und LCP

Große Hero-Bilder können für die wahrgenommene Ladegeschwindigkeit relevant sein.

Eine unnötig große Datei kann deshalb Core Web Vitals negativ beeinflussen.

Das größte sichtbare Bild braucht besondere Aufmerksamkeit

Nicht:

extrem klein und unscharf.

Aber auch nicht:

12 MB groß.

Gesucht wird:

ausreichende Auflösung
+
effiziente Kompression

Zu kleine Quelle kann ebenfalls schlechte UX sein

Performanceoptimierung darf nicht bedeuten:

alle Bilder aggressiv verkleinern.

Ein verschwommenes Produktfoto senkt:

Vertrauen,

Informationswert,

ästhetische Qualität.

Optimierung ist ein Gleichgewicht

zu groß
→ langsam

zu klein
→ unscharf

passend
→ schnell + scharf

Das ist das Ziel.

Was bedeutet intrinsische Bildgröße?

Eine Rasterdatei besitzt eigene Pixelabmessungen.

Beispiel:

1200 × 800

Das ist ihre intrinsische Rastergröße.

CSS kann sie anschließend:

kleiner

oder:

größer

anzeigen.

Kleiner anzeigen

Quelle:
1200 px

Anzeige:
600 CSS px

meist problemlos.

Größer anzeigen

Quelle:
600 px

Anzeige:
1200 CSS px

führt zu Upscaling im Browser.

Das Bild kann sichtbar unscharf werden.

Deshalb gilt als einfache Regel

Eine Rasterquelle sollte für ihren vorgesehenen Einsatz nicht kleiner sein als die benötigte Ausgabeauflösung.

Bei hochauflösenden Displays kann etwas zusätzliche Reserve sinnvoll sein.

Aber Reserve ist nicht unbegrenzt

benötigt ungefähr 1200
↓
Quelle 1400–1800

kann plausibel sein.

Quelle 8000

meist nicht.

Bildauflösung und Zoom

Ein Nutzer kann Browserzoom verwenden.

Nun wird das Bild größer dargestellt.

Eine höher aufgelöste Quelle kann dann zusätzliche Schärfe bieten.

Responsive Images und Browsermechanismen helfen dabei.

Man muss nicht jeden Extremzoom perfekt mit Rasterdaten bedienen

Bei 500 % Zoom kann auch ein normales Webfoto irgendwann Pixel zeigen.

Das ist nicht zwangsläufig ein Fehler.

Text und UI sollten dagegen wesentlich flexibler skalieren können.

Bilder mit kritischer Detailinformation

Bei:

Karten,

technischen Diagrammen,

Scans,

Dokumenten

kann Zoom wichtig sein.

Dann sollten entweder:

hochaufgelöste Quellen

oder:

Vektoren

bereitstehen.

Deep Zoom

Sehr große Bilder wie:

historische Karten,

Gemälde,

Mikroskopaufnahmen

können in Kacheln zerlegt werden.

riesiges Bild
↓
viele Tiles
↓
nur sichtbare Ausschnitte laden

Damit muss nicht das komplette Gigapixel-Bild übertragen werden.

Für normale Websites meist unnötig

Aber das Prinzip zeigt:

Auch extrem hohe Auflösung lässt sich effizient ausliefern, wenn die Architektur darauf abgestimmt ist.

Auflösung in Fotografie

Kameras erzeugen hochauflösende Master.

Die zusätzliche Auflösung bietet Spielraum für:

Cropping,

Druck,

Nachbearbeitung.

Sie muss aber nicht vollständig ins Web gelangen.

Cropping verbraucht Auflösungsreserve

Original:

6000 × 4000

Du schneidest nur ein Viertel der Fläche aus.

Übrig bleiben ungefähr deutlich weniger Pixel.

Die große Ausgangsauflösung kann dann nützlich sein.

Digitaler Zoom ist im Grunde Crop plus Vergrößerung

Wenn eine Kamera keinen optischen Zoom verwendet, sondern nur einen Ausschnitt vergrößert:

verliert man effektive Auflösung.

Das sollte bei Ausgangsmaterial berücksichtigt werden.

Sensorauflösung ist nicht optische Auflösung

Eine Kamera mit sehr vielen Megapixeln kann nur dann tatsächliche feine Details liefern, wenn:

Objektiv,

Fokus,

Sensor,

Aufnahmebedingungen

diese Information ebenfalls erfassen.

Pixelzahl ist nicht alles.

Rauschen beeinflusst effektive Detailqualität

Bei schlechten Lichtbedingungen kann ein hochauflösendes Bild stark rauschen.

Eine kleinere, gut verarbeitete Ausgabe kann angenehmer wirken.

Wieder:

mehr Pixel ist nicht automatisch besser.

KI-Bildmodelle und native Auflösung

Generative Modelle arbeiten häufig besonders gut in bestimmten Größenbereichen.

Sehr große direkte Generierungen können:

mehr Rechenleistung,

mehr VRAM

benötigen.

Darum kann eine Pipeline sinnvoll sein:

Generierung
↓
Auswahl
↓
Upscaling
↓
Webderivate

statt sofort jede Variante maximal groß zu erzeugen.

Lokale Bild-KI

Bei lokaler Bild-KI beeinflusst Auflösung unmittelbar:

GPU-Speicher,

Rechenzeit,

Durchsatz.

höhere Auflösung
↓
mehr Rechenarbeit
↓
häufig mehr VRAM

Doppelte Breite und Höhe bedeuten vierfache Pixelzahl

Beispiel:

1024 × 1024
≈ 1 Megapixel

gegen:

2048 × 2048
≈ 4 Megapixel

Die Breite wurde verdoppelt.

Die Höhe ebenfalls.

Die Gesamtpixelmenge vervierfacht sich.

4096 × 4096

Nun:

≈ 16,8 Megapixel

Gegenüber 1024 × 1024:

ungefähr sechzehnfache Pixelzahl.

Das erklärt, warum hohe Auflösungen schnell teuer werden.

Direkte Generierung ist nicht immer die effizienteste Lösung

Vielleicht benötigt die Website final:

1600 Pixel

Breite.

Dann muss das Bildmodell nicht zwangsläufig:

4096 Pixel

direkt erzeugen.

Ein kleinerer guter Master plus Upscaling kann effizienter sein.

Aber Upscaling kann Stil verändern

KI-Upscaler können:

Texturen ergänzen,

Gesichter verändern,

Details erfinden.

Deshalb sollte das Ergebnis kontrolliert werden.

Für Illustrationen kann das sogar erwünscht sein

Ein Upscaler kann:

Linien,

Materialtexturen,

feine Details

verbessern.

Bei einem Produktbild kann dieselbe kreative Veränderung unerwünscht sein.

Exakte Produkte besser konservativ skalieren

Wenn Produktform und Details exakt bleiben müssen:

klassisches Resampling

oder speziell getestete konservative Verfahren

sind sicherer als stark generatives Upscaling.

Auflösung und Dateiformat zusammen denken

Große Auflösung plus verlustfreies PNG:

kann enorm groß sein.

Große Auflösung plus effizient komprimiertes AVIF:

deutlich kleiner.

Aber:

unnötig viele Pixel

bleiben unnötig.

Formatoptimierung ersetzt keine Dimensionsoptimierung.

Beste Reihenfolge

Motiv auswählen
↓
Crop bestimmen
↓
Zielauflösung festlegen
↓
Resize
↓
Format wählen
↓
komprimieren

Das ist meist sinnvoller als:

riesiges Original
↓
nur anderes Format

Warum ein 8K-WebP trotzdem schlecht optimiert sein kann

Angenommen:

7680 × 4320

wird als WebP gespeichert.

Dateigröße vielleicht deutlich kleiner als PNG.

Aber dargestellt wird:

400 × 225

Dann wurden weiterhin massiv mehr Pixel übertragen als benötigt.

Das richtige Format löst das falsche Maß nicht

Genau wie:

ein sparsamer Motor

ein unnötig schweres Fahrzeug

nicht vollständig kompensiert.

Man braucht beide Ebenen:

Dimension

und:

Kompression.

Bildauflösung in WordPress planen

Eine robuste Strategie beginnt mit dem Theme.

Welche Bildrollen existieren?

Hero

Article

Card

Thumbnail

Avatar

Dann maximale Layoutbreiten bestimmen

Zum Beispiel konzeptionell:

Hero
→ breit

Article
→ mittel

Card
→ kleiner

Thumbnail
→ klein

Dann responsive Quellgrößen definieren

Nicht für jede Rolle zehn Varianten.

Sondern ausreichend, um typische Sprünge abzudecken.

Dann geeignete Formate erzeugen

Wie im Artikel zu Bildformaten beschrieben:

Foto:

moderne komprimierte Rasterformate.

Logo:

SVG.

Screenshot:

saubere Rasterkompression.

Dann Browser wählen lassen

Responsive Bildquellen.

Dann messen

Welche Dateien werden in echten Seiten tatsächlich geladen?

Browserentwicklertools helfen dabei.

Ein typischer Fehler

Der Entwickler hat responsive Bilder eingerichtet.

Aber CSS zeigt ein Bild viel größer als angenommen.

Nun lädt der Browser plötzlich immer die größte Variante.

Das System funktioniert technisch korrekt.

Das Layout ist nur anders als geplant.

Deshalb reale Seiten messen

Nicht nur Media Library ansehen.

Sondern:

Viewport
↓
Elementbreite
↓
geladene Quelle
↓
Dateigröße

prüfen.

Performancebudget für Bilder

Man kann grobe Zielbereiche definieren.

Nicht als universelles Gesetz.

Sondern als Alarmgrenze.

Beispiel:

Thumbnail außergewöhnlich groß?
→ prüfen

Hero mehrere Megabyte?
→ prüfen

Automatische Systeme können solche Ausreißer erkennen.

Bildgrößenanalyse automatisieren

Ein Worker könnte prüfen:

{
  "display_width": 420,
  "source_width": 4000,
  "file_size_kb": 2800
}

Dann:

wahrscheinlich überdimensioniert

Oder umgekehrt

{
  "display_width": 1200,
  "source_width": 480
}

Dann:

wahrscheinlich zu klein

Solche technischen Regeln lassen sich gut automatisieren.

Device Pixel Ratio berücksichtigen

Die Prüfung könnte konservativer sein:

empfohlene_source_width
≈
display_width × ziel_DPR

mit sinnvollen Obergrenzen.

Nicht jeder Fall braucht exakt DPR 3 oder 4.

Sonst steigen Dateien unnötig stark.

Mehr ist irgendwann ineffizient

Besonders bei Fotos.

Der sichtbare Unterschied zwischen:

2x

und:

3x

kann klein sein.

Der Datensprung erheblich.

Deshalb lohnt reale Qualitätsprüfung.

Nutzungsdaten helfen

Wenn fast alle Besucher:

DPR 2

verwenden, kann die Pipeline darauf optimiert werden.

Wenn viele ältere Displays verwendet werden:

kann eine andere Gewichtung sinnvoll sein.

Trotzdem Browserauswahl bevorzugen

Responsive Quellgrößen erlauben Flexibilität, ohne Besucher in starre Gerätegruppen einzuteilen.

Auflösung und Bandbreite

Ein größerer Bildschirm bedeutet nicht automatisch:

schnelle Verbindung.

Ein großer Laptop kann über:

langsamen Hotspot

online sein.

Der Browser kann deshalb unter Umständen weitere Faktoren bei Ressourcenentscheidungen berücksichtigen.

Das ist ein weiterer Grund, nicht überall die maximale Quelle zu erzwingen.

Auflösung und Lazy Loading

Ein Bild weit unten im Artikel wird zunächst möglicherweise gar nicht geladen.

Wenn es später benötigt wird:

sollte trotzdem die passende Auflösung gewählt werden.

Lazy Loading und Responsive Images ergänzen sich.

Hero-Bilder nicht blind lazy laden

Wenn das wichtigste sichtbare Bild erst verspätet angefordert wird:

kann die wahrgenommene Ladezeit leiden.

Das ist eine Priorisierungsfrage, keine reine Auflösungsfrage.

Auflösung und Layout Shift

Die Pixelabmessungen eines Bildes liefern das Seitenverhältnis.

Wenn der Browser diese Relation kennt:

kann er den benötigten Platz reservieren.

Bild noch nicht geladen
↓
Platz bereits vorhanden
↓
Layout bleibt stabil

Das unterstützt gute Core Web Vitals.

Breite und Höhe im Markup sind deshalb nützlich

Sie bedeuten nicht zwangsläufig:

Das Bild wird exakt in dieser physischen Größe dargestellt.

CSS kann es weiterhin responsiv skalieren.

Die Informationen helfen aber bei der Seitengeometrie.

Bildauflösung und CMS-Metadaten

Ein CMS sollte zu jedem Rasterasset idealerweise kennen:

Breite

Höhe

Seitenverhältnis

Dateigröße

Format

Damit lassen sich:

Layout,

Optimierung,

Validierung

automatisieren.

Asset Registry

Beispiel:

{
  "asset_id": "img_4711",
  "master_width": 4096,
  "master_height": 2731,
  "ratio": 1.5,
  "format": "png"
}

Daraus kann ein Bildservice ableiten:

Welche Varianten sind möglich?

Zu kleines Master erkennen

Ein Hero-Preset braucht beispielsweise deutlich mehr Breite als das vorhandene Master besitzt.

Der Workflow kann dann warnen:

Masterauflösung reicht nicht

statt still ein unscharfes Ergebnis zu erzeugen.

Oder Upscaling gezielt anbieten

zu kleines Master
↓
klassisch hochskalieren?
KI-Upscaling?
anderes Bild?

Der Mensch beziehungsweise die Policy entscheidet.

Automatisierte Entscheidung nach Bildtyp

Fotografie
→ konservatives Upscaling möglich

KI-Illustration
→ generatives Upscaling erlaubt

Dokumentscan
→ keine erfundenen Details

Solche Regeln können im Workflow hinterlegt werden.

Nicht jedes Bild darf gleich behandelt werden

Das ist bei automatisierter Medienproduktion entscheidend.

Bildklasse
↓
Auflösungsstrategie

Zum Beispiel:

photo

screenshot

diagram

logo

ai_illustration

Logo

Wenn SVG vorhanden:

kein Raster-Upscaling nötig.

Screenshot

Keine generative Detailerfindung, wenn er Software dokumentiert.

KI-Illustration

Generatives Upscaling kann akzeptabel sein.

Produktfoto

Identität und Geometrie müssen erhalten bleiben.

Auflösung ist also auch eine Qualitätsregel

Nicht nur:

Zahl.

Sondern:

Was darf beim Skalieren mit dem Inhalt passieren?

Bildauflösung und Archivierung

Masterdateien können relativ groß sein.

Das ist in Ordnung.

Das Archiv hat eine andere Aufgabe als die Website.

Archiv
→ Qualität und Zukunftssicherheit

Website
→ effiziente Auslieferung

Diese Ziele sollten nicht vermischt werden.

Ein 30-MB-Master ist nicht automatisch ein Problem

Wenn er:

nur einmal im Storage liegt

und:

nie direkt an Nutzer ausgeliefert wird.

Problematisch wird es, wenn genau diese Datei bei jedem Seitenaufruf übertragen wird.

Storage ist billiger als Bandbreite und langsame UX

Nicht in jedem Infrastrukturmodell, aber konzeptionell:

Ein großer Master einmal gespeichert

ist oft sinnvoller als:

dauerhaft schlechte Ausgangsqualität.

Webderivate können jederzeit neu erzeugt werden

Wenn das Master erhalten bleibt.

Heute:

WebP

Morgen:

anderes Format.

Oder:

neue Größen.

Master
↓
neue Pipeline
↓
neue Derivate

Das macht das System zukunftsfähiger

Bildauflösung ist deshalb eng mit Assetmanagement verbunden.

Dateiname sollte nicht die Auflösung als einzige Identität tragen

Schlecht:

bild-1600-final.webp

besser:

Asset-ID plus Derivatrolle.

Konzeptionell:

asset_4711
├── hero-1600
├── card-768
└── thumb-320

Damit bleibt nachvollziehbar:

Was gehört zusammen?

Bildauflösung und Social Media

Eine Website kann ihre eigenen responsive Größen besitzen.

Social Networks erwarten dagegen oft bestimmte feste Formate beziehungsweise Mindestdimensionen.

Dafür sollte ein eigenes Preset existieren.

Website Hero
≠
Social Preview

Dasselbe Motiv kann unterschiedliche Ableitungen besitzen.

Open-Graph-Bild

Ein Social-Preview-Bild wird nicht wie ein normales responsives Websitebild behandelt.

Es wird von externen Plattformen abgerufen und häufig selbst weiterverarbeitet.

Deshalb ist ein eigenes robustes Derivat sinnvoll.

Newsletter

Auch E-Mail kann andere Größenanforderungen besitzen.

Ein Asset-System kann deshalb:

Website

Social

E-Mail

Print

getrennte Ausgaben erzeugen.

Das Master bleibt gemeinsam

Master
├── Web
├── Social
├── Mail
└── Print

Das ist die saubere Architektur.

Häufige Mythen über Bildauflösung

„Webbilder brauchen 72 DPI“

Nein.

Entscheidend sind primär:

Pixelabmessungen

und:

Darstellungsgröße.

Die gespeicherte PPI-Angabe ist für normale Browserdarstellung nicht die entscheidende Qualitätsgröße.

„300 DPI sieht im Browser besser aus“

Nicht, wenn die Pixelabmessungen identisch sind.

1200 × 800 bei 72 PPI

und:

1200 × 800 bei 300 PPI

besitzen dieselbe Rasterpixelzahl.

„Mehr Megapixel sind immer besser“

Nicht für jeden Einsatzzweck.

Mehr Pixel können:

Croppingreserve,

Druckreserve

bringen.

Für ein kleines Thumbnail sind sie unnötig.

„Ein Bild mit höherer Auflösung ist automatisch größer in MB“

Nicht zwingend.

Format und Kompression spielen eine große Rolle.

„Ein 500-Pixel-Bild kann durch 300 DPI druckfähig gemacht werden“

Eine Änderung der PPI-Zahl ohne echte neue Pixel erzeugt keine zusätzliche Detailinformation.

„KI-Upscaling stellt verlorene Details wieder her“

Es kann plausible Details erzeugen.

Nicht garantieren, dass dies die ursprünglichen Details waren.

„Retina braucht immer exakt doppelte Bilder“

Doppelte Auflösung ist ein nützlicher Denkansatz.

Moderne responsive Bildauslieferung kann aber mehrere Größen flexibel anbieten.

„SVG braucht ebenfalls Retina-Versionen“

Echte Vektorgrafiken können unabhängig von einer festen Rasterauflösung skaliert werden.

Deshalb ist @2x dort normalerweise unnötig.

Häufige praktische Fehler

6000-Pixel-Foto
→ direkt in WordPress
→ im Layout 300 Pixel breit

unnötige Datenmenge.

400-Pixel-Bild
→ Hero 1400 Pixel breit

unscharf.

Logo als 200-Pixel-JPG

statt verfügbarer Vektordatei.

PPI von 72 auf 300 ändern
→ Qualität angeblich verbessert

Missverständnis.

kleine komprimierte Webdatei
→ als neues Master verwenden

Qualitätsverlust.

Ein besserer Workflow

Original
↓
Master archivieren
↓
Einsatzzweck bestimmen
↓
Seitenverhältnis wählen
↓
Crop
↓
Zielauflösungen erzeugen
↓
Format und Kompression
↓
responsive Auslieferung

Das ist die Grundlage einer professionellen Bildpipeline.

Wie bestimmt man die Zielauflösung?

Zuerst:

Wie breit erscheint das Bild maximal?

Dann:

Welche hochauflösenden Displays wollen wir sinnvoll bedienen?

Dann:

mehrere geeignete Quellen erzeugen.

Beispiel Card

Maximale Darstellung ungefähr:

400 CSS px

Mögliche Quellgrößen:

400
800
1200

Nicht zwangsläufig alle drei nötig.

Der konkrete Workflow entscheidet.

Beispiel Artikelbild

Maximal:

900 CSS px

Quellen beispielsweise:

768
1200
1600

Beispiel Hero

Maximal:

1600 CSS px

Mögliche Quellen:

960
1440
1920
2400

Auch hier:

keine universellen Pflichtwerte.

Sie müssen zum Layout passen.

Warum nicht nur 1x und 2x?

Weil:

Bildbreiten flexibel sind.

DPR unterschiedlich ist.

Browser selbst besser auswählen können.

Mehrere sinnvoll abgestufte Breiten sind oft flexibler.

Trotzdem nicht 30 Größen erzeugen

Zwischen:

400,

420,

440,

460,

480

braucht es meist keine eigenen Dateien.

Die zusätzlichen Varianten erhöhen:

Storage,

Generierungsaufwand,

Cachekomplexität.

Sinnvolle Stufen

Man sucht Größen, zwischen denen der Browser vernünftig wählen kann.

Die exakten Werte hängen vom Theme ab.

Bildgrößen aus Analytics ableiten

Man kann prüfen:

Welche Viewportgrößen kommen tatsächlich vor?

Welche Bildquelle wird geladen?

Wie groß ist sie?

Damit lässt sich das System später optimieren.

Nicht nur theoretisch planen

Real User Monitoring kann zeigen:

Welche Dateien Nutzer tatsächlich bekommen.

Das ist wertvoller als reine Annahmen.

Bildauflösung und Page Speed Audit

Audits bemängeln häufig:

„Serve images that are appropriately sized.“

Gemeint ist:

Die geladene Bildquelle besitzt deutlich mehr Pixel beziehungsweise Daten als für die Darstellung benötigt.

Das ist ein klassisches Auflösungsproblem.

Ein Bildoptimierungsdienst kann dies dynamisch lösen

Request:

/image/4711?w=800

Der Dienst erzeugt beziehungsweise liefert:

passende Breite.

Das kann sehr flexibel sein.

Aber dynamische Varianten brauchen Grenzen

Sonst kann jeder beliebige Wert:

w=817
w=818
w=819

eine neue Datei erzeugen.

Das kann Cache und Storage unnötig aufblasen.

Presets beziehungsweise gerundete Größen sind sinnvoll

requested 817
↓
nächste definierte Größe 960

Damit bleibt die Variantenanzahl kontrolliert.

Image CDN

Ein Bild-CDN kann:

Resize,

Crop,

Formatwahl,

Kompression

dynamisch übernehmen.

Das verschiebt einen Teil der Media Pipeline aus WordPress heraus.

Vorteil

ein Master
↓
viele dynamische Derivate

Nachteil

Abhängigkeit von:

Anbieter,

Kosten,

URL-Struktur,

externem Dienst.

Daher sollte das Master unabhängig archiviert bleiben.

Lokaler Image Service

Alternativ:

Master Storage
↓
eigener Image Worker
↓
Derivate
↓
Webserver / CDN

Das bietet mehr Kontrolle.

Dafür muss Infrastruktur selbst betrieben werden.

Bildauflösung lässt sich hervorragend automatisieren

Ein Workflow kann für jedes neue Bild bestimmen:

Bildklasse
↓
Preset
↓
Ratios
↓
Breiten
↓
Formate

Dann sämtliche Derivate automatisch erstellen.

Beispiel

{
  "asset_id": "4711",
  "type": "article_photo",
  "preset": "knowledge-article"
}

Das Preset könnte intern kennen:

3:2

768 px
1200 px
1600 px

plus Formatregeln.

Redaktion muss keine Pixelzahlen kennen

Das ist ein wichtiger Vorteil.

Redaktion entscheidet:

Das ist ein Artikelbild.

System entscheidet:

Welche technischen Dateien braucht die Website?

Genau wie beim Farbsystem:

Semantik oben.

Technik darunter.

KI kann auch hier unterstützen

Ein Vision-Modell könnte klassifizieren:

Foto

Screenshot

Illustration

Logo

und passende Presets vorschlagen.

Aber harte technische Regeln sollten weiterhin deterministisch ausgeführt werden.

Beispiel

KI erkennt:

screenshot

Workflow mappt:

screenshot
↓
lossless-oriented preset

Das Modell selbst entscheidet nicht frei:

Ich nehme heute Qualität 47 und 1733 Pixel.

Automatisierung braucht Schutzgrenzen

Zum Beispiel:

Master kleiner als Mindestbreite
↓
nicht automatisch veröffentlichen

sondern:

manual_review

oder:

Upscaling Workflow

Bildqualität kontrollieren

Technische Prüfung:

Breite korrekt?

Höhe korrekt?

Datei lesbar?

Dateigröße akzeptabel?

Format korrekt?

Visuelle Prüfung:

scharf?

Crop sinnvoll?

Motiv vollständig?

Text lesbar?

Beide Ebenen sind nötig.

Kontaktbogen für Bildvarianten

Bei mehreren Crops und Größen kann eine Übersicht helfen:

Desktop Hero
Mobile Hero
Card
Thumbnail

nebeneinander.

So erkennt man schnell:

Wird das Hauptmotiv irgendwo abgeschnitten?

Auflösung kann nicht getrennt von Komposition beurteilt werden

Ein perfekt scharfes Bild ist trotzdem schlecht, wenn:

das Gesicht abgeschnitten,

das Produkt nicht sichtbar

oder:

Text im Bild außerhalb des Crops liegt.

Technische Schärfe ist nur eine Qualitätsdimension

Schärfe
+
Komposition
+
Motivtreue
+
Performance
↓
gutes Webbild

Was du dir über Bildauflösung merken solltest

Bildauflösung beschreibt bei Rasterbildern zunächst die Anzahl der vorhandenen Pixel in Breite und Höhe.

Zum Beispiel:

1920 × 1080 Pixel

Diese beiden Werte ergeben insgesamt:

gut zwei Millionen Pixel.

Ein Bild mit:

6000 × 4000

besitzt ungefähr:

24 Megapixel.

Mehr Pixel bedeuten grundsätzlich mehr mögliche räumliche Detailinformation.

Aber:

mehr Pixel
≠
automatisch bessere Bildqualität

Fokus,

Optik,

Kompression,

Rauschen

spielen ebenfalls eine Rolle.

Eine weitere wichtige Unterscheidung lautet:

Pixelabmessung
≠
Dateigröße

Ein:

1920 × 1080

Bild kann abhängig von:

Format,

Kompression,

Motiv

sehr unterschiedliche Dateigrößen besitzen.

PPI bedeutet:

Pixels Per Inch

und beschreibt eine Beziehung zwischen Bildpixeln und einer physischen Größe.

DPI bedeutet:

Dots Per Inch

und stammt primär aus dem Druckbereich.

Für normale Websitebilder ist die gespeicherte DPI- beziehungsweise PPI-Zahl nicht die entscheidende Qualitätsgröße.

Der häufige Satz:

Webbilder brauchen 72 DPI.

ist daher als allgemeine Regel falsch beziehungsweise irreführend.

Für Webdarstellung sind wichtiger:

Pixelabmessungen
+
Darstellungsgröße

Ein:

1200 × 800 Pixel

Bild besitzt im Browser grundsätzlich dieselbe Rasterinformation, egal ob in seinen Metadaten:

72 PPI

oder:

300 PPI

gespeichert sind.

Moderne Displays bringen jedoch eine weitere Ebene hinzu:

Device Pixel Ratio.

CSS-Pixel
↓
Browser
↓
physische Gerätepixel

Bei einem Display mit:

DPR 2

kann ein Bild, das:

600 CSS-Pixel

breit angezeigt wird, von einer Quelle mit ungefähr:

1200 Bildpixeln

profitieren.

Darum können hochauflösende Displays größere Bildquellen sinnvoll nutzen.

Das bedeutet aber nicht:

immer größtmögliche Datei senden

Denn zusätzliche Pixel kosten:

Datenvolumen,

Ladezeit,

Rechenaufwand.

Responsive Images lösen diesen Konflikt.

mehrere Bildgrößen
↓
Browser
↓
passende Variante

Beispielsweise:

480

768

1200

1600

Pixel Breite.

Der Browser kann abhängig von:

Viewport,

Layout,

Pixeldichte

eine geeignete Quelle wählen.

Damit wird ein kleines Smartphone nicht unnötig mit demselben riesigen Bild versorgt wie ein großer hochauflösender Monitor.

Die richtige Bildauflösung entsteht deshalb aus der Komponente.

Hero
→ große Quelle

Card
→ mittlere Quelle

Thumbnail
→ kleine Quelle

Nicht aus einer universellen Regel wie:

Alle Websitebilder 1920 Pixel.

Eine professionelle Bildpipeline arbeitet daher idealerweise so:

Master
↓
Crop
↓
Zielauflösung
↓
Format
↓
Kompression
↓
responsive Varianten
↓
Website

Das Masterbild sollte erhalten bleiben.

Denn:

Downscaling ist einfach.

großes Original
↓
kleinere Webversion

Der umgekehrte Weg ist schwieriger.

Beim Upscaling müssen zusätzliche Pixel berechnet werden.

Klassische Verfahren interpolieren vorhandene Bildinformation.

KI-Verfahren können plausible neue Details generieren.

kleines Bild
↓
KI-Upscaling
↓
größeres plausibles Bild

Aber:

plausibel
≠
historisch beziehungsweise sachlich korrekt rekonstruiert

Das ist besonders wichtig bei:

Dokumenten,

Beweismaterial,

wissenschaftlichen Bildern,

Produktdetails.

Bei Illustrationen und generativen Bildern kann KI-Upscaling dagegen ausgesprochen nützlich sein.

Für lokale Bild-KI spielt Auflösung zusätzlich bei der Hardware eine große Rolle.

höhere Auflösung
→ mehr Pixel
→ mehr Rechenarbeit
→ häufig höherer VRAM-Bedarf

Verdoppelt man Breite und Höhe:

1024 × 1024
↓
2048 × 2048

vervierfacht sich die Pixelzahl.

Deshalb ist:

Vorschau erzeugen
↓
bestes Bild auswählen
↓
nur dieses hochskalieren

oft effizienter als alle Kandidaten sofort maximal groß zu berechnen.

Für WordPress sollte die Bildauflösung aus dem Theme und den echten Layoutbreiten abgeleitet werden.

Theme
↓
Bildrollen
↓
responsive Größen

Zum Beispiel:

Hero

Artikel

Card

Thumbnail

Daraus können automatisiert passende Derivate entstehen.

Die Redaktion muss dann nicht mehr entscheiden:

Brauche ich 768 oder 1200 Pixel?

Sie sagt nur:

Das ist ein Artikelbild.

Das System übernimmt:

Resize,

Crop,

Format,

Kompression.

Damit wird Bildauflösung von einer manuellen Einzelentscheidung zu einem reproduzierbaren Medienworkflow.

Der zentrale Merksatz lautet:

Für Webbilder ist nicht die höchste verfügbare Auflösung die beste, sondern die kleinste Auflösung, die im vorgesehenen Layout zuverlässig scharf genug aussieht.