[PHP/GD] Precisie imagearc

[LED-Maniak]

Helaas valt er weinig te vinden over imagearc betreft wat ik zoek dus ik hoop dat jullie mij kunnen helpen door middel van het toepassen van een trucje oid.

Ik heb een stuk code geschreven dat DXF bestanden kan inlezen waar hij vervolgens een afbeelding van maakt. Op zich gaat dit goed, maar de getallen zijn komma getallen en imagearc accepteert alleen int. Nu heb ik al met round afgerond voordat ik de data in imagearc zet maar bij grote arcs krijg je fouten waardoor de afbeelding niet meer mooi aansluit.

Hier een voorbeeld van een raceauto dxf: http://www.protoart.net/test/ndex.php
De schijnbaar rechte lijnen die je ziet zijn arc die door afronding raar beginnen te doen omdat de radius erg groot is.

Heeft iemand enig idee hoe ik dit kan omzeilen zodat ik toch een goede afbeelding kan maken?

[ Voor 43% gewijzigd door LED-Maniak op 13-07-2010 00:09 ]

[NMe]

Niet round gebruiken maar ofwel ceil, ofwel floor (niet combineren!).

[Leftblank]

Met GD zal je waarschijnlijk weinig meer keus hebben dan zelf de lijn te gaan tekenen, daarmee kun je natuurlijk wat meer precisie mee bereiken.

Het alternatief wat je wel hebt is om voor ImageMagick te gaan, dat is een stuk uitgebreider dan GD en kan - via commandline in ieder geval - prima overweg met floats, het nadeel is natuurlijk wel dat je de boel deels zal moeten herschrijven, en de juiste extensions in PHP aan moet hebben.

[NMe]

Leftblank schreef op maandag 12 juli 2010 @ 23:58:
Met GD zal je waarschijnlijk weinig meer keus hebben dan zelf de lijn te gaan tekenen, daarmee kun je natuurlijk wat meer precisie mee bereiken.

Het probleem is dat zo'n vectorfile kommagetallen opslaat voor punten. Jij denkt als tekenaar dat je puntjes perfect op elkaar aansluiten terwijl feitelijk intern bijvoorbeeld 14.2 als x-coördinaat voor punt a wordt opgeslagen en 14.7 voor punt b. Als je daar round gebruikt wordt punt a's x-coördinaat 14, en punt b's x-coördinaat wordt 15.

[LED-Maniak]

Bij kleine lijnen is de afwijking erg gering en merk je het ook niet. Het probleem ontstaat echter pas bij arcs van >200 radius. Ik zal imagemagick eens proberen, bedankt voor de tip!

* LED-Maniak gaat snel even een ander dxfje zoeken

[NMe]

imagearc maakt overigens altijd een perfecte cirkel. Weet je zeker dat het probleem er niet in zit dat je beter imageellipse kan gebruiken of erger nog: zelf een gebogen-lijn-algoritme implementeren?

[LED-Maniak]

imagearc maakt inderdaad perfecte cirkels. De arcs die echter gemaakt worden zijn dan bijvoorbeeld met een radius van 200~300(met 3 decimalen) en ze lopen dan bijvoorbeeld van 180 tot 200 graden(ook weer met decimalen die worden afgerond). Door het afronden krijg je fouten waardoor eea. niet netjes meer aansluit.

Ik dacht dat imageellipse niet met hoekgraden werkt waardoor die helaas niet bruikbaar is.

[ Voor 31% gewijzigd door LED-Maniak op 13-07-2010 00:39 ]

[LED-Maniak]

Met imagemagick lijkt het helemaal gelukt te zijn. Strakke lijnen en alles klopt precies. Gaaf!

Ik zit alleen nog met het probleem dat een dxf wordt getekend met x=0 links en y=0 onder terwijl imagemagick vanuit x=0 links en y=0 boven tekent.

[pieturp]

