Diskussion:Vektorgrafik

2 1/2D Modell

Weiß jemand was dazu? (vgl. http://www.doku.net/artikel/vektorgraf.htm)

Alter Kram

(obsolete Einträge nach Versionen verschoben, Anton 17:55, 20. Jan 2006 (CET))

PDF

Weder PDF noch EPS sind Vektorgraphikformate. PostScript und PDF sind Seitenbeschreibungssprachen bzw. -formate, welche neben Rastergraphiken, Schriftsatzanweisungen und anderem mehr auch Vektorgraphiken enthalten können. --Jwilkes 15:23, 16. Jan 2005 (CET)

Ich finde es falsch, PDF und PostScript hier total außen vor zu lassen. Mit PDF kenne ich mich nicht besonders aus, aber PostScript ist definitiv ein wichtiges Format wenn es um Vektorgrafiken geht. Meines Wissens wurden mit PostScript erstmals Vektorschriften statt Bitmapschriften für Matrixdrucker eingesetzt. Heute ist das eine Selbstverständlichkeit. Natürlich ist die Unterstützung von Rastergrafik unerlässlich - eine Umwandlung von Fotos beispielsweise macht, wie im Artikel beschrieben, keinen Sinn. PostScripts "Kernkompetenz" aber ist die Vektorgrafik, und zwar um eine Seite in beliebiger Vergrößerung und Auflösung verlustfrei drucken bzw. anzeigen zu können.

Um Missverständnissen gegenüber PostScript als Seitenbeschreibungssprache entgegenzutreten: PostScript behandelt Text tatsächlich als Vektorgrafik. Auch Text gilt als "Pfad", also als eine Folge von Linien und Kurven. Dieser Pfad kann gezeichnet, ausgefüllt oder für Clipping etc. benutzt werden.

PostScript-Code enthält keine "Schriftsatzanweisungen". Will man ein Textdokument in PostScript-Form haben, muss es vorher bereits fertig gesetzt sein. Das den PostScript-Code anzeigende Programm oder der Drucker "setzt" nichts mehr eigenständig. Man muss beispielsweise jede Zeile eines Texabsatzes einzeln auf der Seite positionieren, einen automatischen Zeilenumbruch gibt es standarmäßig nicht. (Bemerkung: Man kann mit Tricks "automatische" Umbrüche und ähnliches erreichen - die dazu erforderlichen Anweisungen sind aber ebenfalls mit in den PostScript-Code zu schreiben und werden dann vom Interpreter ausgeführt.)

Das EPS-Format ist eine Spezialform von PostScript-Code. Sie ist eigentlich nicht zur Seitenbeschreibung da, sondern um als Grafik in ein anderes Dokument eingefügt werden zu können.

Hier ist mal ein Beispiel für eine gültige PostScript-Datei:

0 0 moveto
100 100 lineto
200 0 lineto
closepath
stroke
showpage

Sie zeichnet ein Dreieck. Was anderes als Vektorgrafikbefehle ist in dieser Datei wirklich nicht drin! Reicht mein Sermon hier, um PostScript als Vektorgrafikformat anzuerkennen? PDF baut übrigens soweit ich weiß auf dem Konzept von PostScript auf, nur dass PostScript außerdem eine vollwertige Programmiersprache ist und PDF noch diverse Erweiterung als elektronisches Dokumentenformat besitzt. --Zupftom 01:53, 20. Jan 2006 (CET)

Guter Hinweis, baust du ihn ein? Wahrscheinlich stehen Details bei den entspr. Artikeln (Einbinden von Schriften etc). Anton 17:55, 20. Jan 2006 (CET)

Postscript

Das PostScript ist das wichtigste Standardformat wenn es um Vektorgrafiken geht, vor allem um die Weiterverarbeitung im Druckbereich. Natürlich ist die Unterstützung von Rastergrafik unerlässlich - Fotos sind in der Postscriptdatei als EPS-Datei eingebunden.

PostScript behandelt Text als Vektorgrafik. Auch Text gilt als "Pfad", also als eine Folge von Umrisslinien und -kurven. Diese Pfad werden gezeichnet, ausgefüllt oder für Clipping etc. benutzt.

PostScript-Code enthält direkt keine "Schriftsatzanweisungen". Will man ein Textdokument in PostScript-Form haben, muss der Text mit einem vektorbasierten Texttyp (Adobe PS-Schrift) oder Truetype-Schrift gesetzt werden. Damit können die gegebenen Vektoren der Schrift direkt und verlustfrei in das Postscriptformat übernommen werden. Allerdings greift beim Druck das Programm sinnvollerweise auf eine sehr komplexe, externe Schriftdatei zu, um zu vermeiden, dass auch die Schrift mit all seinen komplexen Attributen in die PS-Datei eingebunden werden muss, welches die Datei unnnötig vergrössern würde.

Das den PostScript-Code für den Bildschirm übersetzende Programm oder der Drucker "setzt" nichts mehr eigenständig, sondern setzt die entsprechenden Vektoranweisungen per RIP - (Raster Image Processing) auf die entsprechende Auflösung um und stellt sie dar (sichtbare Bildschirmpixel oder ausdruckbare Rasterpunkte am Drucker oder Belichter).

Möchte man direkt in der PS-Datei schreiben (Scriptprogrammierung), müsste man jede Zeile eines Textabsatzes einzeln auf der Seite positionieren, einen automatischen Zeilenumbruch gibt es standarmäßig nicht. (Bemerkung: Man kann mit Tricks "automatische" Umbrüche und ähnliches erreichen - die dazu erforderlichen Anweisungen sind aber ebenfalls mit in den PostScript-Code zu schreiben und werden dann vom Interpreter ausgeführt.)

Standardmässig werden aber durch die einzelnen Programme (Grafik, Text, Bild) die einzelnen Dateien mit dem Speichern in eine gültige Postscriptdatei umgewandelt, Schrift und Bildanweisungen sind vorhanden, Schriftdateien (Fonts) und externe Bilder (meistens EPS-Dateien) werden bei der Ausgabe mitverarbeitet.

Das EPS-Format (Embedded Postscript Format) ist eine Spezialform von PostScript-Code. Sie dient sowohl der PS-Seitenbeschreibung und vor allem um eine, in der Datei eingebettete, niedrig aufgelöste Bitmap-Vorschaugrafik in einem digitalen Dokument am Bildschirm sichtbar zu machen. Für die Ausgabe der Originalbilder am Drucker ist diese Vorschaugrafik völlig ohne Bedeutung.

Ein Beispiel für einen gültigen PostScript-Code (ohne Header):

0 0 moveto 100 100 lineto 200 0 lineto closepath stroke showpage

Dieser Code zeichnet ein Dreieck.

--Hubertl 18:10, 7. Mär 2006 (CET)

Bild Vektorgrafik

Datei:Vektorgrafik.png

Ausschnittsvergrößerungen

Das Bild ist Banane, da bei der Rastergrafik die dicke Linie sehr grob gerastert ist, und die anderen sehr fein. Hat mal einer Lust, da ein besseres hochzuladen? --Suricata 15:13, 27. Apr 2006 (CEST)

So müsste es sogar mit Bordmitteln gehen: --Suricata 15:33, 27. Apr 2006 (CEST)

Bei mir wird die Vektorgrafik im Artikel nicht angezeigt. Statt dessen wird nur die Beschreibung ("Vektorgrafik") angezeigt. Weiss jemand wie das kommt? Es hat wohl irgendwie mit der Größe zu tun. Es scheinen alle anderen Größe außer den benutzten (20, 60 und 120px) zu funktionieren. Ich habe jetzt mal als notdürftigen fix die größen jeweils um ein pixel vergrößert. Irgend jemand ne idee? (habs auch mit verschiedenen Browsern auf verschiedenen platformen getestet: Firefox 2.0.0.6 (Linux); Opera 9.21(Win2003); IE 7.0(Win2003))

--Lorenz

Scheint ein temporärer Bug zu sein, guck mal auf WP:FZW. Eine Größenänderung wäre nicht nötig gewesen, ein Neuzeichnen geht auch mit der Purge-Funktion. --Phrood 18:02, 16. Sep. 2007 (CEST)

Vektorgrafik

Im Artikel Grafiksoftware gibt unter Branchensoftware den Bereich: CAD-Software und 3D- Grafik-Software. Meine Frage lautet gehören diese Bereiche eigentlich zur Vektorgrafik? Normalerweise arbeiten, so vermute ich, CAD- Software und 3D-Grafik-Software auf vektorbasis oder nicht? Der Artikel Vektorgrafik lässt auch diese Schlussfolgerung zu! Arbeiten also die meisten oder alle CAD und 3D- Programme mit Vektoren? Kennst sich hier jemand aus? --Mohahaddou 19:31, 25. Nov. 2006 (CET)

Es ist natürlich abhängig von der internen Datenstruktur des jeweiligen 3D-Objekts. Spline-Objekte werden beispielsweise meist aus zwei Profilen gebildet, welche ähnlich wie bei einem Vektorgrafikprogramm gespeichert werden. Lediglich die dritte Dimension kommt bei 3D-Programmen noch hinzu. Auch die allgemeinen Prinzipien eines 3D-Programmes sind vergleichbar mit einem Vektorgrafikprogramm: Alle Objekte sind im Nachhinein veränderbar. --Remi 05:39, 28. Nov. 2006 (CET)

CAD und 3D-Grafik-Software wuerde ich einmal als Spezialfaelle bezeichnen... Beides arbeitet zwas mit Vektoren und ist graphisch, ist aber nicht klassisch das, was man unter Vektorgraphik bezeichnet. CAD ist es dabei noch eher als 3D-Graphikprogramme. Mir fehlt hier aber tatsaechlich eine Sektion Software - denn mit Vektorgraphiken umzugehen; und das dann noch zwischen Plattformen wechselnd, d.h. bei mir bisher meistens Linux (meine normale Arbeitsumgebung) und Windows(-Programme) (weil es fuer einen Vortrag/Publikation vom Abnehmer gefordert dann doch ein Word- oder Powerpointdokument sein muessen) da fiele mir mal ein:

• Inkscape Zeichenprogramm (Linux und Windows, OSS)
• Scribus DTP-Programm (Linux ... Windows?, OSS unter Linux)
• Adobe Illustrator (Windows, ?; kommerziell)
• pstoedit konvertiert zwischen verschiedenen Vektorformaten (Linux und Windows OSS, komerzielle Plugins existieren)
• Sketch, heute Scencil aehnlich Inkscape.
• ps2pdf und pdf2ps Postscript/PDF Konvertierung (gehoeren hier vielleicht nicht unbedingt her)?
• Powerpoint und Word (haben rudimentaere Vektorgraphikfunktionen - Linien, Kreise, etc.)
• Xara Xtreme
• Chemieprogramme
  • Chemdraw
  • BkChem
  • XDrawchem

hm, jetzt sehe ich gerade, es gibt eine Kategorie:Vektorgrafik-Software - in die kommen allerdings nur Programme, die auch fuer einen eigenen Artikel relevant genug sind... hier koennte man allerdings auch Programme aufzaehlen, die nicht relevant fuer einen eigenen Artikel sind, wohl aber fuer die Bearbeitung von Vektorgraphiken... z.B. die hier genannten Konvertierungsprogramme - Konvertierung zwischen den Formaten ist immer noch ein grosses Problem - insbesondere, wenn man die Schrift als Schrift erhalten will. Iridos 06:09, 21. Aug. 2007 (CEST)

Zusammenlegen mit Rastergrafik

Ein Großteil der beiden Artikel Vektorgrafik und Rastergrafik besteht aus der Gegenüberstellung der beiden Formate und gehört daher in beide Artikel. Ich würde die beiden Artikel gerne unter Raster- und Vektorgrafik zusammenführen und denke, dass man da einen lesenswerten Artikel erstellen könnnte. Meinungen? --Suricata 17:55, 18. Okt. 2007 (CEST)

Derartige "Vergleichsartikel" sind nicht üblich und ich rate dringend davon ab. --Phrood 22:57, 19. Okt. 2007 (CEST)

Keine gute Idee. --Stefan Birkner 00:49, 20. Okt. 2007 (CEST)

Zwar a) keine gute Idee, aber b) hatte sie schon jemand und hat sie bereits zusätzlich zu diesen Artikeln umgesetzt (IMO auch keine gute Idee) Wenn man mal unter Computergrafik schaut, sieht man dort einen Unterartikel 2D-Computergrafik, der nichts anderes tut als nocheinmal Vektor- und Rastergraphik vergleichen und du, Suricata hast den auch schon im April bearbeitet...Iridos 02:32, 21. Okt. 2007 (CEST)

