I’m just getting my feet wet with Cell Profiler, but it’s been pretty neat so far. I’ve got a couple of modules so far. They’re very hackish. There’s no error checking whatsoever. And I’m not sure how generally useful they are, but I definitely felt like it would be useful for my particular workflow. If possible, I’d love to get some feedback on them in terms of how to make them more efficient or how to think more in line with the other development efforts.
- IdentifyCOISubregion.m (7.97 KB) - finds the center of intensity of each subregion you input, inherits the parent’s parents
- IdentifySecondaryBorderCleanObjects.m (7.54 KB) - excludes secondary objects that lie on the border of an image. Goes back and excludes the primary object as well. Also, inherits the parent’s parents
- RelateByOverlay.m (5.85 KB) - does the relate function except just by straight overlay (so not intelligently), but works in cases where you don’t want too much intelligence when employing relate (primary grouped two disperate objects that are close to each other in to a single object but it spans two containing objects or something like that)
General questions on design
- Is there a CPInherit function or something like that, that goes back and finds all the parents of the parent object and applies them to the child object? Is that necessary to do? Is it necessary to keep track of the number of child objects (will downstream modules look for this)?
- When are Parent and Child information looked at? Do the Calculate Math and Calculate Ratios programs look for things like that and use them intelligently?
- Was it even necessary to develop an IdentifySecondaryBorderCleanObjects module? I’ve looked around to try to find a better way, but it seemed like it could be something wanted.
- Not really a question, but that was fun.
- What next?
All right, well I think that about covers it for now. Just wanted to post up some development and say hello to everyone.
P.S. - Anyone at Stanford making modules?