LED-Maniak schreef op dinsdag 13 juli 2010 @ 19:45:
Ik zit alleen nog met het probleem dat een dxf wordt getekend met x=0 links en y=0 onder terwijl imagemagick vanuit x=0 links en y=0 boven tekent.

y = height - y ?

[RobIII]

pieturp schreef op dinsdag 13 juli 2010 @ 20:46:
[...]


y = height - y ?

En als je dan slim bent stop je dat in een wrapper functie/class whatever zodat je niet steeds eraan hoeft te denken dat je dit "foefje" moet doen

[frickY]

Vermenigvuldig al je coördinaten met, bijvoorbeeld factor 100. Resize de uiteindelijke afbeelding vervolgens 100x kleiner. Et voila?

[NMe]

frickY schreef op dinsdag 13 juli 2010 @ 22:43:
Vermenigvuldig al je coördinaten met, bijvoorbeeld factor 100. Resize de uiteindelijke afbeelding vervolgens 100x kleiner. Et voila.

Had ook gekund, al zou ik persoonlijk lekker bij ImageMagick blijven. Performt doorgaans beter dan GD en het kan nogal wat meer.

[frickY]

Als je IM tot je beschikking hebt zou ik daar inderdaad liever voor kiezen dan GD.

[ Voor 43% gewijzigd door frickY op 13-07-2010 22:48 ]

[LED-Maniak]

pieturp schreef op dinsdag 13 juli 2010 @ 20:46:
[...]


y = height - y ?

Aan gedacht maar heb het nu aangepakt door de afbeelding gespiegeld te laten tekenen(en dus van 0,0) om hem vervolgens te spiegelen. De afmetingen van de afbeelding passen zit nu ook aan gezien hij bij een andere maximum size de afbeelding groter maakt

frickY schreef op dinsdag 13 juli 2010 @ 22:43:
Vermenigvuldig al je coördinaten met, bijvoorbeeld factor 100. Resize de uiteindelijke afbeelding vervolgens 100x kleiner. Et voila?

Had ik ook aan gedacht maar dan krijg ik afbeeldingen van 10.000 pixels breed en hoog, dat is behoorlijk traag


Het lukt al steeds beter gelukkig. Ik zit alleen nu met het volgende punt dat als ik een negatief coördinaat heb in de dxf deze uiteraard buiten de afbeelding valt. Ik zal dus de hele afbeelding moeten opschuiven en vervolgens het negatieve getal positief moeten maken. Bijvoorbeeld als ik coördinaat -10, -5 heb dat ik de afbeelding 10, 5 opschuif en ik vervolgens die lijn dus op 0,0 kan tekenen. Iemand enig idee of die functie bestaat in imagemagick?

[pieturp]

Ik ga niet al je huiswerk voor je maken, maar eh, waarom zoek je niet eerst het laagste getal (mits onder 0) op en tel je dat vervolgens bij al je getallen op? Waarom zou je dat aan imagemagick willen overlaten?

[LED-Maniak]

Huiswerk? Mijn beroep ligt in het mechanische vlak en dus verre van ICT, dus dat zeker niet .

Had verwacht dat gezien de vele opties die beschikbaar zijn in imagemagick dat er ook wel een optie aanwezig zou zijn om een gecreëerde afbeelding te 'moven'. Blijkbaar niet. De andere reden is dat stel dat ik eerst door alle getallen ga, dan zouden er zo 200~300 arcs in kunnen zitten en aan elk van die arcs moet ik dus gaan rekenen wat zijn minimum is en of dit dus negatief is in x, y.

[B0rf]

Je kunt natuurlijk ook zelf een imagearc methode schrijven. Het is niet zo heel lastig om iets te doen als

PHP:

function myimagearc ( $image , $cx , $cy , $width , $height , $start , $end , $color )
{
   for($i = $start, $i < $end; $i+=0.01)
   {
      imagesetpixel($image, $cx + $width * cos($i), $xy + $height * sin($i), $color);
   }
}

