PHP ellipses

Joe

New member
Joined
Mar 27, 2011
Messages
11
Hi! I'm writing a PHP program to take advantage of .png image formats that allow alpha transparency. It is supposed to create ellipses, but I get di-polar creations instead. The problem code section is below, and "should" be basically readable to a mathematician. It creates circles just fine, but as the height/width ratio deviation from 1.0 increases (the more you squish the circle into an ellipse) the more the separation. Interestingly, at a h/w ratio of 2(pi) (approx=6.28) [or 1/6.28 squishes the ellipse top-to-bottom] you just about get 2 tangent circles. I'd post a link to a nearly-complete working demo and all the source code if it was appropriate (just say so). I'll be releasing the entire thing under an open-software license.

Remember, angles are in radians...
anything after // is a comment (until the end of line, but line may wrap on narrow screens)

Code:
 for ($row=$wrkMargin['top']; $row<$height; $row++)  {   //loop through every row (y co-ordinate of pixel) ...
    for ($column=$wrkMargin['left']; $column<$width; $column++)  {  //loop through every column (x co-ordinate of pixel) ...
      if ($hwRatio!=1)  {  
        // if not a circle, then calculate the length of the ray from the ellipse center through the pixel to the edge of the ellipse
        if ($column==$center['x'])  $angle=M_PI_2;  //  angle=PI/2; remember division by 0 is undefined.
        else  $angle=atan( abs($center['y']-$row) / abs($center['x']-$column) );   // abs is absolute value
        $radius=sqrt( pow($Xradius*cos($angle), 2) + pow($Yradius*sin($angle), 2) );  // here "pow" squares the values
        $ellipseFactor=$majorSemiAxis/$radius;  }
      $offCenter=sqrt( pow($center['x']-$column, 2) + pow($center['y']-$row, 2) );  // how far is the pixel from the center?
      //  if the pixel is outside the boundaries of the circle or ellipse, either reflect the colors, or ignore the pixel (user choice)
      if ($¿reflect)  while ($offCenter>$radius)  {$offCenter=abs($radius-($offCenter-$radius));}
      else if (round($offCenter)>$radius)  continue;  //continue with next pixel -ignore this one
      $offCenter=round($offCenter*$ellipseFactor)
      imagealphablending($rainbowBall, $rainbow[$offCenter]['alphablend']);  // set blend mode
      imagesetpixel($rainbowBall, $column, $row, $rainbow[$offCenter]['clrAllocate']);  // set the pixel to the appropriate color
      }
   }

I've created another test feature. This creates an ellipse outline in white, then in the (+,+) quadrant (angle<2(PI)) it resets the pixels to red AFTER it recalculates the pixel position using the same logic as the first program... It also graphs the angle and the radius...
Code:
  //loop through all angles from 0 to 2 times PI (approx 6.28...) at a rate of .01 radians
  for ($angle=0; $angle<M_PI*2;  $angle=$angle+.01)  {
    $x=cos($angle)*200;
    $y=sin($angle)*300;
    if ($angle==0)  imageellipse($image, 400+$x, 400-$y, 7,7, $red);  //show start point of first quadrant
    if ($angle-.01<M_PI_2  and  $angle+.01>M_PI_2)  imageellipse($image, 400+$x, 400-$y, 7,7, $cyan);  //show end of quad.
    imagesetpixel($image, 400+$x, 400-$y, $white);
      if ($angle<M_PI_2)  {  //  if in the first quadrant, 'backwards calculate' 
        if ($x==0)  $beta=M_PI_2;
        else  $beta=atan($y/$x);  //  in this quadrant x and y are positive and less than 400, no need for abs
        $xb=200*cos($beta);  $yb=300*sin($beta);
        $radius=sqrt( pow($xb, 2) + pow($yb, 2) );
        $ellipseFactor=300/$radius;
         imagesetpixel($image, 400+$xb, 400-$yb, $red);  //here we reset the white pixel to red - in this quadrant
        imagesetpixel($image, 400+$count, 400-$beta*150, $cyan);  //graph the angle's value
        imagesetpixel($image, 400+$count, 400-$radius, $purple);  // graph the radius' value
        imagesetpixel($image, 400+$count, 400-($ellipseFactor*300), $white);
        imagesetpixel($image, 400+$count++, 400-($ellipseFactor*$radius), $yellow);
      }
  }

