Zusammenfassung

Die aktuelle Situation der Bildspeicherung und -manipulation in der Python-Welt ist extrem fragmentiert: Fast jede Bibliothek, die Bildobjekte verwendet, hat ihre eigene Bildklasse implementiert, die inkompatibel mit allen anderen ist und oft nicht sehr pythonisch ist. Eine grundlegende RGB-Bildklasse existiert in der Standardbibliothek (Tkinter.PhotoImage), ist aber für alles außer Tkinter-Programmierung praktisch unbrauchbar und wird nicht verwendet.

Diese Fragmentierung nimmt nicht nur wertvollen Speicherplatz in den Köpfen der Entwickler ein, sondern macht auch den Austausch von Bildern zwischen verschiedenen Bibliotheken (was in relativ häufigen Anwendungsfällen erforderlich ist) langsamer und komplexer als nötig.

Dieses PEP schlägt vor, die Situation zu verbessern, indem ein einfaches und pythonisches Bildprotokoll/-schnittstelle definiert wird, das hoffentlich von bestehenden Bildklassen innerhalb und außerhalb der Standardbibliothek akzeptiert und implementiert werden kann, *ohne die Abwärtskompatibilität* mit ihren bestehenden Benutzerbasen zu brechen. Praktisch handelt es sich hierbei um die Definition, wie ein minimales *bildähnliches* Objekt aussehen und sich verhalten sollte (ähnlich wie die Methoden read() und write() bei *dateiähnlichen* Objekten).

Die Aufnahme einer Klasse in die Standardbibliothek, die grundlegende Bildmanipulationsfunktionen bietet und das neue Protokoll implementiert, wird ebenfalls vorgeschlagen, zusammen mit einer Mixin-Klasse, die dabei hilft, bestehenden Bildklassen Unterstützung für das Protokoll hinzuzufügen.

PEP Verschiebung

Die weitere Erforschung der in diesem PEP behandelten Konzepte wurde mangels eines aktuellen Vertreters, der an der Förderung der Ziele des PEP interessiert ist und Feedback sammelt und einarbeitet, sowie über ausreichend verfügbare Zeit zur effektiven Umsetzung, zurückgestellt.

Begründung

Ein guter Weg, um hochwertige Module für die Aufnahme in die Python-Standardbibliothek bereitzustellen, ist, einfach auf die natürliche Selektion unter konkurrierenden externen Bibliotheken zu warten, die einen klaren Gewinner mit nützlicher Funktionalität und einer großen Benutzerbasis hervorbringt. Dann kann der De-facto-Standard offiziell sanktioniert werden, indem er in die Standardbibliothek aufgenommen wird.

Leider hat dieser Ansatz bei der Schaffung einer dominanten Bildklasse in der Python-Welt nicht gut funktioniert: Fast jede Drittanbieter-Bibliothek, die ein Bildobjekt benötigt, erstellt ihre eigene Klasse, die mit denen anderer Bibliotheken inkompatibel ist. Dies ist ein echtes Problem, da es für ein Programm durchaus üblich ist, ein Bild z. B. mit PIL (der Python Imaging Library) zu erstellen und zu bearbeiten und es dann mit wxPython oder pygame anzuzeigen. Aber diese Bibliotheken haben unterschiedliche und inkompatible Bildklassen, und die übliche Lösung besteht darin, ein Bild manuell von der Quelle in ein (Breite, Höhe, Bytes-String)-Tupel zu "exportieren" und es durch Erstellen einer neuen Instanz im Zielformat zu "importieren". Dieser Ansatz *funktioniert*, ist aber sowohl hässlicher als auch langsamer als nötig.

Eine andere "Lösung", die manchmal verwendet wurde, ist die Erstellung spezifischer Adapter und/oder Konverter von einer Klasse zu einer anderen (z. B. bietet PIL das Modul ImageTk zur Konvertierung von PIL-Bildern in eine mit der Tkinter-Klasse kompatible Klasse). Aber dieser Ansatz skaliert schlecht mit der Anzahl der beteiligten Bibliotheken und ist für den Benutzer immer noch ärgerlich: Warum sollte ich ein Objekt, das ich habe, konvertieren, bevor ich es an die nächste Methode übergebe, warum kann es nicht einfach mein Bild so akzeptieren, wie es ist?

Das Problem beschränkt sich keineswegs auf die drei genannten Bibliotheken und hat wahrscheinlich mehrere Ursachen, darunter zwei, die meiner Meinung nach sehr wichtig sind, um es zu verstehen, bevor es gelöst wird

