pickcells-essentials issueshttps://framagit.org/pickcellslab/pickcells-essentials/-/issues2022-06-03T11:07:37Zhttps://framagit.org/pickcellslab/pickcells-essentials/-/issues/33FeatureComputerManager should read the data graph to determine the type assoc...2022-06-03T11:07:37ZGuillaume BlinFeatureComputerManager should read the data graph to determine the type associated to a SegmentationResultThere is a problem currently in the way FeatureComputerManager (FCM) recognises the type of object which is associated with a given SegmentationResult object:
At the moment FCM creates a property 'Associated Objects' which corresponds ...There is a problem currently in the way FeatureComputerManager (FCM) recognises the type of object which is associated with a given SegmentationResult object:
At the moment FCM creates a property 'Associated Objects' which corresponds to the declaredType() of the SegmentedObject that it creates for a given SegmentationResult. The problem is that when the user wishes to go back and recompute features, the user will delete the data objects, but the 'Associated Objects' property in SegmentationResult will remain and FCM will not allow the user to create new objects again.
Deleting the 'Associated Objects' property as a workaround is fine if there is only one type of SegmentationResult. If there are several, then the property is also deleted in the SegmentationResults which are not concerned by the change, so this leads to quite a few issues.
While there is a [trigger system planned](foundationj#5) for dealing with this type of problem, an alternative could be to make FCM check whether the SegmentedResults of a given 'Segmentation Type' are actually connected to SegmentedObjects.
To make the method available for all consumers of SegmentationResults, a static method in UsefulQueries (in API) could be created.Guillaume BlinGuillaume Blinhttps://framagit.org/pickcellslab/pickcells-essentials/-/issues/28Record / Track analysis steps2018-08-03T15:44:43ZGuillaume BlinRecord / Track analysis stepsOne feature which would be novel and useful to users is the automated recording of the steps and parameter values used for the analysis of an experiment. This would bring several important advantages:
* First it would keep track of all...One feature which would be novel and useful to users is the automated recording of the steps and parameter values used for the analysis of an experiment. This would bring several important advantages:
* First it would keep track of all parameter values used in one experiment, playing the role of a sort of notebook
* And second, it would allow to import an analysis pipeline from a preexisting experiment (template). Advantages of this include:
* Not having to repeat the same tasks over and over again for each replicate experiment. This is even more important that some tasks can be a bit error prone / tedious such as filters and attribute creation.
* Enabling the standardisation of specific procedures and higher throughput. One performs an analysis once, validates it and adds it to some sort of shared library that other members of the lab can access.
Of course, this has to be very well thought through:
* For tracking:
* Any module writing to the database should be forced to declare its input parameter values.
* Module versions should be checked to ensure compatibility
* For Reproducing the pipeline:
* Some steps in the pipeline might require user intervention, such as segmentation or track editing, so once imported and run on a new experiment, the pipeline will have to pause at these steps and resume upon user validation.
* In case of error occuring during the run, there should be a form of roll back to the latest step which completed without error. Although this roll back procedure in case of error should probably be enforced for every module.
**NB:** Feature request taken from [this post](https://colony.pickcellslab.org/t/auto-generated-pipelines/27) in the forum