Was interessieren mich meine Bearbeitungen von gestern :-) Vielen Dank für den Hinweis! Ich werde die Artikel mal besser gegenseitig verlinken und die Redundanz etwas reduzieren. --Suricata 08:56, 21. Okt. 2007 (CEST)

Bilder

Vektorgrafik	Rastergrafik
Vektorgrafiken lassen sich ohne Qualitätsverlust beliebig skalieren.

Verlustfreie Skalierung ohne Qualitätsverlust einer Vektorgrafik (links) und einer Rastergrafik mit Bildinterpolation (rechts)

Hallo Vierge Marie, Deine Bilder sind zweifellos schöner. Für das Verständnis würde ich jedoch gerne beide Bilder reinsetzen, da bei denm Haltestellenschild die einfachen grafischen Primitive Kreis und Polygon besser erkennbar sind, und die Pixel als Quadrate auch die einfachste Darstellung dafür sind. Die Interpolation ist bereits ein weiterer Verarbeitungsschritt. --Suricata 11:37, 18. Mai 2008 (CEST)

ps: Dein Bild würde übrigens besser ins Lemma Rastergrafik passen. --Suricata 11:44, 18. Mai 2008 (CEST)

Bilder 2

Passt das, was über die Haltestellenbilder gesagt wird, überhaupt mit der MediaWiki-Software zusammen? Ich dachte immer, die macht aus einem SVG ertmal wieder ein PNG, welches dann angezeigt wird. Wird durch die „100px“ in der Bildeinbindung wirklich das SVG größer skaliert und nicht nur das abgeleitete PNG größer angezeigt? --Jarlhelm 13:37, 4. Jan. 2009 (CET)

