#ap186

Erosion and Dilation

So remember how operations with sets work? Morphological operations rely on those. In this part of the activity, we focus on two simple operations: Erosion and Dilation. Aside from our image, we need a structuring element to operate with. This can be almost any shape, as I’m about to show, and quantitatively dictates how an object changes. I’ll get right down to showing how this works using the following base images.

Okay, so to put it simply, erosion removes pixels, while dilation adds them in. Just how many pixels are removed or added is determined by the structuring element. Let’s start with dilation. We apply the structuring element to every pixel on the base image, noting the reference pixel of the element, and all the pixels not yet already part of the image are added in. In erosion, we again apply the structuring element to every image on the base, again noting the reference pixel. If the applied structure element can fit into the base image, that pixel is kept. Got it? No? Maybe demonstrating it would be better.

And that’s how it works for a simple 2x2 square element. But a structuring element can be almost any shape, right? So here are more examples.

For a 2x1 vertical line:

For a 1x2 horizontal line:

For a 3x3 cross shape:

For a 2-pixel diagonal line:

Segmentation

So how can this help in segmentation? Well, in cleaning mostly. We can use morphological operations to clean up images for an easier time in segmentation. We used the IPD kit by Dr. Harald Galda to perform morphological operations on an initial segmentation on the following image of “cells.”

That’s not all it can do, though. This kit allows us to identify and index continuous “blobs” in the image. We can then proceed to do things like measure the area of these blobs and use the histogram of these areas to find an acceptable range for an average “cell.”

So with this new range we can do things like filter out abnormal “cells.” Take this image for example. We were asked to highlight the “cancer cells,” using image segmentation.

Another life saved by Mighty Morphological Operations. 

Like I’d said in the introduction, I struggled a bit when it came to using the functions of the IPD kit. I still managed to produce the required output, but again with not much exploration. However, I like to think my presentation deserves a bit of credit, so I’m giving myself 10 out of 10. I’ve pretty much stopped attaching parts of my code, but that’s mostly because, besides the new functions of the IPD kit, it would mostly appear similar to at least one of the snippets I’d previously uploaded.

Time for some Mighty Morphin’ Acknowledgements:

Dr. Harald Galda, the legend himself who provided the IPD kit

Dr. Maricor Soriano, for guiding us in using the IPD kit to save the life of the cancerous paper

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

The original image

The goal of this activity was to recreate a plot from an old journal. The plot had to either be hand drawn or created with an old XY plotter, which means we had to dig through the College of Science library for an old publication. I didn’t want to have to do that before the SPP conference, so I was planning on waiting until we came back and looking through the older theses in our lab’s archive.

Fortunately, Albert, who was a labmate as well as a classmate, offered to help find me an old plot while looking for his own. Thus, from the Canadian Journal of Physics Volume 29 published in January 1951, comes this plot.

It’s from a paper titled “The Scattering Lengths of the Deuteron” by D. Hurst, et. al. A deuteron is an isotope of hydrogen, consisting of a proton and a neutron, and would be the nucleus of the atom called deuterium. What makes a deuteron special is its stability, as a free neutron would decay, but a deuteron keeps its neutron through its binding energy.

The plot itself was drawn using an old XY plotter, and corrected for rotation and warping using Photoshop.

Recreating the plot

This is where most of the elbow grease went into. Our professor provided the outline of the method: open the plot in Paint, use the X and Y pixel values to determine the ratio of pixels to ticks on the plot, get points from the image and plot them, and compare the result to the original image.

First I went about finding that pixel to tick mark ratio using Paint. I recorded the locations of the ticks then took the average distance between them to serve as my ratio. I got 74.5 pixels per 0.1 units for the X-axis, and about 74.4 pixels per unit for the Y-axis. I used Kingsoft Spreadsheets because I don’t own a copy of MS Office myself, nor did I want to use Google Sheets for fear of connection issues taking a toll on my admittedly short patience.

That wasn’t too bad. Next came the actual points. Looking at the plot, there are six points where measurements were taken, corresponding to scattering angles. I took their pixel locations, not too bad since the points are aligned on the Y-axis, and also recorded the Y-intercepts for the three lines formed, just to ensure I got lines that reached the Y-axis.

As you can see above, I did corrections for my Y pixel values since Paint counts starting from the top of the canvas. I also corrected for the margins using the location of the origin. Only then did I finally make the plot. You can see the resulting line graph, but I used the scatterplot function in Spreadsheets, with connecting lines, since the values I had were technically ordered pairs of X and Y. I manually set my values for the axes, but the ticks were set using the ratios. 

Comparing the two images

Again, I used Spreadsheets, which doesn’t have the function that lets you use an image as a background to a graph, as far as I know, so I copied both images onto Photoshop and set the layer containing the original plot to Multiply, eliminating the white of the paper and allowing a comparison to be made.

Overall, I’d say they line up quite well, don’t you?

Well, that wasn’t nearly as bad as I thought it’d be! That’s probably because I used only seven points for each line, not to mention the fact that they’re lines. Three lines, yes, but lines, nonetheless. I’d be shaming myself if I wasn’t able to recreate something like this. Still, my major concern was finding an actual plot to use, and with Albert’s help, that wasn’t a problem. I will forever be grateful to you, Albert.

Now it’s time for some self-evaluation. Okay, my output is there, and I did show the overlay comparison, although that was with the help of Photoshop. Speaking of Photoshop, I was able to use pixel ratios to fix the warping of the original plot, similar to what we learned in our first meeting of this class. That’s something, right? And I was able to recreate the plot well, even though it just consisted of three lines. But, oops, no captions again. I’m starting to think I won’t use them at all, since Tumblr doesn’t really have a good format for those, unless I switch to using LaTeX, which I probably won’t be doing anytime soon. Overall, I’d give myself a 9 out of 10. I do feel like I didn’t put in enough effort as I could have, with me not finding my own image and all, and it being an easy one to match.

Here come the acknowledgements and references,

D. Hurst, et. al., “The Scattering Lengths of the Deuteron,” Canadian Journal of Physics Volume 29 January 1951

HyperPhysics, for telling me what a deuteron is