Diskussion:Graphics Interchange Format

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Graphics Interchange Format“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

True-Color-GIFs

Hier ist ein GIF-Bild mit 32697 Farben zu sehen. Ist der Text „bis zu 256 verschiedene Farben“ dann nicht falsch? --Ahellwig 17:33, 29. Mai 2005 (CEST)

Du hast recht. Das Problem ist, daß die Verwendung von mehreren Bildblöcken für mehr als 256 Farben im Grunde ein Workaround ist, bei dem animierte GIFs verwendet werden und jeder Frame ein Teilbild von 16x16 Pixeln ist (daher auch der langsame Bildaufbau im Browser). Die gängigen Programme unterstüzen solche Hacks sowieso nicht. Es müßte also heißen "256 Farben pro Bildblock" oder "256 Farben pro Einzelbild". Phrood 18:39, 29. Mai 2005 (CEST)

Nein das ist kein Hack sondern war schon immer vorgesehen. Nur die Unterstützung aktueller Software für dieses alte Feature ist nicht so überzeugend. Alte Netscape-Versionen konnten diese Bilder schneller anzeigen als aktuelle Software. Weitere Infos zu TrueColor -GIFs siehe auch: http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=12781140&forum_id=117517

Das ist nicht korrekt, GIF war nie für Echtfarben ausgelegt. Das Missverständnis rührt daher, dass GIF das Speichern mehrerer Bilder von jeweils maximal 256 Farben in einer Datei erlaubt. Webbrowser haben diese Einzelbilder später als Animation interpretiert. Bei den so genannten "True-Color-GIFs" wird das Originalbild in Einzelbilder von 16x16 Pixel aufgeteilt, die separat komprimiert werden. So eine krude Methode kann nur als Hack bezeichnet werden. Klar, dass das verlinkte Bild als GIF 853 KiB und als PNG nur 482 KiB groß ist. Der Forenbeitrag, der True-Color-GIFs als "stark im kommen" bezeichnet, ist inkompetent und unverantwortlich --Phrood 19:34, 18. Mai 2007 (CEST)

Phrood, lies einfach den ganzen Thread in genanntem Forum. Da werden alle von dir genannten Punkte angesprochen. Ich will das jetzt nicht alles wiederholen.

Hinweise darauf, dass die Speicherung von True-Color-GIFs von Anfang an als Einsatzmöglichkeit der Einzelbilder vorgesehen waren, konnte ich im Thread nicht entdecken --Phrood 22:54, 18. Mai 2007 (CEST)

dann lies mal http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=12781748&forum_id=117517 und http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=12782568&forum_id=117517 sowie http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=12782568&forum_id=117517 bei gif87a dachte noch niemand an Animationen!

• "GIF ist von Anfang an für sowas erfunden worden, sonst wäre die Möglichkeit dafür nicht bereits in der allerersten Spezifikation GIF87a berücksichtigt worden." - Nicht unbedingt. Es wäre auch möglich, dass die Funktionalität dazu diente, ähnlich wie bei Icons Bilder in verschiedenen Größen bereitzustellen. Selbst wenn GIF für True Color entworfen worden wäre - einen Beleg bleibt der Autor schuldig - so hätte sich das wohl nur auf kleine Bilder bezogen.
• "bei großflächigen Bildern mit einer mittleren Anzahl von Farben (einige tausend), wie sie bei Screenshots typischerweise vorkommen, komprimieren True-Color-GIFs sogar deutlich besser als PNGs. In diesem Bereich hat die PNG-Kompression offenbar eine Schwachstelle." - Ohne Beispiele glaube ich das nicht. Sowohl Deflate als auch LZW sind General-Purpose-Komprimierungsalgorithmen ohne offensichtliche Schwachstelle, und PNG hat den Vorteil der zusätzlichen Vorfilterung. --Phrood 19:14, 22. Mai 2007 (CEST)

Es ist doch vollkommen irrelevant, was sich die Erfinder von GIF87a nun genau gedacht haben. Das lässt sich jetzt wohl auch nicht mehr in Erfahrung bringen. Tatsache ist, die Spezifikationen lassen Truecolorbilder zu, also kann man dieses Feature auch nutzen. Klar, png komprimiert da (fast immer) besser, aber was solls? Man nimmt eben das Format was man für eine Anwendung zur Verfügung hat. Und gif ist ziemlich universell/flexibel und verbreitet, also kann man es auch nehmen ohne jedesmal die Bits zu zählen, ob ein anderes Format besser komprimiert. Nur in wenigen Fällen ist die maximal mögliche Komprimierung notwendig. Jedes Format hat seine Vor- und Nachteile. gif komprimiert bei kleinen piktogrammen auch besser als png - und trotzdem nehmen viele Leute dafür png. Ja viele setzen heute, auch für größere Bilder, sogar noch bmp ein, wofür ich allerdings kein Verständnis habe. Aber im Allgemeinen komprimiert png besser als gif, ich glaube, das verneint hier niemand.