Speicherverbrauch

@Benutzer:Shaddim: Der Speicherverbrauch ist bei Vektorgrafiken nicht zwangsläufig hoch. Bei SVG ist der Verbrauch im Browser deswegen hoch, weil im Hintergrund immer noch ein DOM steht, auch wenn die Grafik gar nicht per DOM-Scripting dynamisch manipulierbar sein soll, keine Animationen enthält oder ähnliches. Vektorgrafiken in PDF-Dateien etwa sollten zur Darstellung nicht viel Speicher verbrauchen, weil praktisch nur ein Strom von Befehlen abgearbeitet werden muss, der gleich wieder "vergessen" werden kann (also nicht im Speicher behalten werden muss). Daher habe ich die Aussage, dass Vektorgrafiken viel Speicher zur Darstellung benötigen, wieder rausgenommen. So pauschal ist das falsch. --Zupftom (Diskussion) 21:25, 24. Sep. 2012 (CEST) P.S.: War beim Editieren des Artikels nicht eingeloggt

Ok, denke mal das du die tieferen Einsichten hast. Als konkretes Beispiel für SVG und auch Wikipedia bin ich vor kurzem gerade über diese 4MB SVG gestolpert bei dem die Thumbnail generierung fehlschlägt: [1] Error creating thumbnail:(process:12886): GLib-ERROR (recursed) **: /build/buildd/glib2.0-2.24.1/glib/gmem.c:176: failed to allocate 128 bytes aborting... Kurzum, ein Out-of-Memory. Firefox bekommt das SVG direkt nach viel Gewürge auf. gruesse Shaddim (Diskussion) 01:41, 25. Sep. 2012 (CEST)