• In der heutigen Computerwelt ist ein Bild ein Basistyp, der nicht eng an eine bestimmte Domäne gebunden ist. Deshalb wird es nie einen klaren Gewinner zwischen den Bildklassen der drei genannten Bibliotheken (PIL, wxPython und pygame) geben: Sie decken unterschiedliche Domänen ab und konkurrieren nicht wirklich miteinander;
• Die Python-Standardbibliothek hat nie eine gute Bildklasse bereitgestellt, die von Drittanbietermodulen übernommen oder nachgeahmt werden kann. Tkinter.PhotoImage bietet grundlegende RGB-Funktionalität, ist aber bei weitem die langsamste und hässlichste der Gruppe und kann nur nach der Erstellung des Tkinter-Hauptfensters instanziiert werden.

Dieses PEP versucht, diese Situation auf vier Arten zu verbessern

1. Es definiert ein einfaches und pythonisches Bildprotokoll/-schnittstelle (sowohl auf Python- als auch auf C-Seite), das hoffentlich von bestehenden Bildklassen innerhalb und außerhalb der Standardbibliothek akzeptiert und implementiert werden kann, *ohne die Abwärtskompatibilität* mit ihren bestehenden Benutzerbasen zu brechen.
2. Es schlägt die Aufnahme von drei neuen Klassen in die Standardbibliothek vor
   • ImageMixin stellt fast alles Notwendige für die Implementierung des neuen Protokolls bereit; sein Hauptzweck ist es, die Unterstützung dieser Schnittstelle für bestehende Bibliotheken so einfach wie möglich zu machen, in einigen Fällen so einfach wie das Hinzufügen zur Liste der Basisklassen und geringfügige Ergänzungen zum Konstruktor.
   • Image ist eine Unterklasse von ImageMixin und fügt einen Konstruktor hinzu, der ein Bild zwischen verschiedenen Pixelformaten skalieren und/oder konvertieren kann. Dies soll eine schnelle und effiziente Standardimplementierung des neuen Protokolls bieten.
   • ImageSize ist eine kleine Hilfsklasse. Details siehe unten.
3. Tkinter.PhotoImage wird das neue Protokoll (hauptsächlich über die Klasse ImageMixin) implementieren und alle Tkinter-Methoden, die ein Bild empfangen können, werden modifiziert, um jedes Objekt zu akzeptieren, das die Schnittstelle implementiert. Nebenbei wird der Autor dieses PEP mit den Entwicklern der gängigsten externen Bibliotheken zusammenarbeiten, um das gleiche Ziel zu erreichen (Unterstützung des Protokolls in ihren Klassen und Akzeptanz jeder Klasse, die es implementiert).
4. Neue PyImage_* Funktionen werden zur CPython C API hinzugefügt: Sie implementieren die C-Seite des Protokolls und akzeptieren als ersten Parameter **jedes** Objekt, das es unterstützt, auch wenn es keine Instanz der Klassen Image/ImageMixin ist.

Die Haupteffekte für den Endbenutzer werden eine Vereinfachung des Austauschs von Bildern zwischen verschiedenen Bibliotheken sein (wenn alles gut geht, wird jede Python-Bibliothek Bilder von jeder anderen Bibliothek akzeptieren) und die sofortige Verfügbarkeit der neuen Klasse Image. Die neue Klasse soll einfache, aber gängige Anwendungsfälle abdecken, wie z. B. das Zuschneiden und/oder Skalieren eines Fotos auf die gewünschte Größe und dessen Übergabe an ein geeignetes Widget zur Anzeige in einem Fenster, oder das Abdunkeln einer Textur und deren Übergabe an eine 3D-Bibliothek.

Die Klasse Image ist nicht dazu gedacht, PIL, Pythonmagick oder NumPy zu ersetzen oder mit ihnen zu konkurrieren, auch wenn sie eine (sehr kleine) Teilmenge der Funktionalität dieser drei Bibliotheken bietet. Insbesondere PIL bietet sehr reiche Bildmanipulationsfunktionen mit *Dutzenden* von Klassen, Filtern, Transformationen und Dateiformaten. Die Aufnahme von PIL (oder etwas Ähnlichem) in die Standardbibliothek mag ein lohnenswertes Ziel sein oder auch nicht, aber sie liegt vollständig außerhalb des Rahmens dieses PEP.

Spezifikation

Das Modul imageop wird als *Standardort* für die neuen Klassen und Objekte verwendet, da es seit langem Funktionen beherbergt, die eine etwas ähnliche Funktionalität boten, aber ein neues Modul kann nach Belieben erstellt werden (z. B. ein neues Modul namens "image" oder "media"; letzteres könnte schließlich andere Multimedia-Klassen enthalten).