Gerade kleine Piktogramme sind mit PNG kleiner, weil das Format weniger Meta-Overhead hat. Es dürfte kaum gelingen, ein derartiges PNG zu finden, das nach pngrewrite und PNGOUT größer als das entsprechende GIF ist. Falls du eines findest, wäre ich überrascht. - Ich denke, bezüglich True-Color-GIFs sind unsere Positionen klar. Die Spezifikationen lassen True-Color-Bilder zu, ich bezweifle aber weiterhin, dass das auch ein erwünschtes oder eingeplantes Feature war. --Phrood 22:27, 22. Mai 2007 (CEST)

Ich habe jetzt keine kleine Piktogramme als Demonstration vorrätig. Habe willkürlich folgende hergenommen http://www.bildblog.de/faq.gif und http://src.selfhtml.org/de.gif und mittels gimp nach png konvertiert. Dabei ist die Dateigröße größer geworden. pngrewrite und pngout habe ich jetzt nicht ausprobiert. Du kannst es ja nachholen.

Was die Truecolor Fähigkeit von gif betrifft, möchte ich abschließend sagen, dass die Aussage, bei gif wären nur 256Farben möglich, schlicht falsch ist, unabhängig davon, wie "unelegant" die Truecolornutzung jetzt sein mag und was sich der gif-Erfinder ursprünglich gedacht hat.

Stimmt, ich bekomme bei diesen Piktogrammen auch größere Dateien. (faq: gif 138, png 176; de: gif 59, png 98). Ich habe mal beim DE-Bild nachgesehen, die tatsächen Bilddaten sind praktisch gleich groß, also ist hier der Overhead von PNG sogar höher. Hm. - Im Artikel steht doch gar nicht, dass nur 256 Farben möglich wären, sondern nur "bis zu 256 verschiedene Farben pro Einzelbild". --Phrood 14:20, 23. Mai 2007 (CEST)

Übrigens: da die Vorschau von Windows Vista nur den ersten Frame einer GIF-Animation anzeigt, zeigt sie bei einem True-Color-GIF nur das erste Teilbild an. --Tilka 06:26, 3. Dez. 2007 (CET)

Beispiel für ein TrueColor-GIF87a wurde im Wikiartikel leider gelöscht

Wer folgendes Beispiel http://img140.imageshack.us/my.php?image=truecolordy3.gif besser in den Wikiartikel einbinden kann, möge das bitte tun. Ich kann die Löschung nicht nachvollziehen!

Phrood, das GIF-Truecolor-Bild (http://img140.imageshack.us/img140/5452/truecolordy3.gif), dessen Link du am 22.5.07 (und auch schonmal vorher) entfernt hast, ist ein gif87a. Das andere (http://ipal.org/phil/tc.html) im Wikiartikel ist ein gif89a. Deshalb finde ich, dass man mindestens das gif87a-Bild verlinken sollte. Andernfalls wird nicht gezeigt, dass das Truecolorfeature schon bei gif87a vorhanden war.

OK, wenn du willst ersetze den vorhandenen Link --Phrood 22:27, 22. Mai 2007 (CEST)

Maßstab

Das Gif Format kann meines Wissens keine Auflösung speichern. Wenn eine technische Zeichnung komprimiert gespeichert werden soll, dann wäre das Gif Format günstig, weil keine JPG Artefakte, weil kompatibel, weil technische Zeichnungen mit wenigen Farben gut dargestellt werden können. Das Fehlen der Auflösung verursacht, dass die Zeichnung beim erneuten Öffnen mit einer Default Auflösung z.B. 72 dpi dargestellt wird. Für Skizzen ist eine Auflösung von 72 dpi eindeutig zu wenig. Daher wird beim Erzeugen der Zeichnung eine höhere Auflösung verwendet, die beim Speichern im Gif Format leider verworfen wird. Leider hat das Png Format das gleiche Problem. PCT und das PCX Format speichern die Auflösung. Diese Formate beim Speichern nicht so flexibel wie das Png oder das Gif Format. Die erzeugten Dateien sind größer. Fazit: Gif und PNG sind Bildschirm orientierte Dateiformate. Für CAD oder Print nur eingeschränkt geeignet. (Getestet mit Adobe Photoshop CS)

PNG kann sehr wohl die physische Auflösung speichern, dazu gibt es den pHYS-Chunk, und er wird auch von aktuellen Photoshop-Versionen gespeichert. --Phrood 19:44, 18. Mai 2007 (CEST)

Es gibt Möglichkeiten, EXIF- oder XMP-Informationen in GIF (als Kommentar) abzulegen, wie z.B. die Auflösung. -- anonym, 09.11.08

Patentfrei?

Siehe Heise.de

GIF/PNG

Es würde mich interessieren, welches die Eigenschaften von GIF sein sollen, die von PNG nicht unterstützt werden. --Phrood 17:26, 1. Dez 2005 (CET)

Soweit ich weiß, gibt es in PNG Erweiterungschunks für spezielle GIF-Eigenschaften wie Bildposition. Daher habe ich den Satz entfernt. --Phrood 12:17, 9. Dez 2005 (CET)

Hallo, Danke für den Artikel. In Deutschland sagt doch aber wohl kein Mensch "dschif" - oder sind nur wir in Kiel so dumm "Gif" zu sagen ? :-)(ka'Ahnung, wie ich Lautschrift schreibe). Gibt es konkrete Personen, die als Erfinder gelten, oder nur Compuserve Entwicklungsabteilung (o.ä.)? - snork

Die Aussprache ist nicht definiert, aber einer der GIF-Entwickler spricht das Format "dschif" aus, daher dürfte das als "offizielle" Aussprache gelten. Laut dem en. Artikel hieß dieser Entwickler Bob Berry (die Komprimierung aber stammt von Lempel, Ziv und Welch). --Phrood 17:53, 5. Mai 2006 (CEST)

Verlustfrei??

Wie kann gif verlustfrei sein? Gif unterstützt nur 256 verschiedene Farben, wenn ich ein Bild mit mehr als 256 Farben als gif kodiere, muss also eine Quantisierung erfolgen. Vielleicht wäre in diesem Zusammenhang auch interessant welche Algorithmen außer dem Lempel-Ziv-Welch benutzt werden... --UxPx 19:40, 5. Jan 2006 (CET)

Die Quantisierung findet vom Bildbearbeitungsprogramm statt und ist nicht Teil der Kompression. Für GIF wird nur LZW benutzt. PNG benutzt Deflate (LZ77), manche BMPs und TIFFs verwenden RLE, etc. --Phrood 19:46, 5. Jan 2006 (CET)

GIF kann immer dann problemlos verlustfrei sein, wenn die Quellgrafik maximal 256 Farbnuancen aufweist. Selbst darüber hinaus ist es (theoretisch!) mittels des Animationstricks möglich, beliebig viele Farben verlustfrei abzuspeichern. Lohnt nur den Aufwand nicht :O) --DemonDeLuxe :O) 02:50, 26. Jul 2006 (CEST)