(code niet getest)
door ceil of floor te gebruiken bij de imagesetpixel kun je zelf kiezen hoe en waar afgerond wordt. Op deze manier heb je gewoon floating points waar je ze wil

[ Voor 5% gewijzigd door B0rf op 15-07-2010 00:12 ]

[pieturp]

LED-Maniak schreef op donderdag 15 juli 2010 @ 00:06:
Huiswerk? Mijn beroep ligt in het mechanische vlak en dus verre van ICT, dus dat zeker niet .

Had verwacht dat gezien de vele opties die beschikbaar zijn in imagemagick dat er ook wel een optie aanwezig zou zijn om een gecreëerde afbeelding te 'moven'. Blijkbaar niet. De andere reden is dat stel dat ik eerst door alle getallen ga, dan zouden er zo 200~300 arcs in kunnen zitten en aan elk van die arcs moet ik dus gaan rekenen wat zijn minimum is en of dit dus negatief is in x, y.

Had er ook een smiley bij moeten zetten, geloof ik

Het bepalen of een getal negatief is, is bepaald geen noemenswaardige performance hit hoor. Ook optellen behoort al jaren gelukkig tot de snellere bewerkingen

edit: Ik denk dat het voor jouw toepassing snel genoeg is om eerst ff door die coördinaten te lopen en ze handig aan te leveren voor imagemagick. Denk zelfs dat 't geen noemenswaardig verschil maakt of je eerst de afbeelding maakt en dan 'flipt', of eerst de eerdergenoemde oplossing gebruikt om de coördinaten om te draaien (op de y-as). Theoretisch is imagemagick waarschijnlijk sneller dan PHP hierin, maar ik betwijfel of 't meetbaar is.

[ Voor 21% gewijzigd door pieturp op 15-07-2010 00:20 . Reden: aanvulling ]

[.oisyn]

B0rf schreef op donderdag 15 juli 2010 @ 00:11:
Je kunt natuurlijk ook zelf een imagearc methode schrijven. Het is niet zo heel lastig om iets te doen als

PHP:

function myimagearc ( $image , $cx , $cy , $width , $height , $start , $end , $color )
{
   for($i = $start, $i < $end; $i+=0.01)
   {
      imagesetpixel($image, $cx + $width * cos($i), $xy + $height * sin($i), $color);
   }
}

Als je gaten of jerky lijntjes wilt hebben is dat idd de manier ja.

Beter ga je uit van iets als het midpoint circle algoritme, en teken je alleen die pixels die binnen je arc vallen.

[ Voor 14% gewijzigd door .oisyn op 15-07-2010 02:11 ]

[LED-Maniak]

pieturp schreef op donderdag 15 juli 2010 @ 00:14:
[...]


Had er ook een smiley bij moeten zetten, geloof ik

Het bepalen of een getal negatief is, is bepaald geen noemenswaardige performance hit hoor. Ook optellen behoort al jaren gelukkig tot de snellere bewerkingen

edit: Ik denk dat het voor jouw toepassing snel genoeg is om eerst ff door die coördinaten te lopen en ze handig aan te leveren voor imagemagick. Denk zelfs dat 't geen noemenswaardig verschil maakt of je eerst de afbeelding maakt en dan 'flipt', of eerst de eerdergenoemde oplossing gebruikt om de coördinaten om te draaien (op de y-as). Theoretisch is imagemagick waarschijnlijk sneller dan PHP hierin, maar ik betwijfel of 't meetbaar is.

ah. Juist. Ik ben gewnd om te werken met microprocessoren met een kloksnelheid van 20MHz dus verwerkingssnelheden en belasting van de server is voor mij totaal onbekend en ben daarom ook snel bang dat de belasting te hoog zou kunnen worden

ik zal dan eerst door de code lopen en de x, y van alle arc eerst uitrekenen met cos vanuit het middelpunt, om ze daarna verder te verwerken in de te maken afbeelding. Bedankt iig!