Kurz gesagt
Pillow Test: Pillow 13.0.0 erzeugte in unserem Test sechs WebP-Titelbilder mit jeweils weniger als 100.000 Bytes. Zusätzlich bestanden Prüfungen zu Dateiformat, Abmessungen, EXIF-Ausrichtung, Transparenz und Metadaten. Die Bibliothek eignet sich damit für eine skriptgesteuerte Bildpipeline. Ein Qualitätswert allein garantiert jedoch keine Dateigröße; die fertige Datei muss kontrolliert werden.
8,5/10
Fazit
8,5/10 für die geprüfte kleine Bildpipeline. Dateibudget und Sichtkontrolle bleiben Teil des eigenen Workflows.
Vorteile
- Sechs WebP-Exporte unter der Byte-Grenze
- EXIF- und Alpha-Fälle praktisch geprüft
- Kompakte, nachvollziehbare Python-Pipeline
Nachteile
- Keine fertige redaktionelle Oberfläche
- Farbprofile, Animationen und Last separat zu behandeln
Sechs echte Titelbilder lagen zwischen 79.726 und 94.634 Bytes.
Die Byte-Grenze wird nach der Komprimierung geprüft.
Transparenz und EXIF-Ausrichtung brauchen eigene Testfälle.
Was wurde im Pillow Test verarbeitet?
Im Pillow Test wurden die sechs KI-generierten Originalillustrationen dieser ersten Byte-Dossier-Serie tatsächlich geöffnet, verkleinert und als WebP gespeichert. Die Umgebung verwendete Pillow 13.0.0, Python 3.12.14, libwebp 1.6.0 und libavif 1.4.2 unter Linux. Der Export begrenzte Bilder auf höchstens 1200 × 675 Pixel und entfernte nicht benötigte Metadaten aus den Ausgabedateien.
Die Methode startete bei Qualität 88 und senkte den Wert in Zweierschritten, bis die Ausgabe unter 98.000 Bytes lag. Diese interne Grenze lässt Abstand zur Vorgabe von weniger als 100.000 Bytes. Das war bei allen sechs Motiven möglich. Es wurde keine universell gleiche Bildqualität behauptet: Kompressionsspuren hängen vom Motiv und von der Betrachtungsgröße ab.
Welche Dateien sind tatsächlich entstanden?
Motiv | Abmessungen | Qualitätswert | Dateigröße |
|---|---|---|---|
Agenturauswahl | 1199 × 675 | 88 | 83.442 Bytes |
GEO und SEO | 1199 × 675 | 88 | 79.726 Bytes |
KI-Sichtbarkeit | 1199 × 675 | 88 | 94.346 Bytes |
Bildformate | 1199 × 675 | 76 | 90.992 Bytes |
Statische Suche | 1199 × 675 | 88 | 94.634 Bytes |
Bildpipeline | 1199 × 675 | 80 | 92.072 Bytes |
Die Breite von 1199 Pixeln entsteht durch das proportionale Einpassen der Originale. Es wurde keine Bildkante auf 1200 Pixel gestreckt. Damit bleiben die Seitenverhältnisse erhalten. Die Dateigrößen stammen aus den gespeicherten Dateien, nicht aus einer Schätzung vor dem Export.

Welche Zusatzprüfungen wurden ausgeführt?
Sechs Prüfungen bestanden: alle Titelbilder unter 100.000 Bytes, korrekt dekodierbares WebP, Einhaltung der maximalen Abmessungen, transparenter Rand eines separaten RGBA-Testbildes, korrekte Drehung eines JPEG mit EXIF-Orientierung 6 und fehlende EXIF-Daten in den sechs exportierten Titelbildern. Der Transparenzfall wurde verlustfrei gespeichert und gehört nicht zu den sechs RGB-Titelbildern.
Die Orientierung ist praktisch relevant, weil ein bloßes Verkleinern ein gedreht gespeichertes Foto falsch ausgeben kann. Die separate EXIF-Prüfung verwendete ein 80 × 40 Pixel großes Bild. Nach der Anwendung der Orientierung musste es 40 × 80 Pixel groß sein. Genau diese Bedingung wurde geprüft.
Wie sieht ein minimales Exportbeispiel aus?
Das folgende Muster zeigt das Prinzip für statische RGB-Bilder. Es übernimmt keinen vollständigen Produktionsbetrieb, keine Farbprofil-Konvertierung und keine Behandlung animierter Dateien. Es bricht ab, wenn die Grenze mit den erlaubten Qualitätswerten nicht erreichbar ist, anstatt eine zu große Datei stillschweigend zu speichern.
from PIL import Image, ImageOps
from io import BytesIO
from pathlib import Path
with Image.open('original.png') as original:
image = ImageOps.exif_transpose(original).convert('RGB')
image.thumbnail((1200, 675), Image.Resampling.LANCZOS)
for quality in range(88, 39, -2):
output = BytesIO()
image.save(output, 'WEBP', quality=quality, method=6)
if output.tell() < 98000:
Path('export.webp').write_bytes(output.getvalue())
break
else:
raise ValueError('Dateibudget nicht erreicht')Wo liegen die Grenzen der Bibliothek?
Pillow ist eine programmierbare Bibliothek, kein fertiger Bildfreigabeprozess. Für Nutzereingaben braucht eine Anwendung zusätzliche Entscheidungen zu zulässigen Dateitypen, Pixelgrenzen, Farbprofilen und Animationen. Ein RGBA-Bild darf außerdem nicht pauschal in RGB umgewandelt werden, wenn Transparenz erhalten bleiben soll. Das vereinfachte Codebeispiel ist für diesen Fall nicht gedacht.
Der Test prüft Exportfunktionen und Dateigrenzen. Er untersucht keine Millionen-Dateien-Pipeline, keinen parallelen Serverbetrieb und keine repräsentative Sammlung von Kamerafotos. Vorlagen mit winziger Schrift oder harten Farbkanten benötigen eine gesonderte Sichtprüfung.
Wie ergibt sich die Bewertung von 8,5 Punkten?
Die redaktionellen Teilnoten lauten Reproduzierbarkeit 9, geprüfte Exportfunktionen 9, Budgetsteuerung 8 und Aufwand für eine vollständige Produktionsintegration 8. Der ungewichtete Mittelwert ist 8,5. Für eine kleine, skriptgesteuerte Redaktion ist Pillow nach dem beschriebenen Test gut geeignet. Wer eine visuelle Oberfläche oder eine vollständig verwaltete Medienplattform benötigt, bewertet andere Anforderungen.
Titelbild: KI-generierte Themenillustration, keine reale Aufnahme.
Welche Beiträge helfen bei der nächsten Entscheidung?
Häufige Fragen
Garantiert Qualität 80 eine Datei unter 100 KB?
Nein. Dateigröße hängt unter anderem von Bildinhalt und Abmessungen ab. Prüfen Sie die tatsächlich gespeicherten Bytes.
Kann Pillow WebP mit Transparenz speichern?
Im separaten verlustfreien RGBA-Test blieb der transparente Rand erhalten. Eine vorherige Umwandlung in RGB würde die Transparenz entfernen.
Sind die Ergebnisse auf jedes Foto übertragbar?
Nein. Der Test verwendet sechs KI-generierte Illustrationen und kleine Zusatzfixtures. Andere Motive und Produktionslasten müssen separat geprüft werden.
Quellen
- Pillow 13.0.0: Image file formats , Pillow
- Pillow 13.0.0: ImageOps , Pillow
- Byte Dossier Lab: sechs WebP-Titelbilder und sechs Funktionsprüfungen, ausgeführt am 13.11.2026