Ist denn diese Möglichkeit in der Spezifikation beschrieben oder wird zumindest von den üblichen Programmen unterstützt? -- Memset 16:27, 26. Jul 2006 (CEST)

Die Möglichkeit ergibt sich implizit. GIF bietet mehrere Varianten, wie mit einem Frame beim Übergang zum nächsten zu verfahren ist; eine davon ist "alles so stehen lassen" (eine andere wäre "revert to background". Wenn man also frameweise Paletten verwendet und Frame 1 in der oberen Bildhälfte 256 Rottöne darstellt und Frame 2 256 Blautöne in der unteren Hälfte, sieht man in Frame 2 dann 512 Farben gleichzeitig. Ich habe gestern 'mal testweise so eine Grafik mit ca. 2000 Farbnuancen erstellt (hatte den obigen, wesentlich eindrucksvolleren, Link zu spät gesehen), und jedenfalls MSIE6 und Firefox 1.5 machen das problemlos. IIRC hatte ich mit diesem Späßchen allerdings bereits 1996 herumexperimentiert, und schon damals konnten die Browser das. Nur, wie gesagt: Lohnt nicht, ist eher "Trivia" *g*. --DemonDeLuxe :O) 16:50, 26. Jul 2006 (CEST)

Achso jetzt versteh ichs. -- Memset 23:07, 26. Jul 2006 (CEST)

Vergleich mit PNG/MNG

bitte unter diesem Abschnitt erwähnen, ob MNG Alpha-Transparenz (wie PNG) unterstützt oder auch nur die schlappe binäre GIF-Transparenz!!! --Hobster 10:17, 21. Feb 2006 (CET)

Ich habe das mal unter MNG ergänzt. --Phrood 13:11, 21. Feb 2006 (CET)

Ich finde es übrigens etwas merkwürdig, bereits in der Einleitung PNG so hoch zu loben. PNG hat ja in der Tat einige Vorzüge, aber das gehört m.E. absolut nicht in die einleitende Begriffserklärung. Liest sich ein bisschen wie "GIF? Was wollen Sie denn überhaupt mit GIF, das braucht heute kein Mensch mehr!". --DemonDeLuxe :O) 10:52, 5. Aug 2006 (CEST)

Im Prinzip hast du recht, Erwähnung in den vorgesehenen Abschnitt verschoben --Phrood 11:09, 5. Aug 2006 (CEST)

Dangö - sag'mal, inwiefern wurde Interlace bei PNG "verbessert"? Ich hab' mich da noch nie eingelesen, was ist denn da anders? Bei den heutigen Verbindungen sieht man den Effekt ja eh' immer weniger. --DemonDeLuxe :O) 12:11, 5. Aug 2006 (CEST)

Adam7 --Phrood 12:23, 5. Aug 2006 (CEST)

Ah, exzellent. Man lernt doch nie aus - Wikipedia muss man einfach lieben :O) --DemonDeLuxe :O) 12:39, 5. Aug 2006 (CEST)

Weblinks

Begründung für Löschung der beiden Weblinks:

• Auf http://www.computerhilfen.de/magazin_grafikformate.php3 wird behauptet "Um mehr als die 256 Farben zu simulieren, nutzt das GIF-Format einen optionalen "Dither-Modus", was irreführender Unsinn ist.
• http://www.gif-bilder.de/lexikon/gif.html bietet gerade mal zwei Absätze zum Format und enthält nichts, was nicht auch im Artikel steht. --Phrood 13:23, 14. Mai 2006 (CEST)

