The code is fairly well commented, in particular one should review func_extraction_worker_w_rots_lmdb_parfor.m, which is where the actual DB transactions occur. It also helps when working with students to be able to review the final input to the DL classifier without having to visually examine the patches themselves.ģ. In general, since we’re extracting sub-samples from a mask, it’s nice to get a quick high level overview of what is being studied. They look something like this, where red pixels and green pixels represent locations of positive and negative patches which were extracted: This approach has some additional code which generates ”layout” files, which show where the patches were extracted from on the original image. Not a huge deal (one could re-compile the code allowing for modification), but it’s a nice benefit of this approach.Ģ. While this was acceptable before since we extracted all the patches ahead of time and “had no move to give”, the ability to add patches later on is now a reality since in Matlab we can specify to append to the database instead of overwriting. Will throw an error if the database already exists.
Caffe’s convert_imageset tool is a one shot deal in the sense that it doesn’t allow for the addition to the database after its created, in particular the C++ line: Additionally, we can now create database of unlimited size, since we’re writing them directly to disk (which is also greatly sped up through the usage of transactions and caching in the LMDB layer).
#Matlab caffe install how to
Besides this, the remainder of the approach (i.e., how to select patches, etc) remains the same. In this case, we use not only matcaffe, which is provided by caffe making it straight forward, but also the caffe-extention branch of the matlab-lmdb project which provides a linux only wrapper for matlab to lmdb. Clearly a more optimized approach, but required additional code and dependencies. In this way, it is also only manipulated a single time.
#Matlab caffe install Patch
Thus, in this implementation, we’re never required to pull the patch from disk, its created in memory, used for all purposes, and then written to disk. In the revised approach shown above, we can see that now we use Matlab to both extract the patches, immediately place them into the database, as well as compute the a mean in line with the patch generation process. We were using a ramdisk to hold the patches before converting them to a database because pulling them from disk was incredibly slow, so either we were (a) limited to the size of the ram of the machine or (b) had to accept that time penalty for using the disk.
Additionally, this had another implicit constraint.
Clearly this wasn’t optimal, but at the time it was the most straight forward way as it limited the dependencies and leveraged tools which were already written. Overall, we can see that this essentially requires manipulating each patch 3 separate times, the first time to generate, the second time to place it in the DB, and the third time to add its contribution to the overall mean. Subsequently, the tools provided by caffe were used to (a) put the patches into a database and then (b) compute the mean of the entire database. As shown in the figure above, in that approach, Matlab solely extracted the patches and determined which fold of the evaluation scheme the belonged. Please refer to the blog post which provides a tutorial of how the nuclei segmentation was performed in the previous version. In this blog post, I re-address the nuclei segmentation use case using the latest and greatest approaches. Since then, many improvements have been made both in the field and in my implementation of them. Our publication “ Deep learning for digital pathology image analysis: A comprehensive tutorial with selected use cases”, showed how to use deep learning to address many common digital pathology tasks.