File talk:Welterbe.svg

pfad

Moved from User talk:Sarang#pfad

hi, ich hab mir File:Welterbe.svg angesehen und habe fragen zum pfad darin - abgesehen davon, dass er komplett kombiniert ist und in einem 'switch' gekapselt ist - wie kann der pfad so einfach sein? ich meine, ist er tatsächlich so 'ungenau' wie seine kommastellen? ich frage mich nur oft, obs kniffe gibt, die ich nicht kenne - wenn ich mit scour optimiere und die kommastellen auf weniger als 4 kürze, sehe ich deutliche unterschiede zum orginal - kannst du dazu was sagen? also auch konkret auf die datei bezugnehmend? danke und gruß --Mrmw (talk) 15:50, 17 June 2020 (UTC)

Das Symbol im Logo ist recht einfach und kann mit einem eher trivialen Pfad gezeichnet werden: der uberwiegende Teil des Pfadcodings betrifft den Text. Unser renderer kann immer noch nicht Text in Kurven darstellen. Der switch ist Unsinn. Und 160×160 mit Kommas darzustellen ist auch Unsinn. Die Datei enthalt uberhaupt keine Kniffe, nur viel Pfad-Text. Das Wegkurzen von Kommastellen kann bei relativen Koordinaten die Ungenauigkeit vervielfachen (wenn ofter in die gleiche Richtung auf/abgerundet wird) , das ist dann irgendwann zu sehen. -- sarang♥사랑 06:28, 18 June 2020 (UTC)

Das Bild hat eine Auflösung von ca 160x160 die (relativen) Koordinaten werden auf 0.1 genau angegeben, also reden wir hier doch von 4 Kommastellen (PS. ich kann Pfaddaten nicht lesen, insofern kann ich mich hier irren). Die Großbuchstaben sind sehr simpel, da kann man sogar mit scour --set-precision=2 --set-c-precision=1 optimieren. Wenn du mit dem Original (Feb. 2012) anfängst, hast du viele getrennte Pfaddaten, ich glaube mit relativen Koordinaten kann man das vl. besser optimieren, dazu sollte man die Pfade zuerst zusammenfügen (das ist ewas das scour nicht kann).

Beachte https://www.dropbox.com/s/pfsqxfay2si8vkr/Screenshot%202020-06-18%2010.54.32.png?dl=0 hier siehst du einzelne Punkte wurden entfernt, einige Tangenten wurden entfernt, das ist etwas was scour mWn nicht macht.

@Mrmw: Hast du auch bei der Datei Probleme wenn du mit scour auf 3 signifikate Kommastellen rundest?

 — Johannes Kalliauer - Talk | Contributions 09:01, 18 June 2020 (UTC)

@JoKalliauer: hmmm ja, verzeiht wenn ich hier keine klaren frage stelle - wenn ich nun dieses svg nehme und so wie es ist optimiert speichere mit scour bekomme ich keine probleme wenn ich auf drei kommastellen reduziere, weil das orginal ja auf ca. 2 kommastellen genau ist

ich bin nur immer irritiert wenn ich svgs sehe die mit 2 kommastellen funktionieren und ich gewöhnlich mit 5 arbeite - deshalb war die frage, ob bei diesem svg lediglich großzügig optimiert wurde und das svg nun dementsprechend grob ist, oder ob beim zeichnen/coden schon eine methode angewandt wird um sich auf dem optimum zu bewegen

in inkscape gibts die erweiterung pixelschnapp - aber damit komm ich auch nicht klar, bzw. konnte keine erfolge verbuchen --Mrmw (talk) 16:51, 18 June 2020 (UTC)

Kommastellen: Manche tools verwenden Kommastellen exzessiv wo sie vollkommen unnotig sind. Bei vielen einfachen Grafiken, zB bei Diagrammen, ist keine besondere Genauigkeit erforderlich, einige Pixel spielen da keine Rolle. Dennoch wird da gelegentlich eine "Prazision" von vielen Nachkommastellen getrieben, die nie und nimmer sichtbar ist - auch nicht bei starkstem Zoomen! Ich sah schon 15 (!) Kommastellen. ::Die Datei Flag of Cuba.svg ist sehr einfach: ein paar Streifen, ein rotes Dreieck und ein weisses Pentagramm. Ich habe dieses sehr exakt mit einer Kommastelle gezeichnet (3. Mai 2017). Es existiert eine Version (3. Januar 2005) die das Pentagramm mit 42 Kommastellen zeichnet ! Ich finde, es lohnt sich, immer darauf zu achten, welche Genauigkeit denn wirklich sinnvoll ist. -- sarang♥사랑 17:29, 18 June 2020 (UTC)

@Mrmw: Wenn du wissen willst wie du es optimiert hättest, nimm die alte version von Feb.2012, dort gibt es Koordinaten wie 155.037 die man noch optimieren kann

Wenn du nach einem Inkscape-Feature suchst, würde ich eher Pfade vereinfachen (Strg & L) wählen.

Grundsätzlich gilt je gößer der Abstand zwischen zwei Kontrollpunkten ist, desto größer kann auch die Rundung passieren, daher kann man weniger Kontrollpunkte oft besser vereinfachen als viele.

Sarang ist sehr gut in Text-editorzeichnen, ich bin eher der der numerisch optimiert, ich habe schon viele unterschiedliche Dateien optimiert/gebugfixed und kann dir auch Dateien nennen die hohe Genauigkeiten brauchen, siehe User:JoKalliauer/Optimization#Precision/benchmark_files

Insbesondere SVGs die Pfaddaten mit transform (wie File:2008_South_Ossetia_war_ru.svg oder File_talk:MichelinStar.svg#Original_version_without_image) erfordern eine hohe Genauigkeit (--set-c-precision=6 --set-precision=6).

Generell würde ich sagen, die maximale erforderliche Genauigkeit ist 1-2pixel, wenn man das Bild Vollbildmodus offen hat (1000-2000Pixel), also man darf einen Fehler von 1‰ machen, bei einem Bild mit einer Auflösung von 160px darf man einen Fehler von 0,16px machen, die Genauigkeit der Datei liegt bei 0,1px, also genauer als gefordert, also nach der 4signifikaten Stelle, also irrelevant.

Es kommt idR nicht auf die Kommastellen drauf an, sondern auf die Anzahl der de:Signifikante Stellen.

 — Johannes Kalliauer - Talk | Contributions 18:15, 18 June 2020 (UTC)

@Mrmw: Ich will die Sache mit der Genauigkeit nochmal an einem konkreten Beispiel verdeutlichen:

Die BSicons sind generell 500×500 gezeichnet, und werden 20×20 angezeigt. Da bringt eine übertriebene Genauigkeit keinen Vorteil, weil sie ganz einfach nicht zu sehen ist. ZB in BSicon uFGATEd.svg:  erfordert eine genaue Darstellung der Punkte des weissen Innenteils rationale Zahlen – doch ist bei dieser Verwendung eine Ungenauigkeit von ein oder zwei px nie und nimmer zu sehen! Wenn nicht ein sportlicher Ehrgeiz Präzision bis in die x-te Kommastelle verlangt, ist hier eher ein sportlicher Ehrgeiz sinnvoll, kompakten Code (ggf. mit tolerierbarer Ungenauigkeit) zu erstellen. -- sarang♥사랑 11:17, 25 June 2020 (UTC)