Dateiformat webp in Delphi VCL

[DugDev]

Gibt es eine Möglichkeit Bilddaten im Format webp mit TImage, TImageList anzuzeigen / zu verarbeiten?

[mkinzler]

Dafür benötigst Du einen Import-/Exportfilter für TImage.
https://github.com/Wykerd/delphi-webp

[Codehunter]

Mal bewusst provokant gefragt: Wozu ist WEBP denn gut? Die Bildqualität ist bestenfalls genauso gut, allzu meist jedoch schlechter als JPEG (4:2:2 und 4:4:4) bzw. PNG. Ich hätte nicht gedacht, dass das heute noch jemand neu in sein Programm einbaut - als PR-Füllmaterial für die Featureliste?

[Sinspin]

Zitat:

Zitat von Codehunter (Beitrag 1480860)

Ich hätte nicht gedacht, dass das heute noch jemand neu in sein Programm einbaut

"Heute noch" ist gut! Aus irgend einem, auch mir, schleierhaften Grund wird das Format, gefühlt, von immer mehr Webseiten für dynamisch generierte Bildinhalte verwendet. Warum man da kein PNG nimmt ergibt für mich auch keinen Sinn.

[Codehunter]

Ich kann mir schon vorstellen, dass Google sein Hausformat mit zahlreichen komfortablen Frameworks garniert. Aber in der letzten Zeit scheint Google das Format selbst aufgegeben zu haben und stattdessen PIK/JPEGXL zu verfolgen. WEBP selbst hat einfach zu wenig Benefit im Vergleich zu JPEG und PNG. Das war damals ganz anders, als PNG sich gegen GIF durchgesetzt hat (mehr als 256 Farben, Alphakanal, bessere Kompression, patentfrei). Interessant ist allenfalls aus historischen Gründen, dass es auf IFF basiert, dem guten alten Amiga-Bitstromformat.

Mich würde schon die Motivation interessieren, das Format in ein Delphiprogramm zu integrieren...

[Redeemer]

WEBP hat für verlustfreie Grafiken einen stärkeren Kompressionsalgorithmus als PNG.
Es wird postuliert, dass WEBP verlustbehaftet "schöner" komprimiert als JPEG bie gleicher Dateigröße. Das ist aber subjektiv und ich finde die WEBP-Verluste nicht besser als JPEG.

[Codehunter]

Zitat:

Zitat von Redeemer (Beitrag 1480881)

WEBP hat für verlustfreie Grafiken einen stärkeren Kompressionsalgorithmus als PNG.

Die umso stärker ins Gewicht fallen, je größer (ich meine Breite x Höhe) das Bild ist. Nur wer benutzt schon PNG für hochauflösende Bilder? Da ist man doch wieder beim JPEG als Referenz, wo WEBP kaum Vorteile zeigt.

Zitat:

Zitat von Redeemer (Beitrag 1480881)

Es wird postuliert, dass WEBP verlustbehaftet "schöner" komprimiert als JPEG bie gleicher Dateigröße. Das ist aber subjektiv und ich finde die WEBP-Verluste nicht besser als JPEG.

Schöner die Verluste nie waren? ;-) Wikipedia hat da ein paar objektive Angaben.

Das einzige das mir im Nachhinein noch eingefallen ist, wo WEBP tatsächlich einen Benefit haben könnte: Verlustfreie Animationen. Da wird ja bis heute noch auf GIF gesetzt und mit allerlei Verrenkungen (z.B. per-Frame-Paletten) die Qualität "optimiert". Juchee, endlich schönere Facebook-Katzen-Glitterbildchen! :lol:

[Redeemer]

Zitat:

Zitat von Codehunter (Beitrag 1480893)

Das einzige das mir im Nachhinein noch eingefallen ist, wo WEBP tatsächlich einen Benefit haben könnte: Verlustfreie Animationen. Da wird ja bis heute noch auf GIF gesetzt und mit allerlei Verrenkungen (z.B. per-Frame-Paletten) die Qualität "optimiert". Juchee, endlich schönere Facebook-Katzen-Glitterbildchen! :lol:

Da wurde nur auf GIF gesetzt, weil APNG keine breite Unterstützung hatte. Seit einem Jahr gibt es effektiv weltweit nur noch zwei Browser gibt, Firefox und Chromium, und die können beide APNG. Dadurch hätte sich die Sache eigentlich erledigt.

