News JPEG-Alternative: WebP wird jetzt von Edge und bald von Firefox erkannt

N1truX schrieb:

PNG ist speziell auf die verlustfreie Kompression von Grafiken getrimmt und unterstützt zusätzlich einen echten Alphakanal (RGBA). Die verlustbehaftete Kompression von Bildern (JPEG) steht gar nicht auf dem Programm und ist dementsprechend auch keine sinnvolle Ablöse.
Mal was Kurioses …
Im Gegensatz zu PNG, welches verlustbehaftete wie verlustfreie Implementierungen erlaubt, ist GIF sogar – auch wenn‘s kaum Einer glauben mag – ein reines lossless-Format und unterstützt daher ausschließlich verlustfreie Implementierung. Übrigens auch mit bis zu 32.697 Farben.


In diesem Sinne

Smartcom
 
Smartcom5 schrieb:
Im Gegensatz zu PNG, welches verlustbehaftete wie verlustfreie Implementierungen erlaubt,
PNG ist ausschließlich lossless, das rührt allein schon daher, dass intern zlib verwendet wird. Wenn PNG "lossy" wird, wird vorher Preprocessing betrieben, ergo das Original manipuliert, sodass zlib besser komprimieren kann. Deswegen ist PNG aber nirgendwo lossy. Das ist wie wenn ich in einer Textdatei [A-G] durch A ersetze. Lässt sich natürlich auch besser komprimieren mit zip, allerdings ist das Original dann definitiv nicht mehr identisch.
 
HaZweiOh schrieb:
Nur 8 Jahre zu spät! Herzlichen Glückwunsch, Microsoft, das ist eine beachtliche Leistung.
Zur Verteidigung von Microsoft & Co. sollte erwähnt werden dass WebP zwar vor 8 Jahren vorgestellt wurde, aber da befand sich das Format noch in einer frühen unfertigen Phase.
Das Format war nicht "eingefroren"... was bedeutet dass die Entwickler jederzeit nichtkompatible Änderungen vornehmen konnten.

Die finale Version von WebP hat Google erst im April 2018 veröffentlicht; was einem Format-Freeze entspricht. Weitere Funktionen können nur in der Form hinzugefügt werden welche kompatibel zu den Decodern der finalen Version sind.
Ergänzung ()

DrPepperIV schrieb:
Hmm, ob FLIF wohl noch mal Verbreitung finden wird? Das Format klingt auch ganz vielversprechend.
https://flif.info/
FLIF würde mit PNG oder dem verlustfreien Modus von WebP konkurrieren.
Meiner Erfahrung nach hat es allerdings einen entscheidenden Nachteil... die Verarbeitungsgeschwindigkeit.
Das Komprimieren und was noch wichtiger ist das Dekomprimieren dauert min. 5-mal so lange im Vergleich zu PNG.

WebP liegt was die Dekodiergeschwindigkeit betrifft deutlich näher bei PNG.

Niedrige Dekodiergeschwindigkeit bedeutet dass es lange dauert bis das Bild nach dem Aufruf auf dem Bildschirm erscheint, und bei mobilen, akkubetriebenen Geräten reduziert das zusätzlich die Laufzeit.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: DrPepperIV
dMopp schrieb:
Wenn man einfach seine Hassbrille absetzt, dann ist HEIF der logische Nachfolger, da bereits weit verbreitet.
Ein Nachfolger für den gesamten Web-Kosmos kann nur ein Format sein welches die Unterstützung des W3C hat. Nur das W3C kann Formate zu einem Web-Standard erklären.

Und HEIF ist nun mal nicht vereinbar mit den Regeln welches das W3C aufgestellt hat. HEIF basiert auf H.265 Intra-Frames, und H.265 ist ein patentiertes Format.
Damit ein Format zu einem offiziellen Web-Format werden kann darf es nicht patentiert, muss ohne die Zahlung von Lizenzgebühren nutzbar sein u. dessen Spezifikationen müssen offengelegt werden.

HEIF kann daher in der Apple-Galaxie genutzt werden, aber zu keinen Standard im Web-Kosmos werden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Herr Melone, ed25519, Lucy Fagott und 2 andere
Genscher schrieb:

Im Moment ist die Affinity Suite der letzte Schrei mit Affinity Photo, Designer und Publisher. Dort funktioniert auch das Color Management für den Print / Druckerei (selbst getestet).
Leider aber auch dort: Keine Unterstützung für WebP oder HEIF.
Affinity unterstützt doch das WebP-Format zumindest lesend?
kopkr17x18.gif


@HaZweiOh @Yuuri Strikt technisch betrachtet wäre es ja eben nicht unbedingt lossless. Den Grund dafür führst Du @Yuuri ja selbst ja zuletzt an, die Kompression. Ohne Kompression gespeichert ähnelt es ja auch stark TIFF – oder ist zumindest in diesem Falle derart identisch, daß es Byte-kompatibel als solches gelesen werden kann. Tiff unterstützt übrigens auch Kompression nach JPEG …

