Team:Aachen/Notebook/Software/Measurarty
From 2014.igem.org
(→Segmentation) |
(→Achievements) |
||
Line 283: | Line 283: | ||
Measurarty is the image analysis logic behind our project. | Measurarty is the image analysis logic behind our project. | ||
- | It | + | It is comprised of simple constructs put together into a pipeline, that is clearly laid out, easily maintainable and - if needed - easily adaptable. |
For example, changing from green to red fluorescence, only means to change the ''createMask'' function to select another target area. | For example, changing from green to red fluorescence, only means to change the ''createMask'' function to select another target area. | ||
- | Overall the results look convincing. We have not yet performed a comparison to a manual delineation, however by eye | + | Overall the results look convincing. We have not yet performed a comparison to a manual delineation, however, by eye the results look promising and have a low error. |
- | Talking about computational complexity, the | + | Talking about computational complexity, the MATLAB code of course performs better than our own C++ implementation, which must be regarded as a proof-of-principle. |
- | Space-wise the code depends heavily on the image size $O( x \cdot y)$ (width $x$, height $y$, which also limits the number of edges in SRM between regions | + | Space-wise, the code depends heavily on the image size $O( x \cdot y)$ (width $x$, height $y$, which also limits the number of edges in SRM between regions, as each pixel is one region to start with. However, it cannot take less memory, as the image is stored in an uncompressed format. |
- | + | On the computational side, the thresholding, image conversion and gradient steps are linear in the number of pixels, and are thus in $O(x \cdot y)$. | |
- | Unfortunately the summation of the gradient for the smoothness index adds a heavy factor to it (k-neighbourhood for smoothness index). | + | Unfortunately, the summation of the gradient for the smoothness index adds a heavy factor to it (k-neighbourhood for smoothness index). |
- | Due to the merging step in our C++-SRM algorithm implementation our code | + | Due to the merging step in our C++-SRM algorithm implementation, our code has to do $O(x^2 \cdot y^2)$ comparisons, which then finally results in a runtime complexity of $O( x^2 \cdot y^2)$. |
*include image here | *include image here | ||
From the above figure it can also be seen that the detected amount of pathogenic-area correlates with time after induction. | From the above figure it can also be seen that the detected amount of pathogenic-area correlates with time after induction. | ||
- | The lag-phase can be explained first by the lag-phase of the cells, which first need to generate a response to the | + | The lag-phase can be explained first by the lag-phase of the cells, which first need to generate a response to the pathogen, and on the other hand, by too low fluorescence which is not detectable. |
- | The pixel | + | The pixel count also meets the expectation when looking at the sample files by eye. |
- | It can be concluded that the | + | It can be concluded that the ''Measurarty'' pipeline defines a robustly working chip-analysis algorithm which can detect pathogens from images supplied by WatsOn. |
- | Therefore this algorithm closes the gap between our biology, detection hardware and the user | + | Therefore, this algorithm closes the gap between our biology, detection hardware and the user who wants easy-to-interpret results. |
- | For future prospects it would be interesting to do a proper performance analysis on our code, to find hotspots and optimize the code. Many ''for''-loops leave plenty of room for vectorization and loop-unrolling. Parallelization, | + | For future prospects, it would be interesting to do a proper performance analysis on our code, to find hotspots and optimize the code. Many ''for''-loops leave plenty of room for vectorization and loop-unrolling. Parallelization, specifically with respect to embedded hardware such as the Raspberry Pi or Odroid U3, is limited to the extend that the overhead created would probably eat the improvements. |
{{Team:Aachen/BlockSeparator}} | {{Team:Aachen/BlockSeparator}} |
Revision as of 12:44, 17 October 2014
|
|
|
|
|
|
|