top of page

The Clock is Ticking(+)

"Time is what we want most, but what we use worst."

-William Penn

For the past week or so, a fraction of a second has determined the difference between satisfaction and dissatisfaction at my third space. You see, I've been trying to force Matlab (the programming language I'm using) into smoothly displaying images from a live camera at a rate of 30 frames per second(a frame being a single image from the video). In other words, I've been trying to make Matlab do something that it really, really does not want to do. I'm sort of like a parent screaming at their kid to eat their dried prunes. From experience, I can tell you that dried prunes are not a delightful experience. In any case, here's the situation. The method I was originally using to display an image on the GUI was to call a function imshow() (A function is a block of code that performs some action). Now, imshow is ridiculously unoptimized for what I need, which is lightning fast image display. Matlab's native imshow() function takes about .15 seconds to display a color image made up of decimal numbers. This means that the frame rate is about 6 FPS, which is extremely laggy and looks terrible. I need to speed it up by 5 times in order to give the application a reasonable frame rate of about 30 FPS. So what can I do?

1.) All the operations are currently being performed on the central processing unit. However, there's another computational component to most computers called the GPU. Simply put, it's the CPU's dumb cousin, because it can only carry out a very small amount of operations. However, this dumb cousin also happens to be an olympic level track athlete, so this cousin is very fast. Basically, a good strategy is to hand the GPU a ton of data that only needs to have a simple operation carried out on it because the GPU can operate on all of the data at the same time(generally). This speeds the image display up, sometimes halving the time required or more. Everything I've just stated about the GPU is a gross oversimplification though.

2.) The imshow() function is horrible. If I can bypass that function, I'll speed everything up. By allocating one memory location to store all of the image data, and not deallocating it and reallocating it over and over again, I save a lot of time. So I actually keep the variable in use, and just change the information it stores. I set it with the image's information, not the image itself. Specifically, I set the CData attribute of the image.

3.) The current datatype that makes up the image is a number with many decimal places (a double, technically). However, this datatype is expensive to operate on. To speed operating with the numbers, I convert the numbers into plain integers, using the GPU method I detailed above. They take less time to operate on

4.) I set a few other properties of the image viewer to speed the actual display up, but they provide negligible changes.

So the upshot of all this is, after my quick optimizations, I reduced the time to display a single image from around .15 seconds to around .037 seconds. So I sped it up significantly, but not quite enough. To make matters worse, in live stream, I also need to retrieve the image data from the camera itself, which takes about .035 seconds. So after everything, I only halved the time it takes to display an image (it takes about .07 seconds). This was quite disappointing for me, as I had hoped to go around 30 FPS, and I can only go around, at the fastest, 10 FPS, as far as I know. However, after asking a couple of graduate students whether 10 FPS is good enough for them, it would appear that they are completely okay with viewing things at around 10 FPS. So my mission to livestream useful analytics data using computer vision under a microscope is almost complete. My code is still quite sloppy, and it will take around 2 weeks I think to iron out the bugs and code other important features. After this, I would love to pivot to more electronics work, since I am working at a MEMS lab after all. This is all part of a larger shift on my part to gain a working knowledge of electronics so that I can implement them in my own projects successfully. The key to this, however, is my timeframe. It’s important that I gain the knowledge so I can quickly begin to implement it in my other projects. I’ve been reading more research papers all related to UAVs that I will eventually implement down the line.

On Monday, Daniel, Hani, Joey and I all got together and planned out the next phase of the microscope analysis. After confirming that 10 FPS was enough, Joey pointed me towards developing a more modular approach to the application so that it is much easier to maintain and update when I am gone. It was an extremely good suggestion, and I'll use my time mostly towards that end.

I also asked them about pointers on using PCB/schematic design software, and on acquiring batteries or supercapacitors for testing and use in a variety of projects I'd like to do. It's all very exciting!

On a more macroscopic level, I continue to be pressed for time in everything I do, and so the clock is always ticking inside my head, pushing me to go faster. It seems to me that I'm ricocheting between tasks wildly. Whether this broad spectrum of activities is detrimental or beneficial, I'm not sure, since I've heard it argued both ways. I'll have to wait and see. I think I need to re-discipline myself in order to squeeze a little bit more time into accomplishing my objectives. But from a general standpoint, I think that my aims to work harder and faster are universal in their simplicity and attractiveness. Everyone is trying to run their lives a little bit faster against the clock. It seems that pressures can be internal or external. In my case, my outcomes rest on my decisions now. There is something beautiful about that.

bottom of page