Könntet ihr mir bitte sagen ob wir hier über den Arbeitsspeicher reden, der benötigt wird um eine Grafik anzuzeigen, wenn ja, hängt es vom der die Grafik darstellenden (Betriebs-)System ab und es lässt sich keine allgemeingültige Aussage treffen; oder reden wir hier von Speicherplatz um die Bildinformationen zu speichern? Für letzteres läst sich aussagen, dass eine Vektorgrafik von winzig bis theoretisch unendlich großsein kann, abhängig von der Komplexität, wohingegen eine Rastergrafik (ohne Komprimierung) eine feste Größe besitzt. --ucc 01:52, 25. Sep. 2012 (CEST)

zumindest ich habe vom arbeitspeicher geredet. Die effektivität der beschreibung einer szene/objekt/etc und damit die dateigrösse ist stark inhaltsabhängig, sehe ich auch so. Die Renderkomplexität (und Speicheraufwand?) sollten jedoch immer grösser beim vektorformat, weil das mit dem "streamen" sicher nicht immer klappt (transparenz überlagerungen, gradienten, interaktion mehrerer objekte), im Gegensatz zum rasterformat. gruss Shaddim (Diskussion) 02:04, 25. Sep. 2012 (CEST)

Ok, reden wir mal nur übers Rendern. Da kann man nicht die allgemeingültige Aussage treffen, das Vektor länger zum berechnen braucht als Raster. Das Beispiel von einem Script, welches auf einem Webserver läuft, dem beschränkte Rechenkapazität und limitierter Speicher zur Verfügung stehen, ist kein Maßstab um eine allgemeingülltige Aussage zu treffen. Ebenso kann man nicht das Beispiel nehmen, bei dem verschiedene Transformationen auf das Bild angewendet werden müssen (z.B. perspektivische Verzerrung, Skallierung), bei dem würde nämlich die Rastergrafik deutlich mehr Rechenoperationen benötigen (es sei den wir haben eine unheimlich komplexe Vektorgrafik). Also, ein Vergleich geht hier nur an konkreten Beispielen. --ucc 02:51, 25. Sep. 2012 (CEST)