Wieso wurde der Link zum 2000x2000 Pixel Gif gelöscht? Man sieht doch den Qualitätsverlust viel besser als bei diesem mini Sunflower. Zur Info: Die 4 Mpx Gif wurde nicht hochskaliert, im Gegenteil. Ursprünglich war es eine Aufnahme aus einer 8 Mpx-Kamera. Die Kombination aus einem hochauflösenden Foto und Grafiken zeigen detailiert wo die Schwächen und Stärken dieses Formats liegen. Der Link ist eine Bereicherung und kein, wie wahrscheinlich angenommen "Backlink-Hascherei". MfG Silencio

Der Link bietet wirklich keine weiterführenden Informationen. Wenn das Sunflower-Bild dir die Farbquantisierung nicht deutlich genug zeigt, kann man es durch ein anderes ersetzen. --85.214.71.55 20:19, 16. Jan. 2007 (CET) (Phrood)

Standard?

Hat CompuServe sein GIF Format (wie das bei PNG geschehen ist) auch von der ISO zum Standard erklären lassen, bzw. vom W3C Konsortium zur "Empfehlung" ? --Uwe W. 19:32, 31. Mai 2006 (CEST)

AKAIK nein. --Phrood 20:15, 31. Mai 2006 (CEST)

Interlacing

Ich habe gehört, dass man bei GIF Interlacing einstellen kann. Stimmt das? Wenn ja, wie geht das und wie funktioniert dann der Bildaufbau?

Ja, das ist möglich. Kann in den Einstellungen beim Speichern eingestellt werden. Der Bildaufbau erfolgt jeweils in 8 Pixel hohen Streifen, bei denen Zeile für Zeile übertragen wird. --Phrood 19:32, 4. Aug 2006 (CEST)

Mh, ich hab' das etwas anders in Erinnerung:

Abgespeichert wird das Bild quasi in mehreren Durchläufen: Zunächst jede 8. Zeile, dann jede 4., dann jede 2. und schließlich der Rest. Bei der Darstellung werden die eingelesenen Zeilen in der jeweils korrespondierenden Höhe dargestellt, so dass sich der Eindruck beim Betrachter einstellt, das Bild wäre zunächst grob gerastert und würde dann stufenweise immer feiner - was ja auch der Sinn der Sache ist. --DemonDeLuxe :O) 22:53, 4. Aug 2006 (CEST)

Entschuldigung, DemonDeLuxe hat natürlich Recht. --Phrood 22:55, 4. Aug 2006 (CEST)

• ächz* und ich hatte schon Sorge, mein Erinnerungsvermögen würde trügen, ehrlich. Ist schon so lange her... *g* --DemonDeLuxe :O) 23:27, 4. Aug 2006 (CEST)

sicher? Wird nicht im zweiten Schritt ebenfalls jede 8. Zeile(um 4 Zeilen verschoben) übertragen woraufhin dann jede 4. Zeile vorhanden ist usw.? Nach obiger Vorgehensweise würden Daten redundant übertragen, und zwar würde jeweils der vorgegangene Schritt für die jeweilige Darstellung unnötig, zumindest hinsichtlich der Datenmenge. Bestätigen kann ich das leider nicht. --maexs 3:00, 2.Feb 2007 (CEST)

Hast Recht. Siehe Appendix E auf [1] --Phrood 02:50, 2. Feb. 2007 (CET)

(Anm.: Danke für die Korrektur in Sachen "Progressive JPG", ich dachte immer, das sei im Prinzip derm GIF-Interlacing vergleichbar). --DemonDeLuxe :O) 10:50, 5. Aug 2006 (CEST)

GIFF

In der Engischen Wikipedia steht das GIF auch als „GIFF für Graphics Interchange File Format“ bekannt ist, jedoch wurde diese information wieder aus dem Artikel entfernt. Ist der zweite Name nicht relevant genug um erwähnt zu werden? --Uwe W. 20:00, 24. Aug 2006 (CEST)

Der Name wird in der Einleitung erwähnt. Eine Formatierung in Fettschrift halte ich für übertrieben. --Phrood 20:38, 24. Aug 2006 (CEST)

Aber eine eigene Zeile für den Namen GIFF halte ich für sindvoll.--Uwe W. 10:56, 25. Aug 2006 (CEST)

Vorlage: Mediaformate

Bitte Vorlage "Mediaformate" hinzufügen! :)

GIFs sind nun mehr oder weniger patentfrei!

Siehe c't-Meldung. --84.156.124.115 11:24, 2. Okt 2006 (CEST)

der Genauigkeit halber wäre es schön, wenn wir etwas mehr als Heise zu bieten hätten - die bleiben ziemlich schwammig, was denn jetzt genau noch nicht frei war. Und warum soll das Format erst am 1. Oktober komplett frei sein, wenn das Patent, wie es hier im Artikel steht, am 11. August auslief? Wir sind also auch ziemlich ungenau - falls jemand die Patentnummern hat, wäre es schön, diese als Quellen in den Artikel einzufügen, und evtl. noch weitere Informationen zu ergänzen. -- 217.84.166.2 13:03, 2. Okt 2006 (CEST)

golem.de, GNU.org --84.156.124.115 23:03, 2. Okt 2006 (CEST)

Unterstützung von PNG

Im Text stand volgender Halbsatz: , und die noch relativ neue Unterstützung von großen Teilen der Webgestaltergemeinde bisher nicht ausgereicht hat um PNG als GIF-Ersatz zu etablieren.
Ich habe bisher von großer Unterstützung der Webgestaltergemeinde für PNG sonst nirgens gehört oder gelesen und desshalb das Wort großen als POV entfernt.--Uwe W. 20:36, 5. Dez. 2006 (CET)

