Did you know that you could mount a remote directory (any directory accessible to you) through an ssh command? I was reading 16 ultimate ssh hacks by Carla Schroder and found out this little piece of heaven. The command is sshfs. You use it in the following way:
sshfs USER@SERVER:REMOTEDIR LOCALMOUNTPOINT
There are also some really cool comments on slashdot about further ssh candy.
One of the things that I did not like about using R was that there was not “easy” way of calling it in a command sort of way. The test part of my R workflow consisted in going into the R environment and setting everything up from scratch. This was a pain (to say the least). Another problem that overly annoyed me was that I could not get to the script arguments. My solution to these and more problems was to use the -e argument of the R command (not good).
Today I find out that I was overworking myself all along. Since R 1.5.X it has something called Rscritp, that allows the execution of R scripts in a “hashbang” sort of way. This saves me the trouble of having to directly execute R for testing. I can now code a script and add a “#!/usr/bin/Rscript” to the header so it can do the “right” thing.
But it does not end there… The arguments can be accessed by using the commandArgs() functions. This is OK, but you still have to do quite a lot of analyzing to get the command line parsing right. If there was only something like getoptparse…. It turns out that someone has already been down this road and was kind enough to make an R package for that. I present to you the getopt package. So now I can parse those arguments in a sane way.
This has made my day :)
This is a very interesting way of gathering relative information for ones research. I like it because it is repeatable and somewhat measurable. I read a paper by Paolo Tell that described the process quite nicely :). Here is the link.
This post is meant to show how a “good” plot picture looks like. I did the tests in my back yard.
Things to note are:
Good Plot PictureRemember to take more than one picture of the same plot from different places. This will increase the possibility of getting a “good” detectable picture.
Try findInterval :).
Let me try to explain what I mean with this title. I have a vector of numbers. The numbers represent bin limits. For example c(1,2,3) is a vector that represents 2 bins. The first is [1,2) and the second is [2,3]. I need a function that returns the bin index given any number within the vector range (in our example the range is 1 to 3). So the function must return 1 if it receives a 1.4. It returns 2 if it receives 2.7 etc…
The function you are looking for is findInterval.
I have defined two models that I want to use for my experiments with the CENS data set. These models are based on Eric Graham’s previous work. Both of them are Naive Bayesian Models with a slight twist :).
I created a latex document that described the way I’m going to apply these models to the data. The document itself is still a draft and will be changing in the future (hopefully). The link to the source code is here. You can find the pdf in Bayesian Model Definition.
I’m guessing there are many ways to handle this; this is just the one I feel comfortable with :). I like it because it shows me the things I still need to do in the resulting document. So when I read a draft of my masters degree, I will know what needs to be fixed.
\usepackage[footnote,draft,silent,nomargin]{fixme} \begin{document} …. bla, bla, bla…. \fxnote{Text describing the todo :)} …. bla, bla, bla…. \listoffixmes \end{document}This will create two places where to see the “fixme”: 1. in the footnote on the page where the “fixme” was written and 2. at the point where \listoffixmes is executed. Both these reminders are very useful when proofreading a document. You’ll have a “bird’s eye view” with the index and you’ll have specific context with the foot note :)
My solution to this issue was to write a bunch of code to handle the behavior of the average calculation at the 0 and 360 points. It was a pain in the neck, and I probably have it wrong :(.
Today I retook the issue and found various ways of doing the average calculation with less code and more math. This stack overflow link has really cool links and ideas. I really like the following algorithm to handle the calculation:
x = y = 0 foreach angle { x += cos(angle) y += sin(angle) } average_angle = atan2(y, x)There is also a link on wikipedia briefly explaining stuff about means of circular quantities. Here is a paper on google docs that also talks about this issue.
I unfortunately did not find a way to do it with opencv. Which is strange given that you might want the mean of an HSV image. I guess the way to go is to convert it to RGB, calculate the mean and then try to use the RGB->HSV equations to find the Hue mean. However, this seems just plain wrong. Additionally the cv::mean functions do not provide (according to the documentation) a facility to differentiate between a regular Cartesian mean and an angular mean.
Are current objective is to try to make the photo-plot based phenology work-flow comparable to the current phenology work-flow. To accomplish this we need to streamline the process of making the annotations on the images. We want to reduce, as much as possible, the amount of time it takes to annotate an image. With this in mind I want to list a few characteristics that the new annotation GUI that should go into the final design.
I would lie if I said that Gigavision has not been a inspiration for what we are to do. But notice that our product is not going to be an annotation system. Our product is going to be the proof that an annotation system -like Gigavision- has the potential to add value to phenological measurements as we know them :)
For my stay abroad I had to come to CENS at UCLA. The advances related to novel methods for collecting and analyzing ecological data is synchronized with what I have been doing for the past couple of years. I arrived a couple of weeks ago and after a short vacation, I have started to work alongside Eric Graham.
He has a series of scripts that he is using to analyze image data from various projects related to CENS. I have taken a look at the scripts and am currently in the process of understanding them. Though they are no longer available through github, you can find more up to date imaging code related to ecology here, here, here and here. You can also look at my EcoIS and EcoIP projects for further reference on the work done in UCLA.
I have analyzed about 20% of what he has and see that he is doing what I have been trying to do all along (segment an image based on other images to elucidate additional data, like number of flowers). I’m not yet sure how successful these scripts are with the data he has nor am I sure if they can be used with the images we have from Zackenberg. Time will tell :)
I’m excited to be here and plan to take advantage of my stay in all respects :)
Joel's Blog 