as shown, I calculate the angle in the first program as the arctangent of the rise over run, with rise and run being calculated from the center of the ellipse, and it doesn't work. Yet the overall process DOES in the example in the second program! The graph of the angle and the radius values show them to rise, not cycle, in this quadrant.

This has been straining my brain for over a week. I took trig in college, but that was 20 years ago... From every identity I can find, my approach is correct, or so I THOUGHT. Obviously NOT. PLEASE tell me what gives before my brain melts away from overheating... :?

tangent(angle) = rise/run = opposite/adjacent
arctangent( tangent(angle) ) = angle
 
1) Are you SURE horizontal pixels measurement is the same as vertical pixel measurement?
2) Why on Earth would you not use a vector-based drawing tool?
 
1) Are you SURE horizontal pixels measurement is the same as vertical pixel measurement?

More or less, YES. In any case, it should not matter, the overall picture would be stretched if pixels were not square. But I'm not even getting a true ellipse, stretched or not. I'm getting two 'intersecting' circles. see:

newRainbow.png


here is the output from the second program, showing all is well....
(I changed it slightly so it graphs details in the upper-right quadrant (+,+), as most are used to)

testellipse.png



2) Why on Earth would you not use a vector-based drawing tool?

The one I have is a very popular one for Windows, and it is very limited in it's ability to create color gradients. I wanted a background for a sunrise, going from yellow in the center to deep orange to deep violet to deep blue at the edge. My expensive drawing tool could not do this. It only allowed me to choose the start and end colors, and it creates the rainbow of colors in between 'automatically'. When I brought the problem to a real graphic artist, they tried using the 'most popular' graphics vector-based tool (you know the one) and it failed also. Both kept introducing hot pink between the orange and violet. I wrote this to make the circular gradient I needed. But now I want to do ellipses also...
I just think it's fun... until you pull your hair out over what seems to be correct! Why the technique works in the second program but not the first?
Another reason is that transparency gradients are not in any way supported with my vector-based software. Maybe that $500 software that is the most popular can do this, but I don't have $500 to find out.
Another reason is that vector based drawing tools do not interface with programming languages very well. I develop software for websites (not the graphics on a pro level, but I'm just playing around here) and it would be nice to be able to create a custom graphic as needed on-the-fly with the desired color and transparency gradients to the size needed. It's a technique used in "Ajax" website programming, where JavaScript reads the window size of the user, sends that info back to the server, then graphics are created to fit that individual window size. But I'm not actually working on any project that needs that ability. Mostly I just think it's fun to tinker around. And I wanted to brush up on my trig. Next I have some ideas using a parabolic formula...

I'll try posting a link to the complete code and working demo, if it's allowed
 
A couple of thought questions...Just making sure I am seeing your intent.

$angle=atan( abs($center['y']-$row) / abs($center['x']-$column) );
This assumes symmetry across both x- and y- axes and across the Origin.

$radius=sqrt( pow($Xradius*cos($angle), 2) + pow($Yradius*sin($angle), 2) )
This, and the previous, assumes $angle is in Radians. I'm tempted to run the code and check.

$radius=sqrt( pow($Xradius*cos($angle), 2) + pow($Yradius*sin($angle), 2) );
$offCenter=sqrt( pow($center['x']-$column, 2) + pow($center['y']-$row, 2) )
You could save a few miliseconds be making comparison calculations without the square roots.

$majorSemiAxis
What is this? I don't see where it is defined.

{$offCenter=abs($radius-($offCenter-$radius))
What's the intent of this?
 
tkhunny said:
A couple of thought questions...Just making sure I am seeing your intent.

$angle=atan( abs($center['y']-$row) / abs($center['x']-$column) );
This assumes symmetry across both x- and y- axes and across the Origin.

Hmmm... An ellipse is symmetrical across both axes, but I suppose not across the Origin. But a Circle is.
My intention is to find the angle of the ray (or ray segment as it ends up being used) from the center of the ellipse through any given point [pixel] (each point [point] is given in succession).
Then, given that ray on that angle, find the distance from the center to the edge of the ellipse, which I then call "radius" (see the next line just below here).

[quote:2bquxbtb]$radius=sqrt( pow($Xradius*cos($angle), 2) + pow($Yradius*sin($angle), 2) )
This, and the previous, assumes $angle is in Radians. I'm tempted to run the code and check.

Yes, angles are in radians.

$radius=sqrt( pow($Xradius*cos($angle), 2) + pow($Yradius*sin($angle), 2) );
$offCenter=sqrt( pow($center['x']-$column, 2) + pow($center['y']-$row, 2) )
You could save a few miliseconds be making comparison calculations without the square roots.

Good point. But I eventually need the $offCenter value as a distance from the center to the pixel in question. See below.

$majorSemiAxis
What is this? I don't see where it is defined.

It's defined earlier. $Xradius and $Yradius and $center['x'] and $center['y'] are also. They are real time values, and I have verified their values to be correct.
The $majorSemiAxis is the longer of the two. In this case it represents the total number of colors that the user has defined to make this "rainbow". The colors should emminate from the center to the edge of the ellipse. At the $majorSemiAxis, every color is used. On the $minorSemiAxis, there are less pixels than colors defined, but the edge of the ellipse should be the same all the way around. That's where $ellipseFactor comes into play. For circles, $ellipseFactor is defined earlier as 1.0.


{$offCenter=abs($radius-($offCenter-$radius))
What's the intent of this?[/quote:2bquxbtb]

This "reflects" the user's defined colors back at the edge of the ellipse (or circle). Let's look at a circle, for simplicity.

If the user has defined 200 colors, the $radius will be 199, and the diameter of the circle will be 199*2+1=399. The center pixel will be $rainbow[0], and the pixels on the edge of the circle will be $rainbow[199].

If there is a margin given, or since a .png image is square, not round, there will be pixels that lie outside the edge of the circle (or ellipse, if that's the case).

To "reflect" the colors means like in a mirror. So if the pixel in question is, say 234 pixels away from the center of the circle, calculated using the Pythagorean theorem, we wan to know how far from the edge is it, and choose the appropriate color. If the pixel INSIDE the circle just before the edge is $rainbow[198], then the pixel just OUTSIDE the circle will be $rainbow[198]. For our pixel in question above, 199-(234-199)=164. So we set the color of that pixel in question to $rainbow[164].
This is set inside a loop for when the margins are a much larger percentage of the radius. If your pixel in question is 900 pixels away from the center, then 199-(900-199)=(-502) = |502|. Since there is no $rainbow[502], it feeds back into the loop, and we get 199-(502-199)=(-104) = |104|. So we color the pixel $rainbow[104]. This compound reflectiveness acts as if there were two mirrors, one encircling the circle/ellipse, and one "super magical" one the size of a point at the center. If you look at the demo graphic, you can see the reflection effect. This was a small graphic with 150 or 200 pixels of margin given. If only it was an ellipse...{crying...}
You know, I've been programming for 25 years, and beaten my head against the wall many times, but usually probing the data throughput leads to answers. But here, I'm getting no where.... This is the first time I've ever broken down and asked for help. How does that song go??? "I was so much older then; I'm younger than that now."

I'm thinking of more test programs, which I hope to write tonight...
I need to limit the data throughput somewhat.
But I still don't see HOW I get an COULD ellipse in the second program, and not the first???
 
Joe

I have no hard information on what is wrong with your program. I do have an intuition about it (and intuitions may be useless). The simple definition of an ellipse is based on two foci, not a single center (although perhaps you could create a definition based on a center). Another way of saying the same thing is that the circle is the special case of an ellipse where the foci are coincident. It appears that as you alter the parameters your program is trying to create a circle with two centers. That would be consistent with your saying that you are getting something that looks like two circles that are tangent at certain values of the paramters. It is also consistent with one of your screen shots.

I apologize if this idea is a blind alley.
 
JeffM said:
Joe

I have no hard information on what is wrong with your program. I do have an intuition about it (and intuitions may be useless). The simple definition of an ellipse is based on two foci, not a single center (although perhaps you could create a definition based on a center). Another way of saying the same thing is that the circle is the special case of an ellipse where the foci are coincident. It appears that as you alter the parameters your program is trying to create a circle with two centers. That would be consistent with your saying that you are getting something that looks like two circles that are tangent at certain values of the paramters. It is also consistent with one of your screen shots.

I apologize if this idea is a blind alley.

I'm not sure if I follow you, but I would "intuitively" reply:

If you can create an ellipse using sin and cos by cycling an angle (from 0 to 2PI radians), is not the center implied in the formula? The second program does this and does not use any foci.

Or am I not following you? I don't recall studying ellipses in trig class. I came up with all this based on what I found in Wikipedia and a few other sites. I waded though formulas and identities that I don't pretend to fully understand until I came up with this function. Using Xradius*cos(angle) and Yradius*sin(angle) and the Pythagorean theorem makes sense to me based on what I DO understand about triangles and trig. But I had to work to find out HOW to find the angle - using arctangent.
 
Symmetry across the Origin is fine if the ellipse is ALWAYS oriented along the x-axis or y-axis. (major and minor axis parallel to the coordinate axes) Any other rotation is no good.

I have to agree with JeffM. There's something funny with xradius and yradius. I haven't had time to look at it. Maybe you'll beat me to it.
 
Joe said:
JeffM said:
Joe

I have no hard information on what is wrong with your program. I do have an intuition about it (and intuitions may be useless). The simple definition of an ellipse is based on two foci, not a single center (although perhaps you could create a definition based on a center). Another way of saying the same thing is that the circle is the special case of an ellipse where the foci are coincident. It appears that as you alter the parameters your program is trying to create a circle with two centers. That would be consistent with your saying that you are getting something that looks like two circles that are tangent at certain values of the paramters. It is also consistent with one of your screen shots.

I apologize if this idea is a blind alley.

I'm not sure if I follow you, but I would "intuitively" reply:

If you can create an ellipse using sin and cos by cycling an angle (from 0 to 2PI radians), is not the center implied in the formula? The second program does this and does not use any foci.

Or am I not following you? I don't recall studying ellipses in trig class. I came up with all this based on what I found in Wikipedia and a few other sites. I waded though formulas and identities that I don't pretend to fully understand until I came up with this function. Using Xradius*cos(angle) and Yradius*sin(angle) and the Pythagorean theorem makes sense to me based on what I DO understand about triangles and trig. But I had to work to find out HOW to find the angle - using arctangent.

I have not done coding in 30 years so I am not going to try to analyze your code. But when I was coding and a program did something that it ought not, I always used to ask myself what was it trying to do. And it looks as though the program is jumping between foci for SOME reason. If you look again at the wikipedia article on trigonometric representations of ellipses, you will see that most do use the ellipse's center so that cannot be the problem. But you will also see that one trignometric formula applies when the center is at the origin and the MAJOR axis lies on the x-axis. Presumably the formula will not work if the major axis lies on the y-axis. You will also see another trigometric formula with a plus/minus sign in it. All of this suggests to me that the trig formulas implicitly take into account the dual foci of the ellipse and that somehow your program is applying the formulas in a way that neglects the duality of the ellipse.

This is a hand-waving sort of argument, and I apologize again if it leads you astray, but debugging a program is more art than science anyway.
 
Make this change and see what it does:

$offCenter = abs($radius-($offCenter-$radius));

$offCenter = $radius * ($radius/$offCenter);

The top one looks like a linear adjustment which will distort the non-linear object. It should also cure the looping problem.
 
I have not done coding in 30 years so I am not going to try to analyze your code. But when I was coding and a program did something that it ought not, I always used to ask myself what was it trying to do. And it looks as though the program is jumping between foci for SOME reason. If you look again at the wikipedia article on trigonometric representations of ellipses, you will see that most do use the ellipse's center so that cannot be the problem. But you will also see that one trignometric formula applies when the center is at the origin and the MAJOR axis lies on the x-axis. Presumably the formula will not work if the major axis lies on the y-axis. You will also see another trigometric formula with a plus/minus sign in it. All of this suggests to me that the trig formulas implicitly take into account the dual foci of the ellipse and that somehow your program is applying the formulas in a way that neglects the duality of the ellipse.

Well, again I say my ellipse formula does not utilize foci. The second program generates an ellipse. This is indisputable, as the second image shows. It calculates the edge of the ellipse the same way - by finding the angle of a pixel from the x-axis with the fulcrum at the origin using atan (arctangent).

When I look at the first image, -I- see the angle being calculated is correct ONLY on the axes. From the x-axis it rushes faster than it should up to a point, then slows back down until it reaches equilibrium at the y-axis again. I.E, if the point lies on say 15 degrees, the atan function might be returning say 17 degrees (except in radians...yes I get the difference, but for sake of this discussion, degrees are more easily understood); if the point is on 25 degrees, the atan function returns 30; if the point is at 35 degrees, we get 44 degrees instead, etc... But at 60 degrees we get maybe 65 because we slow back down, until at 90 degrees we get 90. This would cause the radius to be larger than it should toward the middle of the arc (between the two axes) and bulge the ellipse outward.

When I look at the actual numerical data produced (I put a variable dump to screen in the loop) the angles never do actually match, due to internal round-off errors in atan and in the division of y/x. I'm using 10-digit precision, I think. Maybe 8, but I think 10. This was my first intuition, so I wrote the test program to see what happens. If my theory is correct, I would predict a concentration of red dots closer to the center of the arc of that quadrant in the second image; but from what I see, they are fairly evenly spaced and not thinned out at the ends of the arc of that quadrant.

When I create a "rainbow" graphic using this first program, I'm sure of the values of the x and y axis, and they come out correct. All the colors are proportioned correctly along the minorSemiAxis, and the edge of the ellipse is calculated correctly. On the majorSemiAxis, all the colors are there, and again the edge is again calculated correctly. It's in-between that is not correct.

Make this change and see what it does:

$offCenter = abs($radius-($offCenter-$radius));

$offCenter = $radius * ($radius/$offCenter);

The top one looks like a linear adjustment which will distort the non-linear object. It should also cure the looping problem.
I'm not sure you understand... There is no looping problem. It is SUPPOSED to loop. It IS a linear adjustment because we apply color to a given RAY (from the centerpoint outward) one pixel at a time. And we don't do one ray, then the next, we do one pixel, then the next, finding the ray that it sits on in the process...
Try reading my last post again.
 
Joe

I won't bother you again. I know you are basing your work off the center and that there are trig formulas that warrant that technique. But when I look at the trig formulas, it is quite obvious that at least some of them implicitly adjust for the fact that an ellipse has two foci. For example, one formula explicitly says that it works if the major axis is the x-axis. That strongly suggests that it does not work if the major axis is the y-axis. All I was doing was to suggest that you check that the formula you are applying does indeed work across your entire range of angles.

Sorry to have annoyed you.

Jeff
 
On NO! Sorry if I came off annoyed. Yes, I'm frustrated, but not with you. I know you're trying to help; I'm trying to explain it all in my terms why I think you're not following the process. And spelling it all out helps me understand it better, and may help me solve the problem in the short or long run. That's what group discussion is all about, methinks.

Anyway, look at this:

newRainbow2.png


This one was given 3 colors for the rainbow: black, chartreuse, and blue. The background color given was crimson.
The height/width ratio is 3:1. The margins given are 20 pixels.
Note hot the x- and y- axes have perfect color representation and radius calculated. Between the two the calculated radius is always greater than it should be.
And reflect was OFF. Therefore, $offCenter = abs($radius-($offCenter-$radius)); never came into play at all. Instead, if the pixel was found to be outside the "ellipse", it was skipped. Yet the shape is the same. Without reflect, the pixels outside the rectangular area that surrounds the ellipse are not even in play, so they are not colored at all and the graphic looks clipped.

If your wheels are startin' to spin eccentrically, here's a nice big piece of fat to chew on:

The whole Rainbow PHP class I've wrote so far:
http://owl-eye.org/Rainbow.htm

You can see it highlighted in color.
Comments are in orange. Variables are in blue, preceded by a yellow $

Sorry, don't have time to elaborate much on it, and it's not yet well commented.

The Public Function Block takes the user's list of colors and the other associated info, and creates gradients: i.e. a longer list of colors. For each color given (except the first) there must be an associated 'overspan' value, which is the number of pixels between the color and the last. Each gradient color in succession is slightly motivated in tone from one user-defined-color to the next. Or perhaps not so slightly if "overspan" is just a few pixels. It also creates a "rainbow block" graphic if the last variable passed in is left to default (FALSE).

The Public Function Disk takes the rainbow gradient raw data from "Block" (by passing TRUE as the last variable, instead of allowing the default) and creates circles and hopefully some day ellipses.

You really need to understand PHP to read all this, but I thought I'd post it for the interested anyway. Note how it uses sin to "curve" the color gradient either toward the the start or end color, should the user desire. Or the user may choose a linear gradient. Eventually I'll add a "curve factor" to alter the curve even more, but time, time...

And I have dreams of a floating centerpoint, while the edge of the ellipse/circle remains stable. Don't have a clue yet on that one, especially as the centerpoint floats outside the boundaries of the ellipse. Get that? I'm still trying to fully envision it, let alone understand the trig behind it...

And there's more plans in the works...

In the mean time, I'll try to get a working demo up and running where you can't blow up my host's computer with giant rainbows.....
 
Joe said:
On NO! Sorry if I came off annoyed. Yes, I'm frustrated, but not with you. OK No problem. I understand intellectual frustration
I know you're trying to help; I'm trying to explain it all in my terms why I think you're not following the process. And spelling it all out helps me understand it better, and may help me solve the problem in the short or long run. That too I understand. Your best chance of seeing where things are going astray is to re-articulate the process to yourself.

That's what group discussion is all about, methinks. I am bringing very little to the group here. I have not written any code in the last 30 years, and I was seriously writing code back in the 60s with machines that seem laughably primitive today and with languages that long preceded C. Nor am I a mathmetician. But I do do what you do in this sense: I try to apply what I remember from long-ago math to problems that I have posed to myself.

Just looking at the screen shots, it is obvious that UNDER SOME CIRCUMSTANCES whatever formula you are using for the ray length is seriously in error. (I know that one program is generating acceptable results, but the other is not.) One thing that would be helpful would be for you to specify in math notation the exact formula from Wikipedia that you are basing your program on. That is: what is your formula for the length of the ray. I keep wondering if there is some restriction on the formula that we are forgetting, and it is hard to do that if I am not certain which of quite a few possible formulas you selected.

I also wonder why, if your program invariably generates outlines that are ellipses or close enough to ellipses in one quadrant, an alternative solution is not to calculate in just that quadrant and use symmetry for the other quadrants. (The answer to that may be that ultimately you want to distort the ellipse in ways that are not symmetric).

Finally, I wonder why you do not use the trammel method that the Wikipedia article specifies to generate the outline of the ellipse. That should be very easy to program, bases the program on the center of the ellipse as is apparently important, and involves parameters based on lengths rather than angles. (Again, this may be inconsistent with your future plans, and it may be inefficient computationally.) Asking the user of your routine to center the ellipse and specify the maximum horizontal and vertical widths would certainly lead to a simple user interface.
 
JeffM said:
Just looking at the screen shots, it is obvious that UNDER SOME CIRCUMSTANCES whatever formula you are using for the ray length is seriously in error. (I know that one program is generating acceptable results, but the other is not.) One thing that would be helpful would be for you to specify in math notation the exact formula from Wikipedia that you are basing your program on. That is: what is your formula for the length of the ray. I keep wondering if there is some restriction on the formula that we are forgetting, and it is hard to do that if I am not certain which of quite a few possible formulas you selected.

The length of the ray segment which is the radius in question is calculated using the Pythagorean Theorem.
a[sup:3gq4at6s]2[/sup:3gq4at6s]+b[sup:3gq4at6s]2[/sup:3gq4at6s]=c[sup:3gq4at6s]2[/sup:3gq4at6s]
or
c=sqrt( a[sup:3gq4at6s]2[/sup:3gq4at6s]+b[sup:3gq4at6s]2[/sup:3gq4at6s] )

The values of a and b - the sides of the triangle - are found using the sin and cos of the angle of the ray segment as applied in the formula for ellipses (either horizontally oriented, or vertically oriented, not in between):
given an angle (0 to 2PI radians) (0 to 360 degrees)
given the known radius on the x-axis (Xradius)
given the known radius on the y-axis (Yradius)
the x-co-ordinate is calculated using: Xradius*cos(angle)
the y-co-ordinate is calculated using: Yradius*sin(angle)


JeffM said:
I also wonder why, if your program invariably generates outlines that are ellipses or close enough to ellipses in one quadrant, an alternative solution is not to calculate in just that quadrant and use symmetry for the other quadrants. (The answer to that may be that ultimately you want to distort the ellipse in ways that are not symmetric).

That's what I'm doing.

JeffM said:
Finally, I wonder why you do not use the trammel method that the Wikipedia article specifies to generate the outline of the ellipse. That should be very easy to program, bases the program on the center of the ellipse as is apparently important, and involves parameters based on lengths rather than angles. (Again, this may be inconsistent with your future plans, and it may be inefficient computationally.) Asking the user of your routine to center the ellipse and specify the maximum horizontal and vertical widths would certainly lead to a simple user interface.

That's would take several more steps and require the same basic trig technology I'm using (atan, sin, & cos).
And I'm not drawing outlines, anyway. That's just the demo graphic.

Any other takers on this problem?

?????????????????????????????????
 


You're talking about a Personal Home Page: Hypertext Preprocessor program to take advantage of the portable network graphics image-formats that allow alpha transparency.

IKD.

But I find it interesting that the acronym
PHP is an initialism, like VISA.

 
I'm not drawing outlines, anyway.
PLUS
The length of the ray segment which is the radius in question is calculated using the Pythagorean Theorem. When you loop through to calculate the lengths or endpoints of the rays, you ARE outlining the ellipse.

The values of a and b - the sides of the triangle - are found using the sin and cos of the angle of the ray segment as applied in the formula for ellipses Which of the many formulas are you using? For example, are you using a center-offset approximation, which only works for an ellipse of low eccentricity? Your program does not generate correct results; therefore, either you are not using a correct formula, you are using a correct formula in an inappropriate way, or your program is improperly implementing the formula. It is a tad difficult to determine which error you are making if you will not disclose what formula you are trying to use.

As for symmetry, though you say That's what I'm doing, you also say given an angle (0 to 2PI radians) (0 to 360 degrees) This is NOT taking advantage of symmetry. If you are satisfied with the results in one quadrant, you can use reflection without processing through the full revolution.

That (using the method shown in Wikipedia) would take several more steps True, but it might also give a correct result.
and require the same basic trig technology I'm using (atan, sin, & cos). There is absolutely no need to use any "trig technology." You can calculate the length of the ray using the Pythagorean formula (as you well know) if you have the coordinates of the endpoint of the ray, and there is a perfectly simple algebraic formula to do that.

Good luck.
 
Well, another verdict is in. I added this code to the test ellipse program:

Code:
  for ($y=20; $y<300; $y+=30)  {  // loop through several points, 30 pixels apart
    imageline($image, 480, 400-$y, 400, 400, $yellow);  // draw a line from the test point to the center
    $beta=atan($y/80);  //  calculate the angle of the yellow line
    //  draw a red line at the SAME angle from the center to the edge of the ellipse.
    imageline($image, 400+200*cos($beta), 400-300*sin($beta), 400, 400, $red);  }

remember, the centerpoint of this ellipse is at (400, 400)

and we get

testellipse2.png


So, as I was saying, it appears as if the angle calculated using
angle = arctangent ( rise / run )
is inaccurate - just slightly ahead at first and rushing faster and faster, then slowing back to normal just at the end.....

Are we paying attention class?

And no drinky-drinky out of the steel boot flask back there in the back row. Jeff!!!!

I hope this helps someone somewhere, but I think the comments this forum have become quite useless to me.

If any one can point out either (a) I'm using the incorrect formula, or (b) using the formulas the wrong way (they are plain as day as PHP reads like English standard mathematical formula notation. Don't think of it as a "program," just a series of steps you would take to solve the problem on paper.)
I'd surely be thankful. In the mean time, I'll be looking into whether this is a round=off error, an error with PHP's atan function, or what???

Peace, ya'll
 
Top