Open lukeb546 opened 10 years ago
looks like the only way i can get emails about new issues that i didn't create is for you to mention me, like @mention ... so probably @lukeb546 not sure if there are any other options on your end.
I'm putting some different versions of C2 in the following folder: Dropbox\Michele, George, Jacob, & Luke\Pre-processed The operations I did, and the order in which I did them, are documented in the filename, along with any values that were changed from the default, which are listed in order of the fields in the plugin window.
Some of the images have lots of single-pixel noise, but most of this is within the cell body and away from the boutons, so hopefully it's not a problem. Also, since it's mostly single-pixel noise, I think the algorithm already ignores this.
You might try running the bouton ID & counting part of the script on these images, to see if the different type of thresholding that I used makes a difference.
the thresholding step is still the make-or-break it step at the end. even after all of the processing and massaging, the thresholding value used still determines whether or not boutons are lost (if the value is too high) or whether they are joined together when they shouldn't be and connected by bridges of axon (if the thresholding value is too low). the auto local threshold may be a way around this, but it still seems temperamental. i think going with a lower threshold value, so that nothing is lost, and then trying to implement some sort of erosion -> dilation or similar strategy could be useful.
i don't know how successful what i tried today will be, but i think it's worth taking a look.
@lukeb546 boutons that are inside the cell that should be rejected: 207, 241, 253, 269, 278, 305, 308, 312, 338
I've coded an initial version of this and will deploy it soon.
@lukeb546 What about pole boutons (when cell comes in vision and outside vision). It seems like you kept early boutons in Cell 1...Should this be the same for other cells?
Yes, I think keeping boutons that appear inside the edges of the cell for the first ~5 z-planes or so will work okay.
17 is missed. 19 and 21 seem double-marked
42, 44, 10 and 25
Maybe some double counting
191,192, 160, 169. Maybe some double counting.
cell 1: (left-most cell in stack)
32 - this is just past the tip of the cell body and look to be on a dendrite; switching the gray cell-based approach should get rid of these; also potentially affected are #22, 23 24, refer to .ojj ground truth to check
27 = legit bouton; it is one that appears on the upper surface of the cell as we move down through the stack; if we move to rejecting anything inside the cell body outline that is not within the first X number (i.e., 5) of sections, this would get rejected and that would be unwanted; so, we will have to think about how best to do this...; perhaps, for each XY location, keep track of whether or not there is an outline in an adjacent z-plane; so, for example, bouton 27 first appears on z-plane 12, and the XY location that bouton 27 occupies is only included within the cell body outline starting on z-plane 11, so it is within the first 5 planes for that XY location, so the bouton is valid ... ...
second cell ("middle" cell in stack, exists from z13-52):
third cell (right-most in stack, exists from z35-end)
i think it may be worth going back to try a different thresholding scheme as a pre-processing step, and then feeding those images into the matlab script, commenting out the thresholding that you have implemented temporarily, for comparison. that auto local threshold function that we talked about long ago may be better at not breaking up the axon + boutons into so many small pieces, which get treated as unique by the algorithm. i can also play around with this and send you an auto local thresholded stack to play around with