Du schreibst ja selbst, daß wenn es verlustbehaftet komprimiert und sobald preprocessing betrieben wird, daß Original nicht mehr Bit-identisch rekonstruiert werden kann. Das ist per Definitionem lossy.


In diesem Sinne

Smartcom
 
HaZweiOh schrieb:
- sowie die Content-Ersteller, die jetzt einfach immer WebP erzeugen können, ohne zu überlegen, wann sie JPG und wann sie PNG nehmen und wie sie dessen Größe auf ein vertretbares Maß eindampfen können.
Ein Content-Ersteller muss dennoch entscheiden mit welchen Qualitätseinstellungen dieser Bilder mit WebP erstellt und
für welche Bilder dieser den verlustbehafteten und für welche den verlustfreien Kompressionsmodus von WebP verwendet.
Vorteil von WebP ist jedenfalls dass Transparenz für beide Modi unterstützt wird,
während JPEG ohne Transparenz auskommen muss.

Nachteil, soweit mir bekannt. Mehr als 24 Bit (pro Bildpunkt) unterstützt WebP nicht. Ist ein Nachteil falls man Bilder mit HDR übertragen möchte.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Smartcom5
DrPepperIV schrieb:
Hmm, ob FLIF wohl noch mal Verbreitung finden wird? Das Format klingt auch ganz vielversprechend. Nach Eigendarstellung schlägt es WebP auch in vielen Szenarien.
https://flif.info/
nein FLIF wird sich nicht durchsetzen weil es extrem langsam ist wohingegen WebP auf sämtlichen Direct3D9-PCs und aktuellen Smartphones Hardware-en&decoder existieren.
weiterhin ist die lizenzfreiheit von webp noch ein weiterer fundus der nicht zu unterschätzen ist.
die nächste stufe ist die auskoppelung der framecodierung des kommenden AV1-videocodecs in ein WebP-Update.
 
  • Gefällt mir
Reaktionen: Smartcom5
Wie siehts bei WebP/HEIF mit Farbprofilen aus? Werden die alle sauber unterstützt? PNG kann sowas z.b. nicht, JPG schon. Ohne Farbprofile wird sich das wohl kaum durchsetzen.
 
dMopp schrieb:
Also HEIF halte ich für sinnvoller, da bereits millionenfach in Verwendung... Naja.
sicher nicht - webp wird im hintergrund bereits auf mehr geräten angewendet als es PCs gibt.
das liegt unter anderem auch an Android (nativer support) und den webcaches die heimlich
webseiten durch webp komprimiert transportieren, sobald der empfänger webp-support im header kenntlich macht (z.b. mit vivaldi opera und chrome)
und dann wäre noch das lizenzproblem - HEIF ist beim encodieren teuer - webp kostenlos
Ergänzung ()

estros schrieb:
Heif ist ja ein Container, und die Idee dahinter halte ich für klug. Ebenenso wie WebP. Nur wie ich aus der 8 Jahre alten News heraus lese, kann WebP deutlich weniger als Heif. Sollte man dann nicht lieber letzteren unterstützen?
HEIF encodieren heisst lizenz bezahlen - webp ist free
HEIF kann keine 24bit-Animationen mit Alphakanal - webp schon
HEIF ist ausgebaut - webp ist noch ausbaufähig (ist ja grad bei v0.5)
HEIF muss per software encodieren - weil hardware teurer ist (und kaum vorhanden)
webp kann auf bereits verwendete kostengünstige hardwareencoder zurückgreifen
um hardwarebeschleunigung zu nutzen
man könnte die basis von VP8 zu AV1 wechseln - und erweiterte farbräume hinzufügen
so gesehen gibt es nichts was dem webp gegenüber dem HEIF verschlossen bliebe
eher umgekehrt (zukünftig) ..
Ergänzung ()

dMopp schrieb:
Der Kunde dem die Bandbreite für JPEGs fehlt, fehlt auch die Rechenleistung für WebP... Totgeburt.

Soll Google halt Handybilder in WebP speichern wie Apple es mit HEIF mach. Und dann dann JPEG nach draußen.

dann wird apple ein problem haben - weil es keine günstigen hardwareencoder für HEIF gibt..
für webp ist in so gut wie allen GPUs von grafikkarten oder Smartphones-SOCs kostengünstige en&decoder vorhanden
rechenleistung ist so gesehen eher bei HEIF das problem - nicht bei WebP
Ergänzung ()

k0ntr schrieb:
und wer genau braucht WebP momentan? Glaube das junkt gerade die wenigsten

die meisten nutzen webp ohne das sie merken das sie damit zu tun haben...
schon gewusst dass es mehr geräte gibt die webp nativ unterstützen als es windows-pcs gibt?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ed25519, Smartcom5 und HaZweiOh
Dafür dass die Performance ein Problem sein soll, klappt das aber auf allen iPhones seit iOS10?(oder 11? ka mehr) wunderbar auch auf JAHRE alter Hardware
 
Ist bei WebP auch kein Problem, aber das spielt keine Rolle.

