As I mentioned in the last post, I am now studying machine learning in my new position. Today I came across a problem to use SVM to do multiclass classification. The toolkit (link) downloaded from NI did not provide the ability to do multiclass classification with SVM but only for two classes (it’s quite a useful tool still). So I took use of the SVM VIs and made a multiclass version using one-vs-all method.
There is a good tutorial on one-vs-all or one-vs-rest classification by Andrew Ng (link). So basically we pick one class each iteration as Class A and make the rest classes as Class B. Only the test data that locate in Class A are allocated to the known class. Here is the code:
The original trained labelled data are classified as Class 0, 1, 2, … N. In the i-th iteration, only the data from Class i are re-classified to Class 1 and the rest data are re-classified to Class 0. When the test data locate in class 1 area, they are classified as Class i. Any unsorted data are left in Class -1. When I test the performance of this one-vs-all classifier, the result seems fine
The code is not optimized and the execution may cost a while.
Hi all, hope you had a wonderful Christmas and a happy new year. It’s been 4 months since last post and something changed in my life. I started a new job in a LabVIEW consultancy company based in London. I always love London, in which there are so many places to explore.
So have to say goodbye to the lab and neuroscience. I am doing signal processing with LabVIEW now. It sounds fun and can be a good opportunity for me to learn more about machine learning and advanced LabVIEW programming. I will keep updating the blog and am thinking if I should change the blog title to some more general one (Let machine learn? Let lab wow?).
All the best.
When I tried to do parallel tasks (e.g. multiple producer/consumer loops) in LabVIEW, it was always painful to quit all loops “elegantly”. What I wanted was a notifier to tell all loops when an error occours in any loop. I know there are a few error manager VIs in the internet already but I just reinvented the wheel anyway.
In this error manager.vi there are 3 states: reset (clear errors in the shift registor), read (monitor if there is an error) and hold (stop reading when error).
So I sort of created a functional global variable here using the single loop to store the error. You can use this VI in every loop and it will quit all loops if an error happens. Here is an example:
Hope this is useful to you:)
In my projects sometime I need to write a 2D array in the same line into the text file (see the figure below).
We know that LabVIEW can write 2D arrays directly to the text file using “Array to Spreadsheet String.vi” or “Write to Spreadsheet File.vi”. But when we want to convert it to a single line it is not straight forward. We can convert the 2D array into 1D array before writing using “Reshape Array”. I don’t like this method, which is inefficient in term of space and time. Alternatively, we can write the 2D array row by row using a for loop. But LabVIEW just automatically start a new line for each iteration . The method I used is simple, but took me a while to come up with. I set the file position (“Set File Position”) each time when a row is writen, as shown below
The file position is set at the end and the offset is changed to -2 to delete the carriage symbol. A tab string is added afterwards to keep format the same. This program does the job without converting the 2D array. You can add “Transpose 2D Array” for the 2D array if needed.
Recently I had been dealing with bugs and cells. I was trying to locate the moving cells Euglena with a camera. The Euglena is a single cell that belongs both to the plans and the animals. A picture of the Euglena is shown below. The length of a single Euglena is about 50 um.
The illumination was not good due to my poor optical setup. I tried to identify the cells according to its intensity and size but neither worked well. The strategy I took at last was extracting the stable background and then compare it with the live video, so that the moving targets can be identified. The way of generating the background is averaging all the grabbed images (or, video as we call them). The changing bits are then smoothed by the number of the frames.
When averaging the images, we assume the mean of N framesimages is A_n and the (N+1)th frame is I_(n+1). Both variables are 2D arrays. Then the mean of (N+1) frames is
A_n+1 = (N * A_n + I_(n+1))/(n+1)
The code is shown below (with re-calculate/ clear function):
This SubVI can be called without external shift registers. This simple function allows us to extract the still background from the video. And thus the moving (or any changing) targets can be extracted no matter how messy the background is. The result is shown in the video below:
As I said in the description of the video, “This demo shows using an algorithm tracing an Euglena in the dish with poor (non-uniform) illumination. The mid-left and mid-right videos are raw videos from the camera. The bottom-left video is the background generated from the video in real-time. The bottom-right video is the target (Euglena) extracted from the video. The top-left video is the coords of the Euglena.” We can see that the Euglena were identified from the video even the illumination is non-uniform and the background is a bit messy.