MODES ist eine neue Konstante auf Modulebene: sie ist eine Menge von Pixelformaten, die von der Klasse Image unterstützt werden. Jedes Bildobjekt, das das neue Protokoll implementiert, wird garantiert in einem dieser Modi formatiert sein, aber Bibliotheken, die Bilder akzeptieren, dürfen nur eine Teilmenge davon unterstützen.

Diese Modi sind wiederum auch als Konstanten auf Modulebene verfügbar (z. B. imageop.RGB).

Die folgende Tabelle gibt einen Überblick über die derzeit unterstützten Modi und ihre Eigenschaften

Wenn der Name eines Modus mit einer Zahl endet, stellt er die durchschnittliche Anzahl von Bits pro Pixel dar. Alle anderen Modi verwenden einfach ein Byte pro Komponente pro Pixel.

Keine Paletten-Modi oder Modi mit weniger als 8 Bits pro Komponente werden unterstützt. Willkommen im 21. Jahrhundert.

Hier ist eine kurze Beschreibung der Modi und der Grund für ihre Aufnahme; es gibt vier Gruppen von Modi

1. Graustufen (L*-Modi): Sie werden stark in der wissenschaftlichen Datenverarbeitung verwendet (diese Leute benötigen möglicherweise auch einen sehr hohen Dynamikbereich und eine hohe Präzision, daher L32, der einzige Modus mit 32 Bits pro Komponente) und manchmal kann es nützlich sein, eine einzelne Komponente eines Farbbildes als Graustufenbild zu betrachten (dies wird von den einzelnen Ebenen der planaren Bilder verwendet, siehe YV12 unten); der Name der Komponente ('l', kleiner Buchstabe L) steht für Luminanz, die zweite optionale Komponente ('a') ist der Alphawert und repräsentiert die Opazität der Pixel: Alpha = 0 bedeutet volle Transparenz, Alpha = 255/65535 repräsentiert ein vollständig opakes Pixel;
2. RGB* Modi: die alltäglichen Farbbilder. Die optionale Alpha-Komponente hat die gleiche Bedeutung wie bei Graustufen-Modi;
3. YCbCr, auch bekannt als YUV (*YV12-Modi). Diese Modi sind planar (d. h. die Werte aller Pixel für jede Komponente werden in einem zusammenhängenden Speicherbereich gespeichert, anstatt der üblichen Anordnung, bei der alle Komponenten eines Pixels in aufeinanderfolgenden Bytes liegen) und verwenden eine 1, 2, 2 (auch 4:2:0) Unterabtastung (d. h. jedes Pixel hat seinen eigenen Y-Wert, aber die Cb- und Cr-Komponenten werden zwischen Gruppen von 2x2 benachbarten Pixeln geteilt), da dies das Format ist, das mit Abstand am häufigsten für YCbCr-Bilder verwendet wird. Bitte beachten Sie, dass die V (Cr)-Ebene vor der U (Cb)-Ebene gespeichert wird.

   YV12 wird häufig für MPEG2 (einschließlich DVDs), MPEG4 (sowohl ASP/DivX als auch AVC/H.264) und Theora-Videobilder verwendet. Gültige Werte für Y liegen im Bereich von 16 bis 235 (exklusive 236), und gültige Werte für Cb und Cr liegen im Bereich von 16 bis 240. JPEG_YV12 ist ähnlich wie YV12, aber die drei Komponenten können den vollen Bereich von 256 Werten haben. Es ist das native Format, das von fast allen JPEG/JFIF-Dateien und von MJPEG-Videobildern verwendet wird. Die "Seltsamkeit" dieser beiden im Vergleich zu allen anderen unterstützten Modi ergibt sich daraus, dass sie so häufig von vielen bestehenden Bibliotheken und Anwendungen verwendet werden; dies ist auch der Grund für ihre Aufnahme (und die Tatsache, dass sie nicht verlustfrei in RGB konvertiert werden können, da YCbCr ein größerer Farbraum ist); die lustige 4:2:0 planare Anordnung der Pixelwerte ist relativ einfach zu unterstützen, da in den meisten Fällen die drei Ebenen als drei separate Graustufenbilder betrachtet werden können;

4. CMYK* Modi (Cyan, Magenta, Gelb und Schwarz) sind subtraktive Farbmodi, die für den Druck von Farbbildern auf "toten Bäumen" verwendet werden. Professionelle Designer lieben es, so zu tun, als könnten sie nicht ohne sie leben, also hier sind sie.

Beispiele

Einige Beispiele für gängige Operationen mit der neuen Image-Klasse und dem Protokoll