Du hast recht. Es lassen sich ziemlich sicher Szenarien finden, in denen eine Vektorgrafik schneller und mit weniger Speicheraufwand gerastert werden kann, z.B. eine sehr große Bildfläche, die nur eine diagonale Linie enthält. Der Text ist also immer noch zu pauschal. Gescheite Belege wären nicht schlecht, sonst schreiben wir hier nur ins Blaue hinein.

Übrigens ist die erwähnte "Vektorgrafik"[2] so ziemlich das unsinnigste Beispiel für eine Vektorisierung überhaupt. Wenn man da mal reinzoomt sieht man, dass alle Pixel der ursprünglichen Grafik einfach in Rechtecke "vektorisiert" wurden. Da ist es nicht verwunderlich, wenn jede Menge Speicher verbraucht wird. --Zupftom (Diskussion) 09:28, 25. Sep. 2012 (CEST)

Sinnvoll oder nicht, bei diesem Beispiel einer Verwednung und einem "nur" 4MB grossen Vektorgraphik fliegt einem der Speicherbedarf um die Ohren, 4MB JPEGs bekommt Wikipedia noch auf. Ist es auch nicht so das beim Rastergrafik rednern, ausser dem Zielbildpuffer, teilweise gar kein extra speicher benötigt wird (oder ein sehr kleiner, fixer)? Und auch bei "simplen" Vektorgrafiken, zB 3 sich überlagernde transparente Objekte, müssen da nicht alle 3 Objekte parallel im Speicher gehalten werden, zusätzlich zum Rasterzielbildspeicher? Oder wird Brute-force von unten nach oben gerendert und damit potentiell viel unnötiges gezeichnet und überschrieben?Denke (kanns aber nicht beweisen), das Vektorgrafiken sehr schnell den Aufwand und Speicherbedarf von Rasterbildern überschreiten, bei denen ja ein fixer, determinsitischer und damit leicht optimierbarer Renderablauf entsteht.

Zu dem Argument mit den Transformationen, das finde ich ist ein ungeeignetes Argument: Transformationen und Filter sind integraler und notwendiger Bestandteil von SVG und vielen anderen Vektorformaten, man kann anders gewisse Dinge nicht erzeugen, ausser so zur Renderzeit. Bei der Rastergrafik kann man es immer vorgelagert bei der Bilderstellung tun. Für Schatten/Farbverläufe, die in einem Rasterformat "leicht" abzubilden sind, braucht man sie einfahc deswegen sollte mans sie als normalen Teil von Vektorgrafiken betrachten. gruesse Shaddim (Diskussion) 10:03, 25. Sep. 2012 (CEST)

Meines Wissens ist es normal, dass von unten nach oben "übermalt" wird - das heißt, man braucht die Objekte nicht im Speicher zu behalten, sondern nur den Rasterpuffer.