Transparenz

Meines Wissens unterstützt GIF nur einen 1Bit Alphakanal. D.h. ein Pixel (Bildpunkt) ist entweder total transparent oder gar nicht. Der "Alphakanal" wird bei GIF dadurch erreicht, dass eine der 256 Farben als Hintergrundfarbe definiertwird. Halbdurchlässige FLächen(Pixel), wie bei PNG (JPEG keine Transparenz), sind nicht möglich. Fliessende Transparenz ist u.a. in Homepages für 'moderne' Effekte, wie in Grafiken eingebaute Schatten, mittlerweile wünschenswert. Gerade deswegen wird auf älteren Homepages, auf denen im Sinne von 'Eye-Candy' Blend-Effekte eingesetzt werden sollen, auf das PNG umgestiegen, auch wenn der Umstieg ansonsten unrentabel gewesen wäre. Maexs

Revert

Ich habe mit deinen Änderungen einige Probleme:

• Die Unterstützung von Teilen der Webgestaltergemeinde ist relativ neu. - Ich verstehe den Satz nicht.
• Flächenddeckendes umkonvertieren oder neuerstellen bestehender GIF Dateien im PNG Format währe sehr aufwändig und damit bei der großen Anzahl von Webseiten zu teuer. - Was soll daran aufwändig und teuer sein? Es gibt Programme, die das mit einem Mausklick erledigen.
• Wenn sich die Beschränkung auf 256 Farben bemerkbar machen würde verwenden die meisten Programierer warscheimlich gewohnheismäßig das bewärte JPEG Format. ...das aber nur für Fotos geeignet ist und bei Zeichnungen, Diagrammen etc. viel zu große Dateien für die gleiche sichtbare Qualität erzeugt.

Außerdem ist WP eigentlich nicht der Platz für Mutmaßungen.

Und bitte, Uwe, bemühe dich etwas mehr um Rechtschreibung! --Phrood 12:57, 6. Dez. 2006 (CET)

Hallo Pood, da habe ich wohl mal wieder nicht genug nachgedacht und Grafiken mit vielen Farben vergessen. Ich habe nämlich bei der Beschränkung auf 256 Farben nur an Fotos gedacht, da Icons und einfache Grafiken meistens weniger als 256 Farben haben. --Uwe W. 14:49, 6. Dez. 2006 (CET)

GIF und LZW

Warum darf GIF nicht mit LZW verwechselt werden? --88.76.252.73 13:29, 28. Jan. 2007 (CET)

Weil es zwei verschiedene Dinge sind. GIF ist ein Dateiformat, LZW ein Komprimierungsalgorithmus. --Phrood 18:33, 30. Jan. 2007 (CET)

Warum wird GIF häufig mit LZW verwechselt? --88.76.250.49 15:52, 31. Jan. 2007 (CET)

Das es das wird sei mir neu. GIF wird (wurde) wohl häufig in Verbindung mit LZW gebracht, da das Komprimierungsverfahren LZW in GIF-Dateien Verwendung findet (beim Aufkommen des Formats den alt hergebrachten RLE-Verfahren teils überlegen) und hierauf auch Patente meldete (noch gültig? siehe oben.) Maexs 23:08, 05. Mar. 2007 (CET)

Aussprache

Wie wird "GIF" ausgesprochen: a) [dʒɪf]; oder b) [gɪf]? --88.76.242.17 16:05, 30. Jan. 2007 (CET)

Ersteres ist richtig, steht auch so im Artikel. S.a. engl. Artikel: According to the creator of the "GIF" format, Steve Wilhite, the pronunciation is with a soft "g" --Phrood 18:32, 30. Jan. 2007 (CET)

GIF als Trademark?

Ich habe auf dieser Internetseite gesehen das immer hinter dem Wort GIF das ™ Zeichen geschrieben wurde. Ist der Name GIF von Compuserve Markenrechtlich geschützt worden? Besteht der Schutz immer noch? Dieses sollte auch im Artikel erwähnt werden.--Uwe W. 10:46, 15. Mär. 2007 (CET)

Verbreitung und Verwendung

Im Text stand "Für größere Bilder und Grafiken im Web ist dagegen das GIF-Format heute eher unüblich, sodass man größere GIF-Bilder fast nur auf alten Internetseiten findet, die schon seit Jahren unverändert existieren [6]." Das ist völlig übertrieben, deshalb habe ich es geändert. Eine Google-Bildersuche nach großen GIF-Dateien mit Suchwörtern "image" und "2007" ergibt 122.000 Treffer. Dieselbe Suche für PNG-Dateien gibt nur 36.400 Treffer. Das ist zwar kein eindeutiger Beweis, bestätigt aber den Eindruck, den man beim Surfen duchs Internet bekommt: Es werden nach wie vor GIF-Dateien auch für größere Bilder verwendet. Nur bei Fotografien ist es tatsächlich unüblich. Das sind dann sehr alte Dateien oder sie wurden von Laien angefertigt, die von Bilddateiformaten keine Ahnung haben. --88.76.202.246 12:59, 22. Apr. 2007 (CEST)

Max. Bildgröße

