Sunday, August 28, 2016

Activity 3 - Scilab Basics






As an introduction to learning the basics of Scilab, we were tasked to generate synthetic images using matrix operations in Scilab.

First off, we have the centered square aperture. I found this to be relatively straightforward.

                     
Figure 1. Code (bottom) and generated image (top) of the square aperture.

The first five lines of the code are responsible for generating a 2D grid wherein each point in the grid is assigned an x and y coordinate pair. The maximum and minimum value for both x and y coordinates were 1 and -1, accordingly. The generation of the 2D grid is handled by the meshgrid() function where and are the "template" vectors of the grid. As shown in Figure 1, The size of the square aperture can be varied by varying the parameter a. Of course, a must be between 0 and 1 for an aperture to even exist at all.

Next up, the sinusoid along the x-axis.

                     
Figure 2. Code (bottom) and generated image (top) of the sinusoid along the x-axis.

The code takes advantage of the way meshgrid() works. Instead of generating a 2D grid containing an xy coordinate system, a 1D array of sine values (x) was generated and then replicated across all rows of a new matrix (because you want a sinusoid along the x-axis) . Again, the frequency of the sine wave can be altered by altering the value of w.

Although physically simpler, I had to put some thought before constructing the code to generate the rectangular grating along the x-direction. After some time, I realized I could just modify the sinusoid code. After all, the only difference between the two was that the change between "black" and "white" regions had to be abrupt for the grating case. I used the find() feature to do this.



Figure 3. Code (bottom) and generated image (top) of the grating along the x-axis

Moving on, I modified the code given to us during class to generate a circular aperture [1]. The only change needed was to alter the condition within find() to point to the region between two radii instead of one.

                             
Figure 4. Code (bottom) and generated image (top) of the annulus

For a circular aperture with a gaussian transparency, I once again modified the circular aperture [1] code() in a way to include gaussian transparency. The code works obtaining a radial coordinate r (as was done for the annulus and circle codes [1]) using the x and y grid coordinates generated wherein the "origin" is set at the center of the grid (where x and y are 0). A (the grid to be plotted) is then populated using the gaussian function with parameter a and the radial coordinates r (line 12). To define the boundary of the aperture, a find function is used to set all values outside a radius of b to be zero (line 13).


Figure 5. Code (bottom) and generated image (top) of the circular aperture with gaussian transparency

Again varying the circle code[1], we can create an elliptical aperture by introducing the parameters a and b into the definition of r (line 10) and then setting all the values for which r<1 to 1. This is motivated by the equation of the ellipse.


Figure 6. Code (bottom) and generated image (top) of the elliptical aperture 

Finally, I modified the square aperture code to create a cross aperture. This was done simply by modifying the parameters to create rectangular apertures instead and then including an additional find() function.


Figure 7. Code (bottom) and generated image (top) of the cross aperture

Being wholly a Python supporter for most of my coding life, Scilab is pretty unfamiliar to me. After an initial exposure to the language last semester, the language still hasn't caught up to me as much as Python has. I do, however, now see the vast advantages Scilab has over Python when it comes to matrix and grid operations and subsequently, image processing. The problem of "parsing" data which in Python, would probably be done by loops, is completely handled by Scilab's find() function. I found this function to be pretty handy in the generation of the different apertures. All in all, programming in Scilab is pretty straightforward. I honestly now understand the simplicity and appeal it has over other programming languages.

After a quick search online, I found several other blogs where students of past years got pretty creative with their images. After seeing several "rotated" images, I set to try to use the rotation matrix to try to generate my own rotated ellipse. The result is below.

Figure 8. Code (left) and generated image (right) of the 30 degrees rotated ellipse

As shown above, the code is similar to that of the ellipse. The big difference, however, lies in the fact that a rotation matrix (line 83) is introduced. Each pair of X and Y coordinates are accessed and then multiplied with the rotation matrix to produce rotated coordinates. In effect, the entire grid is being rotated. The condition for the ellipse still follows with the definition of r in line 98.

I explored rotating, adding, subtracting, and multiplying different generated images to obtain the following. Can you guess which operations led to which figures?
                                                              
Figure 9. Figures generated by performing different operations between the figures already generated.

Based on my performance this activity, I would rate myself a 10 out of 10. I really enjoyed and explored the use of the rotation matrix in generating more complex images. Moreover, I can say with a little more confidence now that I'm pretty familiar with programming in Scilab.