Zitat:

Zitat von Codehunter (Beitrag 1480893)

Zitat:

Zitat von Redeemer (Beitrag 1480881)

WEBP hat für verlustfreie Grafiken einen stärkeren Kompressionsalgorithmus als PNG.

Die umso stärker ins Gewicht fallen, je größer (ich meine Breite x Höhe) das Bild ist. Nur wer benutzt schon PNG für hochauflösende Bilder? Da ist man doch wieder beim JPEG als Referenz, wo WEBP kaum Vorteile zeigt.

Die Auswahl des Dateiformats und ob Verlustbehaftung oder nicht, nimmt man Anhand des Inhalts vor. Für alles, was keine fotografischen Daten enthält, ist PNG auch bei großen Bildern JPEG überlegen. Andererseits: Wer nicht-fotografische Daten in einem anderen Format speichert als SVG, hat die Kontrolle über sein Leben verloren.
WEBP kann aber - und das ist neu - verlustbehaftete Alphakanäle, das konnte vorher eigentlich nur JPEG2000 (was nie im Web verbreitet war) und künstlich verlustbehaftetes PNG. Ich glaube, auch verlustbehaftete Animationen mit Alphakanal. Für Animationen ohne Alphakanal gibt es Videos.

Kurzum:
Fotografische Daten: JPEG oder WEBP, je nach Geschmack. Ist halt wirklich diskutabel.
Fotografische Animationen mit Alphakanal: WEBP.
Verlustbehaftete Animationen ohne Alphakanal: MP4.
Alle nicht fotografische Bilder und Animationen: SVG. GIF, PNG und APNG sind überflüssig. Verlustfreies WEBP auch.

[Codehunter]

Zitat:

Zitat von Redeemer (Beitrag 1480901)

Alle nicht fotografische Bilder und Animationen: SVG. GIF, PNG und APNG sind überflüssig. Verlustfreies WEBP auch.

Da wär ich ja prinzipiell sehr dafür, nur bring mal einer TImageList für Toolbar-Icons das SVG-Format bei. Da wünsche ich viel Spaß.

Ich red hier speziell von VCL-Anwendungen. Da pflegt man mitunter drei Bitmap-ImageLists für verschiedene Icongrößen. In den meisten Fällen sind das aufwendig von einer Vektorgrafik runterskalierte Icons, die dann auch noch auf UHD-Bildschirmen wieder hochskaliert werden. Unsinniger gehts ja gar nicht mehr.

Aber nativ gerendertes SVG ist auch kein Pappenstiel. Selbst die ganz teuren zugekauften SVG-Komponenten (wir haben eine für mehrere Tsd. Euro) können nur ein SVG-Subset. Da muss man schon beim Design der Icons wissen, was die Bibliothek kann und was nicht. Einfach mal von einem Designer was pinseln lassen ist nicht möglich. Man kommt z.B. von Indesign oder Corel Draw zu keinem kompatiblen SVG. Am ehesten noch mit Inkscape.

Dabei kann ich mich dunkel erinnern, dass Microsoft schon vor 25 Jahren bei der Entwicklung von NT5 an Vektor-Icons gedacht hatte. Da gabs mal in einer Fachzeitschrift einen Artikel dazu (Internet war ja damals noch nicht so weit).

EDIT: Wenn man mich fragen würde, ich würde ein neues Vektorformat viel eher begrüßen als das drölfzigtausendste Rasterformat. Mit weniger Overhead und weniger parallelen Maßeinheiten. Auf Objektebene würde eine einzige reichen, den Rest regelt man per Scaling auf Viewport-Ebene. Features wie Gradienten wurden ja bei SVG quasi nur "drangeflanscht" durch Container-Markup wie CSS. Also ein einfacher zu parsendes und zu renderndes Format als SVG. Denn für letzteres brauchts inzwischen eine 500-MB-Chromium-Engine wenns halbwegs funktionieren soll.

[mkinzler]

Zitat:

Da wär ich ja prinzipiell sehr dafür, nur bring mal einer TImageList für Toolbar-Icons das SVG-Format bei. Da wünsche ich viel Spaß.

https://github.com/EtheaDev/SVGIconImageList