# create a new black RGB image of 6x9 pixels
rgb_image = imageop.Image(imageop.RGB, (6, 9))

# same as above, but initialize the image to bright red
rgb_image = imageop.Image(imageop.RGB, (6, 9), color=(255, 0, 0))

# convert the image to YCbCr
yuv_image = imageop.Image(imageop.JPEG_YV12, source=rgb_image)

# read the value of a pixel and split it into three ints
r, g, b = rgb_image[x, y]

# modify the magenta component of a pixel in a CMYK image
cmyk_image[x, y].m = 13

# modify the Y (luma) component of a pixel in a *YV12 image and
# its corresponding subsampled Cr (red chroma)
yuv_image.y[x, y] = 42
yuv_image.cr[x // 2, y // 2] = 54

# iterate over an image
for line in rgb_image:
    for pixel in line:
        # swap red and blue, and set green to 0
        pixel.value = pixel.b, 0, pixel.r

# find the maximum value of the red component in the image
max_red = max(pixel.r for pixel in rgb_image.pixels())

# count the number of colors in the image
num_of_colors = len(set(tuple(pixel) for pixel in image.pixels()))

# copy a block of 4x2 pixels near the upper right corner of an
# image and paste it into the lower left corner of the same image
image[:4, -2:] = image[-6:-2, 1:3]

# create a copy of the image, except that the new image can have a
# different (usually empty) info dict
new_image = image[:]

# create a mirrored copy of the image, with the left and right
# sides flipped
flipped_image = image[::-1, :]

# downsample an image to half its original size using a fast, low
# quality operation and a slower, high quality one:
low_quality_image = image[::2, ::2]
new_size = image.size.width // 2, image.size.height // 2
high_quality_image = imageop.Image(size=new_size, source=image)

# direct buffer access
rgb_image[0, 0] = r, g, b
assert tuple(rgb_image.buffer[:3]) == (r, g, b)

Abwärtskompatibilität

Es gibt drei Bereiche, die von diesem PEP betroffen sind und bei denen die Abwärtskompatibilität berücksichtigt werden muss

• Python 2.6: neue Klassen und Objekte werden dem Modul imageop hinzugefügt, ohne den vorhandenen Modulinhalt zu berühren; neue Methoden und Attribute werden zu Tkinter.PhotoImage hinzugefügt und seine __getitem__ und __setitem__ Methoden werden so modifiziert, dass sie ganze Zahlen, Tupel und Slices akzeptieren (derzeit akzeptieren sie nur Strings). Alle Änderungen stellen eine Obermenge der bestehenden Funktionalität dar, sodass keine größeren Kompatibilitätsprobleme zu erwarten sind.
• Python 3.0: die Legacy-Inhalte des Moduls imageop werden gemäß PEP 3108 gelöscht; alles, was in diesem Vorschlag definiert ist, wird wie in Python 2.x funktionieren, mit Ausnahme der üblichen 2.x/3.0-Unterschiede (z.B. wird die Unterstützung für long-Ganzzahlen und die Interpretation von str-Instanzen als Byte-Sequenzen fallen gelassen).
• externe Bibliotheken: die Namen und die Semantik der Standard-Bildmethoden und -attribute werden sorgfältig ausgewählt, um es einigen externen Bibliotheken, die Bilder manipulieren (einschließlich mindestens PIL, wxPython und pygame), zu ermöglichen, das neue Protokoll in ihren Bildklassen zu implementieren, ohne die Kompatibilität mit bestehendem Code zu beeinträchtigen. Die einzigen offensichtlichen Konflikte zwischen dem Bildprotokoll und NumPy-Arrays sind der Wert des size-Attributs und die Koordinatenreihenfolge im Ausdruck image[x, y].

Referenzimplementierung

Wenn dieser PEP akzeptiert wird, wird der Autor eine Referenzimplementierung der neuen Klassen in reinem Python bereitstellen (die in CPython, PyPy, Jython und IronPython ausgeführt werden kann) und eine zweite, für Geschwindigkeit optimierte Implementierung in Python und C, die für die Aufnahme in die CPython-Standardbibliothek geeignet ist. Der Autor wird auch die erforderlichen Tkinter-Patches einreichen. Für den gesamten Code wird es eine Version für Python 2.x und eine Version für Python 3.0 geben (es wird erwartet, dass die beiden Versionen sehr ähnlich sein werden und die Version für Python 3.0 wahrscheinlich fast vollständig automatisch generiert wird).

Danksagungen

Die Implementierung dieses PEP wird, falls akzeptiert, von Google im Rahmen des Google Summer of Code-Programms gesponsert.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.