Wir müssen natürlich zwischen Vektorgrafik und SVG unterscheiden. Auch wenn SVG Transformationen und Filter unterstützt tun das nicht zwangsläufig alle anderen Vektoranwendungen (z.B. Vektorschriften oder das berüchtigte Windows Metafile). Schatten und Farbverläufe sind für viele klassische Anwendungen von Vektorgrafik überhaupt nicht notwendig. Man denke an Risszeichnungen, Funktionsplots und viele andere Diagrammarten, Lineart, Notengrafik oder Plotteransteuerung. Ich finde, wir sollten das etwas ausgewogener beschreiben und möglichst besser belegen als durch eigenes Erfahrungswissen. --Zupftom (Diskussion) 10:57, 25. Sep. 2012 (CEST)

Gute Belege sind immer zu bevorzugen. Welcher Use-Case den nun ein typischer und natürlciher bei Vektorgrafiken ist und welcher nicht ist diskutable, jedoch sollt eman nicht im zweifelsfalle vom Worst-case, also in diesem Falle dem komplexesten (mit Transformation) ausgehen und nicht dem simplen "Sweet-Spot" für Vektorgrafiken? Vielleicht wäre ein guter Kompromiss, den Unterschied Raster-Vektor des nicht fixen Aufwand zu differenzieren? Vorteil Rastergrafik: fester auflösungsabhängiger Renderaufwand. Nachteil Vektorgrafik: Aufwand (Speicerh, Rechenzeit) vorher unbekannt da nicht nur auflösungs-, sondern auch inhaltsabhängig. gruesse Shaddim (Diskussion) 13:27, 25. Sep. 2012 (CEST)

Das fände ich so ganz vernünftig. --Zupftom (Diskussion) 15:29, 25. Sep. 2012 (CEST)

Nochmal zum Speicherverbrauch: Ich habe mal die extreme Grafik nach PDF konvertiert (unter Beibehaltung der Vektorstruktur) und durch Ghostscript gejagt. Das Maximum der Speichernutzung ist bei einer Ausgabegrafik von 325x436 ca. 14660 KB. Wenn ich Ghostscript mit einer unbeschriebenen Seite dieser Größe "pur" laufen lasse (ohne dass eine Datei gerendert wird), dann kriege ich ein Maximum von ca. 10860 KB. rsvg-view (librsvg ist ja der von Wikipedia genutzte renderer) hingegen braucht für die Anzeige der SVG-Datei ca. 170 MB, also mehr als 15 mal so viel. Für eine leere Datei braucht es gerade mal 12 MB.

Entweder hängt es also an der Technologie (SVG) oder dem Renderer (rsvg). PostScript/Ghostscript spielen hier für die selben Vektoren in einer anderen "Speicherliga". --Zupftom (Diskussion) 14:58, 27. Sep. 2012 (CEST)