Ist die Maximale Bildgröße von GIFs auf 65535 Pixel mal 65535 Pixel beschränkt oder auf 16384 mal 16384 Pixel, wie in der voher angegebenen Quelle geschriben wird? Die IP hat für ihren höheren Wert leider keine Quelle angegeben.--Uwe W. 17:05, 24. Apr. 2007 (CEST)

Lipp, Grafikformate gibt auch 16.000x16.000 an. Beim Überfliegen der Spezifikation kann ich allerdings nur ein 2-Byte-Eintrag für Breite und Höhe finden (was 65535^2 wäre). Ich versuche bei Gelegenheit herauszufinden, was richtig ist, inzwischen kann man die Angabe herausnehmen. --Phrood 17:52, 24. Apr. 2007 (CEST)

Ich habe die Bildgröße rausgenommen. --Uwe W. 18:08, 24. Apr. 2007 (CEST)

Hallo Phrood, konntest du schon die korrekte maximale Bildgröße herausfinden?--Uwe W. 18:21, 30. Mai 2007 (CEST)

Leider nein --Phrood 18:28, 30. Mai 2007 (CEST)

Naja was ist denn 2^16 ??? 2^16 = 65536 ist also die maximale theoretische Höhe/Breite ! Meine Fresse.

Da konnte wohl die Pfeife von der TU-Chemnitz nicht richtig den Taschenrechner benutzen.

Davon mal abgesehen gibt die GIF89a Spezifikation den Datentyp als vorzeichenlos an, also sollte man

vielleicht vorher mal die Spezifikationen lesen, bevor man 'ne Arbeit schreibt, Wixer.

Animierte GIFs

Wenn GIF 89a nicht von Anfang an für Animationen ausgelegt wurde, wie es im Artikel steht, welche Funktionen sorgen dann dafür, dass der Ablauf der Animationen gesteuert werden kann, und wofür waren die Funktionen eigentlich gedacht?--Uwe W. 11:12, 30. Mai 2007 (CEST)

Wozu die Multi-Bild-Funktionen ursprünglich dienten, konnte ich nicht herausfinden. Der Ablauf der Animationen wird durch einen speziellen Application-Extension-Block definiert (s. etwa John Miano, Compressed Image File Formats.) --Phrood 12:43, 30. Mai 2007 (CEST)

Speed: Lässt sich die Geschwindigkeit vom User noch verändern, da Animated GIFs manchmal zu schnell oder zu langsam angezeigt werden? --2.247.242.138 21:40, 5. Mär. 2017 (CET)

Der Frage will ich mich anschließen. Welche Möglichkeiten gibt es, die Anzeige einer GIF-Animation zu beeinflussen (z.B. Anzeige als Standbild, manuell durch die Teilbilder gehen, Geschwindigkeit festlegen, ...)? Sei es durch einen Browser bzw. Browser-Plugin oder durch andere Software.--Megatherium (Diskussion) 16:03, 17. Dez. 2019 (CET)

Mit GIF ConstructionSet geht das Imageengineer (Diskussion) 02:10, 15. Mär. 2020 (CET)

GIF-Dateien in der Wikipedia

Kann die deutschsprachige Wikipedia auf animierte GIF-Dateien verzichten? --88.76.240.187 17:15, 23. Jun. 2007 (CEST)

