Number of pixels at radius r

I have written the following code to derive find out the average intensities at a given radius from the center of an array.

void temp_match_img::makevec(){
int temp;
for(int i=-radius; i<=radius; i++){
for(int j=-radius; j<=radius; j++){
temp=(int)sqrt(float(i*i+j*j)); //distance of the point from the local center
if(temp<=radius){
rpvec[temp]+=tmimg[i+row][j+col]/temp; //The average intensity at //radius=temp
}
}
}
}


Can anyone tell me what is approximately the number of pixels in a circle say "n" pixels in radius?
My current approximation is that it is some constant into "temp" - which is the distance of any point from the center of the array.

N.B. The array has odd dimension, e.g. 21X21 or 105X105

Also please let me know how to publish codes. People on this forum publish codes in good looking format, and I do the same in the above ugly format.

Well, roughly, the number of pixels would be the circumference of the circle so: 2*PI*r.

Oh, use [code][/code] tags around your code.

I got the impression that the OP wanted to know the number of pixels inside the circle area with the radius of r pixels.
In that case, shouldn't it be, again roughly, PI*r^2?

Hm. I would say the number of pixels would be about PI*r².

Sorry guys, by "in circle" I meant in the set represented by the circle. Basically the circumference.

The answer is not very close to 2*(pi)*r - neither is the answer for the number of pixels inside the circle close to (pi)*r^2.

There's some good approximation for both - I somehow am not able to remember.

Quote:

---

Originally Posted by sgsawant

Sorry guys, by "in circle" I meant in the set represented by the circle. Basically the circumference.

---

Well, it gets a bit tricky defining precisely what's on the circumference. I presume you mean pixels on the outer boundary of those which fall inside the circle. I would expect that to be close to 2*pi*r.

Quote:

---

The answer is not very close to 2*(pi)*r - neither is the answer for the number of pixels inside the circle close to (pi)*r^2.

---

You'll have to back that up with specific numbers if you want to claim that mathematics which has existed for thousands of years no longer works.

Try it out on a 5x5 grid (radius 2)-----the filled circle contains 13 elements, and pi*2*2 is about 12.5. Coincidentally, the estimate of the circumference is the same in this case; if you go with 4-connectedness, then you've got 12 elements, so it's still close. Going with 8-connectedness yields only 8 elements on the boundary, but since the distance between each is now sqrt(2) rather than 1, you can estimate that as 2*pi*r/sqrt(2) = 8.8.

The approximations should get better as you increase the radius. You may not simply be able to divide by sqrt(2) once your circle gets big enough that you need a combination of 4-connected and 8-connected pixels to represent it, so just stick with 4-connectedness is my suggestion.

Quote:

---

Originally Posted by sgsawant

Sorry guys, by "in circle" I meant in the set represented by the circle. Basically the circumference.

The answer is not very close to 2*(pi)*r - neither is the answer for the number of pixels inside the circle close to (pi)*r^2.

There's some good approximation for both - I somehow am not able to remember.

---

Those formulas are pretty good approximation :)
You are truncating the return of sqrt() function, you need to round it:

Code:

---

temp=(int)(sqrt(float(i*i+j*j)) + .5); //distance of the point from the local center

---

Here is my test program:

Code:

---

#define _USE_MATH_DEFINES
#include <math.h>

void foo(int radius, int& countArea, int& countCirc)
{
        int temp;
        for(int i=-radius; i<=radius; i++)
        {
                for(int j=-radius; j<=radius; j++)
                {
                        temp=(int)(sqrt(float(i*i+j*j)) + .5); //distance of the point from the local center
                        if(temp<=radius)
                                countArea++;

                        if(temp==radius)
                                countCirc++;
                }
        }
}

int main()
{
        int radius = 105;
        int countArea = 0;
        int countCirk = 0;
        foo(radius, countArea, countCirk);
        int area = M_PI * radius * radius;
        int circ = 2 * M_PI * radius;
        return 0;
}

---

For radius of 105 I got ~1% error, but it goes down for greater values of radius.

Oh.. ok. I was a bit concerned about the lower values. I guess if I manually enter the lower values the higher values can be estimated with reasonable accuracy as you have shown.

Yeah, that's a perfectly reasonable approach to take.

The answer depends entirely on the actual algorithm used to draw the circle. there's pixel approximation algorithms that tend to be 'thicker' and there's algorithms that never fill a full angle.

Code:

---

  *      *
  **      *
full    no full angle

---

Quote:

---

Originally Posted by hoxsiew

Well, roughly, the number of pixels would be the circumference of the circle so: 2*PI*r.
...

---

Actually, the number of distinct pixels drawn by the midpoint circle algorithm is 4 round(sqrt(2) r), or equivalently, 4 floor(sqrt(2) r + 1/2), which is approximately 4 sqrt(2) r. This is about 10% smaller than 2 pi r.

Quote:

---

Originally Posted by sgsawant

I have written the following code to derive find out the average intensities at a given radius from the center of an array.

---

Another approach is to actually "draw" the circle using a circle drawing algorithm. See the example C# implementation here,

http://en.wikipedia.org/wiki/Midpoint_circle_algorithm

You could easily modify it to visit all "pixels" on as well as inside a circle of a certain radius and do what ever calculations you like on the "pixels" you encounter. And of course you always know how many "pixels" you have visited.

This is even more efficient than your current algoritm since there's no expensive square-root calculation and you only visit exactly those "pixels" you're interested in.

Quote:

---

Originally Posted by Lindley

...
You'll have to back that up with specific numbers if you want to claim that mathematics which has existed for thousands of years no longer works.
...

---

The thousands-of-years-old mathematics for the length of the circumference of a circle is, of course, (still) correct.

However, the number of pixels does not have to be (and, in fact, isn't) the same, or even very close to, the length of the circumference of a circle.