Bild-Lexikon

Nächste Generation nach WebP (2019) — bis 50% kleiner als WebP.

AV1 Image File Format, basiert auf dem AV1-Video-Codec der Alliance for Open Media. Bietet höhere Effizienz als WebP, mit 12-Bit-Farbtiefe und HDR-Unterstützung. Browser-Support: Chrome 85+, Firefox 113+, Safari 16.4+.

Animations-Format aus 1987, max. 256 Farben, binäre Transparenz.

Graphics Interchange Format, von CompuServe entwickelt. Veraltete LZW-Komprimierung und 8-Bit-Farbraum machen es heute für Animation deutlich schwächer als animiertes WebP — typischerweise 3–4× größer.

Apple-Standard seit iOS 11 — 30–50% kleiner als JPG.

High Efficiency Image Container, basiert auf dem HEVC/H.265-Video-Codec. Standard auf iPhones seit 2017. Außerhalb des Apple-Ökosystems oft inkompatibel — Windows 10 braucht eine kostenpflichtige Erweiterung.

Verlustbehaftetes Bildformat (1992), Standard für Fotos im Web.

Joint Photographic Experts Group, 1992. Zerlegt Bilder in 8×8-Pixel-Blöcke und nutzt Diskrete Cosinus-Transformation (DCT) plus Quantisierung, um Datei-Größe drastisch zu reduzieren — auf Kosten unsichtbarer Detail-Information. Sweet-Spot-Qualität für Web: 78. Kein Alpha-Kanal.

Verlustfreies Bildformat (1996) mit Alpha-Kanal-Transparenz.

Portable Network Graphics, 1996, als patentfreier Nachfolger von GIF entwickelt. Verlustfreie Komprimierung via Deflate, voller 24-Bit-Farbraum, partielle Transparenz. Ideal für Logos, Diagramme, Screenshots, Pixel-Art. Bei Fotos drei- bis zehnmal größer als JPG.

Vektor-Bildformat — beliebig skalierbar, in XML beschrieben.

Scalable Vector Graphics. Definiert Bilder durch Pfade und Formen statt Pixelraster. Perfekt für Logos und Icons (oft unter 5 KB), per CSS stylbar, animierbar, barrierefrei. Für Fotos ungeeignet.

Modernes Bildformat von Google (2010) — 25–35% kleiner als JPG.

Basiert auf der VP8-Video-Codec-Technologie. Unterstützt Lossy + Lossless + Animation + Alpha-Kanal in einem Format. Universelle Browser-Unterstützung seit 2020.

Mathematische Transformation, die JPG-Komprimierung möglich macht.

Zerlegt einen 8×8-Pixel-Block in 64 Frequenz-Koeffizienten — niedrige Frequenzen in der Mitte, hohe Frequenzen am Rand. JPG quantisiert die hohen Frequenzen stärker, weil das Auge sie schwerer wahrnimmt.

Sichtbare Komprimierungs-Spuren bei zu aggressivem JPG.

Block-Artefakte (8×8-Quadrate), Mosquito-Noise (Ringeln um Kanten) und Banding (Stufen in Verläufen) treten auf, wenn die Qualität zu niedrig gewählt wird oder ein Bild mehrfach hintereinander als JPG re-encodiert wurde (Generation Loss).

Mozilla-Encoder, der JPG-Dateien 5–15% kleiner macht als libjpeg.

Open-Source-Fork von libjpeg-turbo (2014). Bringt Trellis-Quantisierung, optimierte Huffman-Tabellen und eine bessere Standard-Quantisierungs-Matrix mit — vollständig kompatibel mit jedem JPG-Decoder.

Rundung der DCT-Koeffizienten — der eigentliche Verlust bei JPG.

Jeder Frequenz-Koeffizient wird durch eine Quantisierungs-Tabelle dividiert und auf eine ganze Zahl gerundet. Hohe Frequenzen werden stärker quantisiert; niedrige bleiben fast erhalten. Hier passiert der unwiederbringliche Verlust.

Verwirft gezielt Information, die das Auge schlecht wahrnimmt.

Lossy Compression. Nutzt psychovisuelle Modelle, um Daten zu reduzieren, die das menschliche Auge ohnehin schlecht erkennt. JPG, WebP-Lossy und AVIF arbeiten so. Bei richtigem Qualitätswert (78–82 für JPG) unsichtbar.

Pixel bleiben byte-exakt erhalten, nur Speicherung wird effizienter.

Lossless Compression. PNG, WebP-Lossless und AVIF-Lossless arbeiten verlustfrei — kein Pixel wird verändert. Erreichbar durch Entropie-Kodierung (Deflate, Huffman) und Prediction-Modelle.

Vierter Bildkanal, der Transparenz pro Pixel speichert (0–255).

RGB + A. 0 = vollständig transparent, 255 = vollständig undurchsichtig. PNG und WebP unterstützen Alpha; JPG nicht.