Acknowledgements:
I'd like to acknowledge Martin Bartolome's blog [2] where I first got the idea to use a rotation matrix and subsequently, Mario Onglao, Martin's source.

References:
[1] M. Soriano, "Scilab Basics," Applied Physics 186 Activity Hand-outs, 2015
[2] Activity #3 – Scilab Basics. (2015). Retrieved August 29, 2016, from https://barteezy.wordpress.com/2015/08/22/activity-3-scilab-basics/

Thursday, August 25, 2016

Activity 2 - Digital Scanning



In an effort to use ratio and proportion to digitally reconstruct printed plots, I chanced upon a printed copy of the proceedings of the 1987 SPP. As I browsed through the articles, I recognized several names, one of which especially brought torturous memories of the hardships endured while taking Physics 131 and 132. Eventually, Minella C. Alarcon's  paper entitled "An Optical Remote Sensing System By Near-Infared Molecular Absorption Spectroscopy" led me to take a look at this graph.

   
Figure 1. Scanned graph from [1]

Though as interesting as the article may have been, I focused my attention on digitally recreating this graph. The first step was ensuring that I had scanned the page well enough to ensure that minimal distortions in the image would occur. If part of the scanned document was "lifted up" from the flatbed even the slightest bit, then parts of the graph could have been shrunken or stretched.

After several attempts, I finally obtained the image in Figure 1. I had noticed that despite all efforts in trying to straighten the scanned image obtained (so that the x and y axes are perfectly horizontal and vertical respectively), both axes could not be simultaneously aligned with digital grid on the computer. This could be caused by distortions caused during the scanning process, but after SEVERAL re-attempts at scanning, I have come to the conclusion that the x and y axes of the plot itself aren't perfectly perpendicular. This, in the long run, caused slight deviations in the digital reconstruction as will be seen later.

To start, I opened the scanned image in MS Paint and obtained the (x,y) pixel positions of the x and y tick marks. Dividing the difference in magnitudes indicated by adjacent tick marks (done for both the x and y aces) by the difference in pixel values of the same tick marks, a corresponding mag/pixel ratio was obtained. This was done for all pairs of adjacent tick marks and the ratios obtained were averaged. This resulted in ratios of 0.002883 mag/pixel and 0.01695 mag/pixel for the x and y directions, respectively . I employed this methodology of averaging the results for all possible intervals rather than just taking one interval in order to account for inconsistencies in the distances between tick marks that may have been caused by errors in the plotting of the actual graph.

I then took representative pixel points, making sure to take more points on the curve where the curve's slope was changing fast. This is needed due to the fact that the interpolation process employed by Microsoft Excel roughly connects the data points with straight lines. Thus, for a fast changing curve to be accurately represented, many points have to be taken.

After adjusting for the pixel position of the coordinates axes origin and the pixel coordinates axes origin (because the pixel measurements were measured with respect to an origin in the upper left corner of the image), I then multiplied these x and y pixel values of the representative points to obtained the blue plot in Figure 2.


Figure 2. Overlayed Excel digitally reconstructed plot with original scanned plot

As shown in Figure 2, the reconstruction is very similar to the original image. This not only validates the use of ratio and proportion in digitally reconstructing the plot, but also reveals some information on the quality of the construction of the original plot. Looked at the overlayed image, the y axes of both the reconstructed and original plots are aligned while the x axes are not. The slight deviation between x axes while having aligned y axes tells us that the x and y axes of the original plot itself aren't perfectly perpendicular. Following both reconstructed and original curves, we see that they separate towards higher x values. This can again be attributed to the fact that the original axes were not perpendicular to begin with. 

Looking at the tick marks, we see that most but not all the tick marks of both the reconstructed and original plots coincide. This is to expected given the fact that the ratio used was the averaged value obtained from all intervals used. Moreoever, the small differences reflect the inconsistencies in the lengths of the intervals in the original scanned plot itself. These could be due to an error in the scanning process and/or errors in the construction of the plot itself.

Taking all these into consideration, I would rate the reconstruction a value of 10. Although the slight deviation exists near the "end' of the curve, this is readily attributable an error in the construction of the original plot itself and not in the reconstruction procedure. 




References:
[1]  Alarcon, M. C. (1987). An Optical Remote Sensing System By Near-Infared Molecular Absorption Spectroscopy, Progress of Theoretical and Experimental Physics (1987): Proceedings of the Sixth National Physics Congress, U.P. Baguio May 22-24, 1987 (pp. 72-73).