Rasterizing

[Spacerat]

Hallo Community, ich bräuchte mal dringend irgendwelche Tutorials oder Programmcode (vorzugsweise Java) die das Rastern von Vektorgrafiken beinhalten. Ich selbst habe mich zwar schon etwas eindringlicher damit beschäftigt, aber irgendwie funktioniert da etwas noch nicht wirklich (siehe Anhang). Ganz schlimm ist es bei der EVEN-ODD-WINDINGRULE, wo mir jeglicher Ansatz fehlt, wie man beim scannen einer Zeile waagerechte Linien von wechselnden Transitionen unterscheiden kann. Das oberste ist mit NON-ZERO gerastert und funktioniert im Prinzip schon, bis auf das rot markierte. Denke mal nicht, dass es unbedingt daran liegt, dass ich ausgerechnet Fonts (woher bekäme man sonst noch auf die Schnelle gute Testvektoren? ) und diese auch noch ohne Hints rendere.
[EDIT]Ach ja... Apaches Batik stöbere ich bereits nach brauchbarem durch, falls mir jemand diesen Tipp geben wollte...[/EDIT]

 

[Spacerat]

Push...
Hat wirklich niemand 'ne Idee, wo man über dieses Thema Best Practises usw. findet? Die Theorie ist ja durch, nur leider funktioniert das alles nicht so, wie es soll.
Ich dreh' hier echt am Rad...

 

[Marco13]

Verweise auf Dinge wie den Bresenham-Algorithmus ? Wikipedia oder Klassiker wie Computer Graphics: Principles and Practice in C (Addison-Wesley Systems Programming Series): Amazon.de: James D. Foley, Andries VanDam, Steven K. Feiner: Englische Bücher sind vermutlich zu high-level. Ein Link auf sun.java2d.pipe: TextPipe.java oder gleich (irgendwas passendes in der Nähe von) jdk7/jdk7/jdk: src/share/native/sun/java2d/pipe/ShapeSpanIterator.c@00cd9dc3c2b5 sind vermutlich zu low-level. Du suchst irgendwas dazwischen? Hm. Vielleicht weiß da jemand was, aber normalerweise tut man sich ja sowas nicht mehr per Hand an

 

[Spacerat]

"Irgendwas dazwischen" ist gut...
Ich suche 'ne Methode, die erstens überall vorhanden ist, zweitens überall die selben Ergebnisse (eine BitMap) liefert und drittens spline, precision, filled und transform als Parameter animmt.
Per Hand habe ich das nun alles soweit, dass ich die Splines inkl. Precision (minimal "sqrt(2)") 15-fach vergrössere und alle Zwischenpunkte der Splinesegmente berechne (deswegen funktioniert wohl das Outline auch am besten). Was ich nun nicht hinbekomme, sind die ON-OFF-Transitionen und dass obwohl die Fälle dafür offensichtlich sind und meine Auswertungen demnach stimmen müssten. Aber irgendwo hat die Sache einen Haken, auf den ich einfach nicht komme.

 

[Marco13]

Ohne da allzutief drin zu stecken: Sooo offensichtlich ist das alles vielleicht nicht. Das mit den winding rules dort einzubauen stelle ich mir zumindest frickelig vor (und deinem Bild nach IST es das auch ) Sonderfälle wie waagerechte Linien müssen richtig mit den Winding Rules kombiniert werden, und ich denke, dass man da schon bei ziemlich fies-tiefen Fallunterscheidungen rauskommt (offensichtlich sind es erstmal nur 4 Fälle, eben alle Kombinationen von booleans "even" und "horizontal", aber mein Bauchgefühl sagt mir: Das reicht nicht).

Das ganze noch kombiniert mit float bzw. beliebiger Skalierbarkeit macht das ganze dann richtig eklig, weil man schlimmstenfalls an jeder Ecke noch irgendwelche Epsilons (für "beinahe horizontal") einbauen muss. Und das kann wirklich RICHTIG eklig sein, weil man immer aufpassen muss, dass ~"ein epsilon in der einen Richtung nicht den Fall in der anderen Richtung kaputt macht" (analog zu einem Punkt, der wegen eines Epsilons scheinbar sowohl links als auch rechts von einer Linie liegt).

Was mich aber irritiert ist der winzige Fehler bei dem 'q'. Also, wenn alles funktioniert ist's gut. Wenn riesen-Mist rauskommt wie bei den Winding-Rules ist offensichtlich was ganz im Argen. Aber WTF ist an diesem 'q' so dramatisch anders als an dem 'd'? ???:L

