User:Brian P. Josey/Notebook/2010/08/04: Difference between revisions
| Line 22: | Line 22: | ||
# track multiple highly distinguishable particle between two instances in time, then multiple instances | # track multiple highly distinguishable particle between two instances in time, then multiple instances | ||
# add various differential cases, like disappearing and newly appearing droplets, one that disappears for an instant, similar droplets close to each other... | # add various differential cases, like disappearing and newly appearing droplets, one that disappears for an instant, similar droplets close to each other... | ||
==LabVIEW Notes== | |||
I am reading through a self-guided manual from National Instruments that covers a large portion of the details concerning LabVIEW that I am interested in, and I am going to write up my notes from it here so that I have a consistent place to hold on to them. The manual also has a series of exercises to reinforce the information presented, that I am going to do, but will not write up, unless they are especially interesting or relevant to the tracking software. | |||
Wires have different colors depending on their properties: | |||
* '''Orange''' numeric, floating-point | |||
* '''Blue''' numeric, integer | |||
* '''Green''' Boolean logic | |||
* '''Pink''' string | |||
'''Dataflow''' A block diagram executes as soon as all of its inputs are available, and then supplies data to its outputs when it is available. This contrasts with text based program languages that execute in set way. For example, MATLAB starts execution at line 1, finishes and then drops down to line 2, and so on until it completes or hits an error. For convention, the program is set up with inputs on the left, and outputs on the right, which I assume is meant to imitate written English, but the code doesn't necessarily execute in that order. | |||
If the vi is not compilable, it is likely that there is a broken wire somewhere, or that there is a block that is not getting the necessary inputs into it. | |||
<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### --> | <!-- ##### DO NOT edit below this line unless you know what you are doing. ##### --> | ||
Revision as of 15:04, 4 August 2010
 Project name
|
<html><img src="/images/9/94/Report.png" border="0" /></html> Main project page <html><img src="/images/c/c3/Resultset_previous.png" border="0" /></html>Previous entry<html> </html>Next entry<html><img src="/images/5/5c/Resultset_next.png" border="0" /></html> |
Scoring Droplets and Building UpOn Monday, we were able to filter out and assign points to track to the images of the droplets captured on the microscope. To do this we filtered out the brightest points, and assumed that they were the center of the droplets, and drew circles around them that defined them as points of interest. Then for each image in the sequence, we were able to determine four points of data for each of these points: the x and y coordinate, radius and area. Of course, the area is simply a function of the radius. On Monday, I devised a simple way to track these points as they moved across the image over time. For each consecutive image, I assigned a score for each droplet, which was the change in position divided by the change in radius. The computer does this for all possible pairs of droplets in each image, and then selects the one with the minimum score as the most likely change in position. However, a problem does arise from the scheme. As I've seen before, this approach creates a pattern that shows the various points bouncing around in nonsensical pattern across the whole image. It appears that the program is unable to track the particles that appear and disappear, matches up incorrect particles, or selects one pair of dots out of each pair of images that has a minimum score and plots those unrelated movements. Regardless of the cause, it is not working as is. So my minor goal for the time being, is to find a way to match up these points of data between different sets of data. To do this, I think I will first create a simple dummy program. My dummy program will contain a set of data that includes the x and y coordinates of some points, and their radii, and hopefully track these faked-up points of data. I will assign the score the same way I am doing in the image, and try to minimize it as it changes over time, at first just two instances, and produces a display showing their tracks. Assuming this is successful, I will then add other tests to it. Things I would want to be able to account for would include: disappearing points, new points that appear halfway through, points leaving the screen, similar points near each other, points that completely change their direction, and points that cross paths. I could see this taking a long time, even the rest of the summer before my trip, but if I can work it out, it will be a very major move forward, and I can easily adapt it to the tracking software Larry and I are building. It also has the added benefit of teaching me the basics of LabVIEW at a more controlled speed. A basic outline of my approach in note form:
LabVIEW NotesI am reading through a self-guided manual from National Instruments that covers a large portion of the details concerning LabVIEW that I am interested in, and I am going to write up my notes from it here so that I have a consistent place to hold on to them. The manual also has a series of exercises to reinforce the information presented, that I am going to do, but will not write up, unless they are especially interesting or relevant to the tracking software. Wires have different colors depending on their properties:
Dataflow A block diagram executes as soon as all of its inputs are available, and then supplies data to its outputs when it is available. This contrasts with text based program languages that execute in set way. For example, MATLAB starts execution at line 1, finishes and then drops down to line 2, and so on until it completes or hits an error. For convention, the program is set up with inputs on the left, and outputs on the right, which I assume is meant to imitate written English, but the code doesn't necessarily execute in that order. If the vi is not compilable, it is likely that there is a broken wire somewhere, or that there is a block that is not getting the necessary inputs into it. | |