Ein dermaßen Patent-verseuchter Codec wie HEVC / H.265 / HEIF ist zum Scheitern verurteilt, sagt sogar der Gründer der MPEG LA! Und der muss es wissen.

Die Gebühren sind weder einfach zu entrichten (ein gemeinsamer Patentpool), noch schützen sie zuverlässig vor Klagen und sind auch noch übertrieben teuer, und das bei unterlegener Technik!

Bei H264 war das noch anders.
 
Zuletzt bearbeitet:
WebP unterstützt:
- Animation
- Transparenz (+ Alpha-Kanal)
- Metadaten
- Farbprofile
- verlustbehaftete als auch verlustfreie Kompression

Was ich mittlerweile als Nachteil ansehe ist dass die verlustbehaftete Kompression auf dem alten VP8 Format basiert.

Einen wirklichen Vorteil bringt WebP gegenüber JPEG nur wenn man auf noch brauchbare Bildqualität bei kleinen Datenmengen setzt, also die Bilder sehr stark komprimiert;
ist bei HEIF vs. JPEG allerdings nicht anders.

Den verlustfreien Modus finde ich echt gut. Besonders Fotos werden deutlich besser komprimiert im Vergleich zu PNG... und diese werden noch einigermaßen flott dekomprimiert.
 
Conqi schrieb:
Safari läuft aber auch auf iOS und damit reden wir über einen absolut nicht mehr vernachlässigbaren Marktanteil.
Ist irgendwie Nonsens. Ob und inwieweit sich HEIF zumindest im Apple-Universum durchzusetzen vermag, spielt für das Web an und für sich gar keine Rolle, nicht mal so ein bißchen. Was Apple auch immer gedenkt zu unterstützen, besitzt ausschließlich in Apples iUniverse eine Relevanz – wie @Lucy Fagott und hier insbesondere @WinnieW2 schon richtigerweise aufzeigen. Sonst nirgendwo, und das Korsett wurde über die Jahre nur noch enger geschnürt …

Hat damals angefangen mit mit Formaten wie AIFF, über Apple Lossless Audio Codec (ALAC), oder Hardware-Features wie ADP, AppleTalk™, Firewire™, Lightning et cetera pp. Apple will ja gar nicht einen Standard außerhalb ihres geschlossenen Ökosystems setzen – das wollten sie nie, mit egal welchem Vorstoß. Das, was Apple immer wieder treibt, ist, einen eigenen Standard zu etablieren, der absichtlich und gewollt inkompatibel zum Rest der Welt ist – auf daß man eben ihr überteuertes Equipment nutzen möge, oder aber davon zu lassen hat.

Das war immer schon so und das wird auch immer so bleiben. @HaZweiOh Hat's ja wunderbar am Beispiel Vulkan gezeigt. Da wird dann aus Prinzip Metal aufgelegt, was mal wieder obligatorisch inkompatibel ist. Warum? Es ist schlicht gewollt …

Und wenn man sich einmal das Schema anschaut, was Apple da immer wieder fährt, dann sieht man, daß es immer wieder das Selbe ist; Es wird immer nur eine bereits vorhandene Technik/Technologie genommen, diese propietär verändert, auf daß sie gewollt inkompatibel ist – und man hat das Ziel der Nichtvereinbarkeit zu anderen Techniken. Das war selbst bei ADB schon so (modifizierte serielle Protokolle), Firewire (Sony hat‘s ursächlich erfunden), Lighning (Intel), der Hauptgrund, weswegen man jahrelang SCSI verwendete (während der Rest der Industrie IDE nutzte) und so weiter.

Und auch HEIF ist nicht eine kausale Erfindung Apples, sondern existierte bereits zuvor …
Und zwar in Form des Better Portable Graphics-Formates, kurz .bpg. Beide Formate ähneln sich zufälligerweise außerordentlich stark. Zufall, nicht?


In diesem Sinne

Smartcom
 
Zuletzt bearbeitet: (Fix. ;-)
  • Gefällt mir
Reaktionen: WinnieW2, HaZweiOh und SVΞN
Nutze schon lange WebP, ist ein klasse Format. Kann Animationen wie GIF und Alpha-Kanal wie PNG und ist ~30% kleiner als JPEG, hat also das Zeug zum echten Allrounder. Sogar in Kodi ist der Support inzwischen drin nachdem ich mir den offiziell gewünscht hatte ;)
 
Smartcom5 schrieb:
Ist irgendwie Nonsens. Ob und inwieweit sich HEIF zumindest im Apple-Universum durchzusetzen vermag, spielt für das Web an und für sich gar keine Rolle, nicht mal so ein bißchen.

Es ging doch gar nicht darum, ob sich HEIF durchsetzt, sondern darum, dass es egal ist, ob Apple WebP unterstützt und das sehe ich eben nicht so. So lange Apple das nicht unterstützt, muss jede Webseite immer einen Fallback bereitstellen, denn alle iOS-User auszusperren kann sich ein Anbieter heutzutage nicht erlauben.
 
  • Gefällt mir
Reaktionen: ed25519
Zurück
Oben