A4: Area of Expertise
This one’s a bit heavier on the programming side than the others before. I’ll admit I was a little intimidated when I started reading the instructions, especially when Green’s Theorem was mentioned. But when I actually got started, it turned out to not be as bad as I thought. I still struggled a bit with the syntax and all of scilab, but in the end, I pushed through. This activity required the SIVP module in scilab 5.5.2, and ImageJ.
Green’s Theorem
So this activity was all about areas. And a way of computing for the area of a two-dimensional geometric shape is through Green’s Theorem. Here’s the form of the Theorem used in the construction of the code.
This form is necessary, as the area can be expressed as an integral, and integrals can only be solved for numerically through methods such as summation.
Alright, instead of waiting any further, I’ll show the code I used to calculate the area of a 2-D shape now. This code only works with monochromatic bitmap images, as is the limitation of the imread function used here.
//reading image Img = imread("image.bmp"); E = edge(Img, 'prewitt'); //finding edge of shape
//finding centroid [x,y] = find(Img==255); xcent = mean(x); ycent = mean(y);
//sorting edge coordinates [xe,ye] = find(E); xef = xe - xcent; //fixing with respect to centroid yef = ye - ycent; r = sqrt(xef.^2 + yef.^2); //finding distance r th = atan(yef, xef); //finding angle theta coord = []; for i = 1:length(xef); //compiling a list for sorting elem = [xef(i) yef(i) r(i) th(i)]; coord = cat(1,coord,elem); end [sort,j] = gsort(coord(:,4),'lr','i'); //j = index wrt theta coord = coord(j,:); //sorting wrt j
//computing area using Green's theorem summ = 0 for i = 1:length(coord)/4; if i == length(coord)/4; summ = summ + (coord(i,1)*coord(1,2)-coord(i,2)*coord(1,1)); else; summ = summ + (coord(i,1)*coord(i+1,2)-coord(i,2)*coord(i+1,1)); end end Area = 0.5*summ;
The comments should help in explaining how the code works, but I’ll give a quick rundown too.
After reading the image, edge is used to find points on the edge of the shapes. The second argument in the edge function interested me, since when I used the default values to find the edge of a square, it only gave the four corners. This argument turned out to be the edge detection method, with the default being sobel. Mich, a classmate and labmate, told me to try using prewitt, and that gave me something that looked more like a square’s edge.
Still, I wanted to see which of the edge detection methods worked best. To do this, I tested prewitt, canny, and the default sobel. There are two more methods available to scilab: fftderiv and LoG, but fftderiv wouldn’t work, and I didn’t want to use LoG just yet.
The centroid is found by taking the mean of the x and y positions of all the points on the shape. This is set as the origin when computing for the angle θ of a point on the shape’s edge. This angle is used to sort the edge points before summation. To be honest, figuring out this sorting part is what took up most of my time on this project.
Next, Green’s Theorem is applied, and we have the area. Yay.
Area of a Square and a Circle
For this activity, I tested the code first on two simple shapes: a circle and a square. I did the test for two resolutions, just to get an idea of how much the resolution affected accuracy.
Now you see the four points sobel returned for the edge of the square. Looking at the circle, sobel seems to have produced a series of disjointed points, for the most part. Prewitt edge detection gave a thicker edge, meaning more points. Finally, canny gave a thin edge, note the lack of the corner pixels for the square edge though. How did this affect the accuracy? Well,the results were pretty interesting.
For the square, prewitt and canny beat sobel, and it’s not hard to see why, with sobel only giving four points for the edge. It looks like the two are matched though, not being entirely perfect themselves.
And for the circle, what’s this?! Sobel wins! Prewitt comes in second, and canny pulls a third. That’s unexpected, but I guess it has to do with how the Green’s Theorem allows us to estimate the area. The world is full of surprises.
Area of... the Sunken Garden?
Alright, the code can compute areas for simple shapes, but what about the area of a place? How about a landmark like the sunken garden in U.P. Diliman? Let’s put it to the test, with the three edge detection methods. Here I used Google Maps, with the measurement feature in My Maps to get my theoretical area. The scale Google Maps provided at the zoom I used was 2.8 pixels/m.
Looks like all the expected traits present in the simple shape edge detection show up here as well. That’s good. Yay for consistency.
And prewitt wins this round! Of course, 8% isn’t exactly as good as the previous results with the simple shapes, but I think this can be improved on by working with larger resolutions, as the test with simple shape shows. The resolution of the image I worked with was 1076p x 705p, which is as big as I can get the whole sunken garden in Google Maps to appear on my screen.
Measurements in ImageJ
I’ll admit, I’m a Adobe Photoshop or Paint Tool Sai guy. I’m not really familiar with ImageJ, so I didn’t expect this feature. It turns out you can use ImageJ to analyze the size of objects present in the image. Granted, ImageJ was created with the idea of analyzing biological samples in mind, but hey, I did say I wasn’t familiar with it, right?
Basically, you can set the ratio of pixels to whatever unit you choose, and analyze the length of any segment you draw, or the area of any shape. That’s pretty cool, so I wanted to try it on something standardized, like a poker-size playing card.
This is the back of a card in the Bicycle Zombified deck, featuring art by Billy Tackett. I think it fits in the theme of biological specimens. Anyway, poker-size cards have a standard length of 88.9 mm, and a standard width of 63.5 mm, giving a rectangular area of 5,645.15 mm^2.
I set the length of the card into ImageJ after drawing a line segment along the card’s length. It returned a scale of 11.694 pixels/mm. Then I drew a rectangle over the card to get its area. I chose to ignore the curved bits at the corners this time, so I could get a clean rectangle. The area ImageJ gave me was 5,679.585 mm^2. This gives an error of 0.61%. Not bad at all.
Okay, that was fun. I owe a lot of the ideas behind the sorting part of the code to Roland, another classmate and friend, and once that was done, the rest just kinda flowed.
Alright, time to evaluate myself. Okay, the output is all there, and the figures and tables have captions at last! Good job, me. The tables and images are all transparent now, and that is a plus in my own book. Finally put all the Photoshop know-how I’ve amassed across the years into making my tables transparent. The ratios from Activity 2 and plotting from Activity 3 came in handy for this too. I’m going with 11 out of 10 this time. Earn those bonus points, me.
Finally, for my acknowledgements and references:
Scilab Online Help, for references on syntax and functions
Google Maps, for the map of the U.P. Diliman Sunken Garden
Michelle Cirunay, for enlightening me on the different edge detection methods
Roland Romero, for helping me solve the riddle of sorting edge coordinates