Die Server akzeptieren, zur Zeit (September 2007), keine anderen Animationsformate als das gut unterstützte GIF und animiertes SVG das noch nicht von allen Browsern unterstützt wird (siehe: Hinweis. Das heißt dass viele Leser keine Animationen mehr sehen könnten, wenn animierte GIFs abgeschafft würden. Auch spricht der Aufwand des umkonvertierens gegen die Abschaffung von GIFs.--Uwe W. 23:41, 22. Sep. 2007 (CEST)

Nachricht an Uwe W.

Hallo Uwe. Ehrlich gesagt verliere ich langsam die Geduld mit deinen Minimaledits. In unregelmäßigen Abständen fügst du diesem Artikel unwesesentliche und oft auch zweifelhafte Änderungen hinzu, die ihn nicht wirklich verbessern. Ich kann nicht verstehen, warum du das machst, im Raumfahrt- und anderen Bereichen bist du ja produktiv unterwegs. Ich meine das jetzt nicht böse, aber durch diese ziemlich sinnlosen Edits verursachst du auch eine Menge Arbeit mit der Korrektur deiner Rechtschreib- und Tippfehler. Wärst du bereit, in Zukunft deine Änderungen auf dieser Diskussionsseite anzukündigen, bevor du den Artikel bearbeitest? --Phrood 17:33, 26. Aug. 2007 (CEST)

Gegensatz zu JPEG

Hallo Phrood, im Artikel steht jetzt das GIF im Gegensatz zu JPEG Transparenzen und Animationen darstellen kann. Früher stand dort u.a auch das GIF im Gegensatz zu JPEG Grafiken mit harten Farbübergängen korrekt darstellen kann. Kann ich das wider in den Text schreiben?--Uwe W. 21:26, 29. Sep. 2007 (CEST)

Ich bin dagegen, weil diese Eigenschaft auf alle verlustfreien Formate zutrifft; die Probleme mit harten Farbübergängen sind eher für JPEG ein Thema, wo dieser Sachverhalt bereits erwähnt ist. --Phrood 21:30, 29. Sep. 2007 (CEST)

Unwissenschaftliche Formulierung

Also meiner meinung nach haben Formulierungen wie „...und auch der alte Netscape 4.7x rendern sie flott und korrekt“ in einem Lexikonartikel nichts Verloren. Könnte sich bitte mal jemand um eine etwas schriftsprachlichere Formulierung kümmern? Danke. --Flo 1 16:21, 4. Jan. 2008 (CET)

Stimme ich absolut zu !. Wieder mal pure Werbelust einiger Entwickler.

es gibt kein "GIF-Format"

In diesem Artikel wird häufig die Formulierung "GIF-Format" verwendet, die jedoch falsch ist weil es dann "Graphics Interchange Format-Format" heißen würde. Man sollte stattdessen einfach nur "GIF" schreiben.

Korrektheit des Artikels

Die Qualität des Artikels bezogen auf seine Korrektheit ist, um es sanft auszudrücken, beschissen! Hauptsache es sieht schön aus, naja, typisch. Da wird wild mit True-Color GIFs 'rumgefuchtelt' und das XnView ja diese nicht so toll darstellen kann (davon abgesehen müsste man jedesmal diesen Artikel ändern, wenn eine bestimmte Version jetzt doch in der Lage wäre, diese korrekt darzustellen). Mein Gott ich heul gleich, wie schade für die Benutzer dieses Programms. Welche Schwachmat kam eigentlich auf die Idee mit diesem Schrott ? Ich sage nur PNG, JFIF, TIFF, etc., bitte Dateiformat wechseln!!!

1. Animation:

   Es wird ja immer wieder gerne argumentiert dass GIF, ja fast schon prädestiniert sei für Animation:
   Ich sage nur: "The Graphics Interchange Format is not intended as a platform for
   animation, even though it can be done in a limited way." (Appendix D: Conventions, GIF89a)

2. "Bei GIF sind die Farbinformationen in einer Farbtabelle abgelegt":

   Was soll man dazu sagen: Einfach nur Schwachsinn. Die Betonung liegt bei "in einer Farbtabelle".
   GIFs enthalten entweder keine, eine oder mehrere Farbtabellen, die Aussage ist also demnach FALSCH.

3. "Ab GIF89a kann ein Farbeintrag in der Palette als transparent definiert werden".

  MMhhhh. Wie oben unprezise ("in der Palette").

4. Interlacing

  Das hier beschriebene Interlacing-Verfahren entspricht nicht dem der Spezifikationen. maexs hat es richtig beschrieben

Ich hab die Schnauze voll. Zu 2:

  "Das Graphics Interchange Format bietet die Möglichkeit bis zu 256 Farben (aus 256^3 möglichen) in einer Farbpalette
   abzuspeichern" usw.

Zu 3:

  "GIF Version 89a bietet die Möglichkeit eine Farbe (aus der "Aktiven Farbpalette") als transparent zu definieren".

Zu 4:

  Phase 1: Jede 8. Zeile beginnend mit der 1. Zeile.
  Phase 2: Jede 8. Zeile beginnend mit der 5. Zeile.
  Phase 3: Jede 4. Zeile beginnend mit der 3. Zeile.
  Phase 4: Jede 2. Zeile beginnend mit der 2. Zeile.

Überarbeiten

analog zum ersten eintrag auf der diskussionsseite sind in einem gif-bild sehrwohl mehr als 256 farben möglich, je einzelbild ist die palette natürlich beschränkt True-Color GIF Example ob das nun von gängigen browsern unterstützt wird oder nicht oder obs grafikprogramme verstehen oder nicht (firefox 2, opera 9 und gimp 2 haben jeweils keine probleme damit btw) ist unerheblich --suit 20:23, 1. Okt. 2008 (CEST)

Erstens wurde GIF nie zum Speichern von Echtfarben, sondern allenfalls zum Speichern mehrerer Bilder mit Farbpalette in einer Datei entworfen. Ein Bild zur Wahrung der Farbinformationen in 16x16 Pixel große Blöcke aufzuteilen, war nicht im Sinne der Entwickler. Zweitens ist es sehr wohl erwähnenswert, inwieweit das Format von Anwendungen unterstützt wird. Ein Überarbeiten-Baustein ist jedenfalls gänzlich übertrieben; eher solltest du Vorschläge für bessere Formulierungen auf diese Diskussionsseite schreiben. --Phrood 21:01, 1. Okt. 2008 (CEST)

16x16 Pixel ergeben sich nur bei der Brute-Force-Methode, ohne Optimierungsstrategie. -- anonym, 09.11.08

IBM-Patent vor oder nach Unisys-Patent?

Zitat: "Die Anmeldung erfolgte zwar drei Wochen vor der von Unisys; nach dem Patentrecht der USA bedeutet dies jedoch nicht, dass das IBM-Patent Priorität genießt. Vielmehr dürfte das IBM-Patent aufgrund des früher erteilten Unisys-Patents ungültig sein." – Zitat-Ende. – Wenn es einen Unterschied geben sollte (ich weiß es nicht) zwischen einer Patent-Anmeldung und einer Patent-Erteilung, so ist der zitierte Satz schwer verständlich. Wenn nicht, ist er widersprüchlich. --Suaheli 22:24, 7. Jun. 2009 (CEST)

Quelle für Geschichtserweiterung

2012-12-28 Digitales Daumenkino auf Erfolgskurs Nicht Twitter, nicht Instagram und schon gar nicht Facebook war der Webtrend 2012, sondern ein eigentlich reanimierter Oldie: Das Animated GIF hat seinen späten Siegeszug durch das Netz gestartet. [...] Das Oxford American Dictionary wählte GIF zum Verb des Jahres - und zwar als Verb, sprich das Kreieren eines GIFs.

Bei Olympia fehlt der Hinweis, dass es die strikte Video-Beschränkung gab, die man dadurch umging. (Nur ein oder zwei US-Sender hatten gezahlt und das Recht auf ihren Websites Videos zu haben.)--Franz (Fg68at) 14:51, 28. Dez. 2012 (CET)

überlappend?

Soll wohl heissen übereinanderliegend. -- itu (Disk) 09:38, 10. Nov. 2015 (CET)

GIFV

Leider vermisse ich in dem umfassenden und klaren Artikel jeden Hinweis oder Erklärung zu dem GIF-Video GIFV von imgur, siehe auch hier. -- Ilja (Diskussion) 08:15, 11. Okt. 2016 (CEST)

Überarbeiten !:Das Echtfarbenbild hier hat eine Verzögerung von 2

Das Bild https://upload.wikimedia.org/wikipedia/commons/thumb/b/b7/True_Color_GIF_image-Tc217.gif/150px-True_Color_GIF_image-Tc217.gif Hat eine Verzögerung von 2 anstatt von 0. Die Bildunterschrift "GIF-Bild mit 32.697 Farben, über mehrere Farbtabellen erzielt, eine per Bildblock. (Zeitverzögerter Aufbau durch nicht-spezifikationskonforme Interpretation der Browser eines Verzögerungswert von 0 ms[13])" ergibt also keinen Sinn. --79.225.114.215 21:21, 4. Mär. 2017 (CET)

Animiertes GIF

Vier Fragen werden im Artikel nicht beantwortet:

• Wie wird ein animiertes GIF erstellt?
• Wie kann man ein animiertes GIF "anhalten"? (um Einzelbilder zu sehen)
• Wie wird ein animiertes GIF in Teilbilder zerlegt?
• Was ist die bessere Alternative statt GIF? (wie was wo wann warum)

Gruss, --Markus (Diskussion) 06:15, 22. Jun. 2017 (CEST)

Schwachstellen bei 256index Color Formaten

Gif Dithering fuehrt zu Vergroesserungen der Farbpalletten bei 256 Farben. Nun kann man aber zwischen zwei Farbpixeln einen Farbuebergang durchfuehren. Und zwar gibt man nur einmalig einen Pixelabstand an. Sagen wir pixel max. In 2d dann zwei 2x 16 pixel halfbyte Vektoren zu Anderen Farbpixeln. Und dazwischen interpoliert. Der Unterschied zur reinen Interpolation ist: flexibles Gitter. Und nur da Farbuebergang wo auch ein Uebergang ist. Runlength encoded RLE mit interpolation. Am Ende der 1D Summenkette muss man am Bildrand sein. Die 1d Pixelabstaende formen selbst ein GIF bild. Die Grundpixel sind ein Gif bild. Beides in 1/16 Aufloesung. Nur die Anzahl der Pixel fluktuiert und gibt genau einen Sonderpixelstreifen Leerbild am Rand.

Eine solche 2fach verschachtelte Interpolierte Gif Darstellung mit flexiblem Gitterabstand muss doch moeglich sein. Um Anisotropie zu vermeiden nimmt man den Mittelwert beider Richtungen. Oder fuegt beim Farbuebergangsbereich eine Basisdiffusion von 1Pixel oben/unten Nachbarzeile ein.

Wie macht man einen 2D Uebergang in dem Format? Man nimmt 255 Farben. Nicht 256. Sonderfarbe im Innern bedeutet 2d Pixel Uebergang. Pixelsuche nach vorne oben und vorne unten. Und schon kann man 2d interpolieren. Ohne Abstandsangabe. Das erscheint dann in mehreren Zeilen als patch. Und komprimiert in Gif gut. Gewoehnungsbeduerftig ist nur das ueberlaufen der Zeilen bis man zeichnen kann damit die unteren Punktfarben bekannt sind.

Geht oder geht nicht? Erweiterung Farb Ueberschreitungs Extrapolation dazu wer will. Oder 16x256Farb indexed. Oder Bezier Farb Interpolationspatch 2Farbpixel voran.

2Stufiges Gif. FARBRAUMWAHL dann so anpassen dass es keine Speicherung von Farbuebergaengen sondern nur Primaerpixelfarben gibt. Also SolarisierungsRaender suchen und Pixelfarben indexen. Da speichert man 2Pixel Rand. Dazu innere optimierungspixel.

Wer kann das programmieren und wie sieht das aus

Ist 2Stufiges Gif

Wikistallion (Diskussion) 08:59, 28. Okt. 2018 (CET)

Und nach demselben Prinzip 3D Daten. Also Tomographie oder Video. Rechner sind schnell genug Wikistallion (Diskussion) 09:12, 28. Okt. 2018 (CET)