Feedback on 4-16-14 visualization

[lukeb546]

cell 1: (left-most cell in stack)

• boutons too far away: 8, 14, 21, 29, 30, 47, 56, 96, 115

• 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 ... ...

• boutons 55, 64, 65 (z-plane 20) = refer to .ojj to see how this was marked in mine; i think the thresholding may be too aggressive, yielding 3 distinct structures to be identified, while I probably only marked it as 1 or 2
• boutons 81 + 92 (z-plane 24) = same thing as above likely going on here; nearby bouton #76 is probably legit, but #81/92 is false distinction
• boutons 82 + 83 (z-plane 230) = same as above, false distinction
• large bouton on z-plane 27, at X 175 and Y 400 of visualization is not masked; the red cell dims in this area and starts to pull away a couple of z-planes later, but this bouton definitely contacts the cell body
• same for some other boutons, likely for the same reason: (1) z19, X 300 + Y460; (2) z24, X 295 + Y 440

second cell ("middle" cell in stack, exists from z13-52):

• boutons too far away: 41, 45, 66, 111, 130, 137, 143, 144, 193, 194
• some of the high density areas, with lots of overlapping numbers (rough ranges to follow), may be problematic for the same aggressive thresholding reason above; refer to .ojj ground truth to see what's going on, probably are some false distinctions: boutons numbered in the 40s, along with some 50s, centered around z-plane 16-20 the above is an example; i think this may be happening at several other places in later z-planes

third cell (right-most in stack, exists from z35-end)

• several boutons, such as # 197, 212, 217, 224, 228, seem to be ID'ed because of proximity to the nearby blue cell that exists to their northwest
• boutons that are inside the cell that should be rejected: 207, 241, 253, 269, 278, 305, 308, 312, 338
• anywhere the numbers flash rapidly when you scroll through, indicating that the boutons only exist on 1 z-plane, may be problematic due to the too aggressive thresholding problem that I describe above; this cell is very densely innervated, but I think that there must be too many boutons ID'ed here; check the .ojj ground truth to see what may be doing on

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

[lukeb546]

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.

[lukeb546]

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.

[lukeb546]

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.

[jsniff]

@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.

[jsniff]

@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?

[lukeb546]

Yes, I think keeping boutons that appear inside the edges of the cell for the first ~5 z-planes or so will work okay.

[jsniff]

17 is missed. 19 and 21 seem double-marked

[jsniff]

42, 44, 10 and 25

[jsniff]

Maybe some double counting

[jsniff]

191,192, 160, 169. Maybe some double counting.