Dateiformat webp in Delphi VCL

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1480917)

https://github.com/EtheaDev/SVGIconImageList

Da steh ich jetzt schön blöd da :oops: Kannte ich nicht, schau ich mir an und geb dann Feedback.

[Sinspin]

Zumindest ein Hersteller von Komponenten hat auch schon erkannt das es SVG gibt.
Bei DevExpress ist sogar eine schöne Sammlung zum einbauen mit dabei.

[Redeemer]

Zitat:

Zitat von Codehunter (Beitrag 1480912)

Aber nativ gerendertes SVG ist auch kein Pappenstiel.

Da sprichst du mit dem Falschen. Ich hab 2017 mal aus Spaß einen komplett eigenen nativen SVG-Renderer geschrieben. Hat 'ne Woche gedauert. Anschließend ein paar Fixes. Unterschied zu den verlinkten ist, dass meiner GDI (ohne Plus) benutzt. Das ist für mich auch wichtig, weil er EMF-Dateien erstellen und SVGs verlustfrei (bis auf Rundungsdifferenzen) drucken kann. Unterstützung für Raster-Features sind aber durch GDI geringer als bei der GDI+-Lösung.

Mein Hauptprojekt in der Firma enthält 0 Rastergrafiken.

Zitat:

Zitat von Codehunter (Beitrag 1480912)

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.

Mein SVG-Renderer ist etwa 100 KB groß unkomprimiert, was nur daran liegt, dass ich XML selbst parse (weil ich dachte, SVG wäre genau wie HTML kein XML wegen der vielen optionalen Tags, aber SVG ist XML) und sämtliche Entities unterstütze (was auch falsch ist). Ohne das dürfte der unter 50 KB groß sein.

[Codehunter]

Zitat:

Zitat von Redeemer (Beitrag 1480944)

Mein SVG-Renderer ist etwa 100 KB groß unkomprimiert, was nur daran liegt, dass ich XML selbst parse (weil ich dachte, SVG wäre genau wie HTML kein XML wegen der vielen optionalen Tags, aber SVG ist XML) und sämtliche Entities unterstütze (was auch falsch ist). Ohne das dürfte der unter 50 KB groß sein.

Ich meinte auch nicht den Renderer sondern das Dateiformat als solches ist mir zu fett. Damals war XML State-of-the-Art. Heute ist das schon wieder Steinzeit. Aber der Overhead ist das geringere Übel. Ich sehe da eher die vielen Inkonsistenzen. Wenn du willst geb ich dir mal ein paar meiner Test-SVGs, die ich mit Inkscape erstellt habe. Allein schon das ganze Sodipodi-Geraffel da drin...

Sagen wir mal so: Ich habe schon SVGs "zu Fuß" erstellt, nur mit Notepad++, und hatte meinen Spaß dabei. Da kam mir wohl zugute, dass ich schon unter AmigaOS 1.3 und DOS 5.0 grafische Oberflächen gebaut habe. Da hat man noch gelernt in Koordinaten zu denken. Ich glaube, SVG ist so ziemlich das einzige Grafikformat, bei dem die Ursprungskoordinate links unten und nicht links oben ist. Sehr verwirrend, vorallem weil Inkscape das zwischen Version 0.92 und 1.0 getauscht hat ^^

So, aber ich denke wir sind genug OT geworden. Chefe wetzt bestimmt schon seinen Zeigefinger... ;-)

EDIT: Kleine Ergänzung zum Abschluss, weils grad so schön passt: JPEG XL soll JPEG, PNG, GIF umd Webp beerben

[Redeemer]

Zitat:

Zitat von Codehunter (Beitrag 1480946)

Ich glaube, SVG ist so ziemlich das einzige Grafikformat, bei dem die Ursprungskoordinate links unten und nicht links oben ist.

Ist in SVG links oben. Das ist zwar mathematisch falsch, dafür aber konsistent mit allen Grafikformaten.

Zitat:

Zitat von Codehunter (Beitrag 1480946)

Sehr verwirrend, vorallem weil Inkscape das zwischen Version 0.92 und 1.0 getauscht hat ^^

Das hat Inkscape nicht zu entscheiden. Inkscape ist nur irgendein Grafikeditor.

[Codehunter]

https://wiki.inkscape.org/wiki/index...Axis_Inversion

Nicht mehr und nicht weniger hab ich gemeint. Vllt. unpräzise ausgedrückt. Das war sehr verwirrend wenn man "zu Fuß" im NPP das eine Koordinatensystem verwendet und der Wysiwyg-Editor bei einem Versionswechsel das plötzlich auf den Kopf stellt. Man kanns ja umkonfigurieren aber per Default wars kopfüber :roll:

[TurboMagic]

Zitat:

Zitat von Codehunter (Beitrag 1480936)

Zitat:

Zitat von mkinzler (Beitrag 1480917)

https://github.com/EtheaDev/SVGIconImageList

Da steh ich jetzt schön blöd da :oops: Kannte ich nicht, schau ich mir an und geb dann Feedback.

Ist sogar in GetIt drin!

[TurboMagic]

Zitat:

Zitat von Codehunter (Beitrag 1480946)

Ich glaube, SVG ist so ziemlich das einzige Grafikformat, bei dem die Ursprungskoordinate links unten und nicht links oben ist.

BMP ist zwar kein Vektor-Format hat aber den Ursprung links unten.
Ist strenggenommen auch nicht mathematisch falsch, nur ein anderer
Quadrant...

[Redeemer]

Zitat:

Zitat von TurboMagic (Beitrag 1481020)

Zitat:

Zitat von Codehunter (Beitrag 1480946)

Ich glaube, SVG ist so ziemlich das einzige Grafikformat, bei dem die Ursprungskoordinate links unten und nicht links oben ist.

BMP ist zwar kein Vektor-Format hat aber den Ursprung links unten.
Ist strenggenommen auch nicht mathematisch falsch, nur ein anderer
Quadrant...

Das ist falsch. BMP hat überhaupt keinen festgelegten Ursprung für die Y-Achse. Dieser muss vom Nutzer angegeben werden. Bei den allermeisten BMP-Bildern ist das zwar unten links, aber das ist nicht festgelegt.

[TurboMagic]

Um nochmal kurz zum WEPB Thema zurück zu kommen:
SKIA für Delphi sollte dafür Unterstützung haben, sagt zumindest deren GitHub Beschreibung:
https://github.com/skia4delphi/skia4delphi

Und ich hab' neulich wo gehört, dass EMBT in Zukunft auch mehr mit SKIA machen will...