Speichert Farb-Info in niedrigerer Auflösung als Helligkeit.

Das Auge ist empfindlicher für Helligkeit als Farbe. Standard-Notation: 4:4:4 (volle Farbinfo), 4:2:2 (halbe horizontale Farbinfo), 4:2:0 (halbe horizontale und vertikale — Web-Standard).

Druckpunkte vs. Bildschirm-Pixel pro Zoll.

DPI (Dots Per Inch) ist eine Druck-Metrik, PPI (Pixels Per Inch) eine Bildschirm-Metrik. Im Web-Kontext werden beide oft synonym verwendet, technisch korrekt ist PPI. Für Druck-Standardqualität: 300 DPI bei finalem Druckmaß.

Definiert, wie RGB-Werte in tatsächliche Farben übersetzt werden.

International Color Consortium Profile. Web-Standard ist sRGB. Adobe RGB und Display-P3 haben größere Farbräume, werden aber von älterer Software ignoriert.

Bildschirme mit doppelter (oder höherer) Pixeldichte.

Apples Marketing-Begriff für Displays mit 2× oder 3× DPR. Für scharfe Darstellung muss ein 600-px-Container ein 1200-px-Bild laden, sonst wirkt es unscharf.

Metadaten-Block in Bildern: Kamera, Linse, Belichtung, GPS.

Exchangeable Image File Format, von der japanischen JEIDA 1995 standardisiert. Eine moderne Smartphone-Kamera packt 100–500 KB EXIF in jedes Foto.

Adobe-Standard für erweiterte Bild-Metadaten in XML.

Extensible Metadata Platform, eingeführt 2001. Strukturierte Speicherung von Bearbeitungs-Historie, Lizenz-Angaben, Tags, Urheberrechtsinformationen.

Misst, wie stark sich Layout-Elemente während des Ladens verschieben.

Bilder ohne explizite `width`/`height`-Attribute verursachen Layout-Shifts und verschlechtern den CLS-Wert. Google empfiehlt CLS unter 0,1.

Googles Metrik-Set zur Mess der Nutzererfahrung — LCP, INP, CLS.

Seit 2021 offizieller Google-Ranking-Faktor. Bilder beeinflussen direkt LCP (Ladezeit) und CLS (Layout-Stabilität).

Bilder erst laden, wenn sie in den Viewport scrollen.

Mit `loading="lazy"` nativ unterstützt seit 2019. Spart Initial-Bandbreite und verbessert LCP. Hero-Bilder bewusst `loading="eager"` setzen.

Wichtigste Core-Web-Vitals-Metrik — Zeit bis zum größten sichtbaren Element.

Misst die Renderzeit des größten Inhaltselements im sichtbaren Bereich. Ziel: unter 2,5 Sekunden. Bilder verursachen oft den LCP und müssen entsprechend priorisiert geladen werden.

HTML-Attribute zur Auslieferung passend großer Bilder pro Gerät.

Mit `srcset` listest du Bild-Varianten in verschiedenen Auflösungen; der Browser wählt automatisch die für Viewport und DPR optimale. `<picture>` ergänzt Format-Switching für AVIF/WebP-Fallbacks.

Kodierung binärer Daten als ASCII-Text — 33% Größen-Overhead.

Standard-Verfahren zur Einbettung binärer Daten in Text-Formate wie HTML, CSS, JSON. Drei Byte werden in vier ASCII-Zeichen kodiert. Sinnvoll nur für sehr kleine Assets (unter 5 KB).

Browser-API zum Zeichnen und Auslesen von Pixeln in JavaScript.

Erlaubt JNRT Pixel die clientseitige Bildverarbeitung: Bild wird auf ein `<canvas>` gezeichnet, manipuliert und als komprimiertes Blob ausgegeben — alles im Browser, kein Server.

PWA-Icon mit Safe-Zone-Padding für Android-Launcher-Masken.

Standard seit Android 8 (2017). Das Icon füllt eine 108-dp-Leinwand komplett aus; das Betriebssystem maskiert je nach Launcher rund, eckig oder squircle.

Web-App, die wie eine native App installierbar ist.

Begriff von Alex Russell, 2015. Kombiniert Service Worker (Offline-Cache), Web App Manifest (Icons + Theme) und Push-Notifications. JNRT Pixel ist als PWA installierbar.

Browser-Proxy zwischen Web-App und Netzwerk — ermöglicht Offline.

Einführung ab 2014. Fängt Netzwerk-Anfragen ab und kann Antworten aus dem Cache liefern. Voraussetzung für PWA-Offline-Funktion.

Browser-Runtime für C/C++/Rust-Code, nahezu nativ schnell.

Erlaubt komplexe Encoder wie libwebp, Mozjpeg, libavif im Browser laufen zu lassen — mit Performance, die Server-Tools vergleichbar ist. Geladen wird die WASM-Datei einmal pro Sitzung.