danke für die interessante analyse, als zusatzinfo 415,1kB sollte die untere speichergrösse über den 24bit ausgabepuffer für 325x436 sein: overhead 3431.4% ghostscript, 40850% bei rsvg. Habs mal bei dem JPG ursprungsbild (http://commons.wikimedia.org/wiki/File:Silversmith.jpg 610x818) versucht abzuschätzen: 1461,8kB ausgabepufergrösse. Maximaler speicherbedarf irfanview 6460kB. overhead 341.9% (inhaltsunabhängig, schwarzes jpeg genauso), denke wir wuerdne uns nicht zu weit aus dem fenster hängen wenn wir daraus schliessen dass das rendern von vetorgrafiken üblicherweise mehr speicher benötigt. gruesse Shaddim (Diskussion) 16:50, 28. Sep. 2012 (CEST)

So, jetzt teste ich das nochmal richtig methodisch: Ich nutze ein Skript, dass den maximalen Speicherverbrauch *über die Zeit* misst. Ich schaue also nicht, wie viel Speicher der Prozess verbraucht, wenn die Datei bereits geöffnet ist und nichts mehr passiert (vielleicht noch nicht mal mehr ein Puffer für die Grafik vorgehalten wird, wer weiß). Ich nutze überall die Auflösung des Originalbilds: 610x818. Ich mache jeweils drei Durchläufe und nehme die geringste gelieferte Zahl.

     11424 mit gpicview/JPEG (recht speichereffizienter Bildbetrachter): 
     19760 mit eog/JPEG (Standardbildbetrachter für Ubuntu)
    170456 mit rsvg-view/SVG
     12116 mit Ghostscript/PDF
     18700 mit apvlv/PDF
     10624 mit xpdf/PDF (etwas größer als 610x818)
    131236 mit Opera/SVG

In dieser Gruppe ist pxdf tatsächlich die Anwendung mit dem geringsten Speicherverbrauch, und dort wird die Vektor-Version gerendert. Braucht natürlich Zeit bei einer so "komplexen" Grafik, aber nicht viel Speicher. Interessanterweise verbraucht sogar Opera weniger Speicher als rsvg-view, obwohl das ein vollständer Browser ist, der garantiert das DOM vorhält, weil es DOM-Animation und -Skripting erlaubt, während rsvg das eigentlich "vergessen" dürfte.

Damit dürfte ersichtlich sein, dass der Speicherverbrauch nicht unbedingt von Vektor vs. Pixelgrafik abhängt, sondern ganz entscheidend von der konkreten Software. Ich will nicht bestreiten, dass es Bildbetrachter gibt, die noch effizienter sind als die beiden getesteten, aber ich habe gerade keinen zur Hand. --Zupftom (Diskussion) 13:39, 5. Okt. 2012 (CEST)

Computerspiele

Die sogenannten Vektorbildschirme verwendeten das Prinzip, erzeugen jedoch keine Vektorgrafik, sondern Leuchtpunkte auf dem Bildschirm, denn der ist ja gerastert. Insofern führt der Abschnitt etwas in die Irre, zumal sich die damaligen Systeme nicht durchgesetzt haben. --Kulturkritik (Diskussion) 02:53, 25. Sep. 2021 (CEST)

Unterschied zu Drahtgittermodell?

Kann jemand den Unterschied zum Drahtgittermodell erklären? Und gehört so ein Vergleich nicht hier rein?

Auf Elite wird hier ein Unterschied behauptet, der sogar besonders betont wird. Wahrscheinlich ist Drahtgitter grundsätzlich durchsichtig... Mich verwundert, dass Drahtgitter als Begriff HIER aber gar nicht auftaucht. --87.78.55.60 15:55, 30. Okt. 2021 (CEST)

Geschichte

Es fehlt mir ein Abschnitt, dass es geschichtlich gesehen zuerst die Vektorgrafik war, die überall benutzt wurde, weil die Systeme anfangs für Pixelgrafik zu schwach waren. Ein Problem war der Speicherverbrauch, denn die Pixel hätte man alle in eine Art Framebuffer speichern müssen, was damalige Grafikkarten nicht konnten. (Wir Reden von einer Zeit, als 64 Kilobyte viel Speicher waren.) Die ersten Systeme waren daher Vektorgrafiksysteme, denn das Speichern von "Linie von w/x zu y/z" brauchte weniger Speicher als eine lange Liste an Pixeln, alle mit Attributen wie der Farbe. Das Zeichnen selbst war damals weitaus leichter, denn es war das Zeitalter von Analog-Technologie: Monitore waren durchwegs Röhrenmonitore, die ohnehin einen Elektronenstrahl verwendeten (siehe Kathodenstrahlröhrenbildschirm). Diesen zu steuern, um eine Linie zu zeichnen, war mechanisch einfacher als einen Pixel-Grafikbuffer zu verarbeiten. Die ersten Schriften auf dem Bildschirm waren daher auch Vektorschriften. Man findet sie auch oft in sehr alten Filmen wieder. Obwohl umgekehrt für die Zeichenerkennung entwickelt, sahen Schriften auf Vektor-Monitoren häufig so ähnlich aus wie z.B. OCR-A. Ich hätte das zumindest mal irgendwo gelesen. Wenn ich es wiederfinde, baue ich es gerne in den Artikel ein. Außer hier in der Diskussion sagt noch jemand, dass das alles (bitte nicht so ernst nehmen:) Bullshit ist, was ich da zu wissen glaube und behaupte... ‣Andreas•⚖ 18:33, 9. Nov. 2024 (CET)