if (letter=='q') { 
    mirrorY(); 
    draw('d');
    mirrorY();
}

:joke:

Planlos wie ich bin würde ich mal schauen, ob das (bei anderen Schriftarten) auch bei anderen Buchstaben auftritt, und bei anderen Schriftgrößen, Styles oder Zeichen-Offsets, und mal schauen, ob man aus dem jeweiligen PathIterator dort irgendeine dann irgendeine Gemeinsamkeit bzw. Besonderheit ableiten kann (z.B. dass der Fehler immer am Anfang des Paths auftritt, oder immer nach einem MoveTo oder so...). Aber je nachdem, wie verzweifelt du schon bist, wirst du dieses hilflose Rumgestochere wohl eh schon hinter dir haben

 

[Spacerat]

Dein Bauchgefühl trügt dich nicht...
An dem "q" ist nicht wirklich viel anders als beim "d" aber auch in anderen Schriftarten taucht das Phänomen auf, und zwar meistens an solchen Ecken wie beim "q". Ich kann das in meiner Unwissenheit erst mal nur auf Rundungsfehler (das was da so eklig ist...) abwälzen, die dafür sorgen, dass die letzte OFF-Transition der Rundung, kurz hinter der ersten ON-Transition der Kante auftaucht, statt davor bzw. direkt drauf. Bei der NON-ZERO-RULE kann man da noch tricksen, indem man bis zur letzten ON-Transition rückwärts Zeichnet, sobald man auf zwei OFF-Transitionen hintereinander stösst, was in geschlossenen Outlines eigentlich gar nicht vorkommen kann.
Bei NON-ZERO, kann man sich noch damit behelfen, dass man jeden Punkt zeichnet, der eine Transition enthält und sonst von FIRST_ON bis LAST_OFF. Waagerechte Linien werden auf die Art auch korrekt erkannt. Was bleibt, ist EVEN_ODD... Da hab' ich nicht die geringste Idee.
Im Allgemeinen, wäre es mir ohnehin lieber, wenn ich das Ganze nicht zu Fuss (oder per Hand) machen müsste, aber irgendwie machen mir die diversen JVMs (Dalvik, Oracle) immer mal wieder 'nen Strich durch die Rechnung. Und wie es der Zufall so will, es geht dabei im Prinzip eigentlich doch erst mal um Fonts. Die erwähnten JVMs sind in dieser Beziehung nämlich beide recht fest gefahren was die Verwendung von Schriftarten angeht (TrueType, Type1 und OpenType). Für die meisten Zwecke reicht das ja, aber nicht für "Exoten" wie z.B. CompuGraphics.

 

[Spacerat]

Hier ist nochmal der Versuch, den ich einst mit Java2D und Draw- bzw. Fillshape gemacht habe. Die Anordnung ist analog zum oberen Bild. Unschwer zu erkennen, was mir daran nicht gefällt (rote Markierungen). Das einzige, was da "besser" ist, ist der Part mit der EVEN_ODD Windingrule (Zeile 2). Zeile 1 und 3 habe ich sogar mit meinem SW-Rasterizer schon besser hinbekommen. Leider habe ich auch hier keinen Plan, wie man diese Unregelmässigkeiten in Java2D (oder gar noch ganz woanders, wenn's da genauso aussehen würde) abstellt. Ausserdem rendert Java2D meine Splines (Shapes) noch nicht mal zu Ende.

 

[Marco13]

Um da wirklich konkret weiterhelfen zu können, habe ich mich bisher zu wenig damit beschäftigt. (Ich würde ja sowas sagen wie "Vielleicht hat jemand anderes eine Idee..." aber ... ... ... naja). Worauf das ganze Hinauslaufen soll würde ich mich jetzt aber schon interessieren. Wenn es eine akademische Spielerei ist, passt die Alternative, es mit draw(Shape) zu machen, ja irgendwie nicht dazu...

 

[Spacerat]

So hab' ich mir das vorgestellt...
Herzlichen Dank Marco... die PN-Konversation war doch sehr aufschlussreich.
Ich habe mich tatsächlich verhauen und zwar habe ich schlicht einen Stützpunkt mit 'nem Endpunkt eines Segments vertauscht. Da sucht man die Fehler natürlich immer als letztes, weil man in so einem Fall eher kompletten Kaudawelsch erwartet, statt ein minimal verfälschtes Ergebnis. Ich denke, ich kann mich nun ruhigen Gewissens davon entfernen, den Kram zu Fuss machen zu wollen (ein Glück).