There is a substantial amount of code in the repo that is unused by the current neat_ml workflow to perform image analysis. This code is from early stages of the project (ca. 2023) and constitutes the majority of main.py, image_analysis_main.py and lib.py as well as their associated tests.
There are trade-offs between the burden of maintaining the code and the potential usefulness of parts of that code for future development of the code-base. For example, the legacy code maintains separate implementations of opencv.SimpleBlobDetector, classifier ensembling, lime/shap feature importance, and data loading/handling functions, and is generally monolithic in nature due to early prototyping. Furthermore, we have already run into issues related to the maintainability of this code base (i.e. with the most recent release of scipy (1.17.0) as discussed in #17 (comment)) and much of it is replaced in the current workflow by fully tested, modular functions/code. However, there are some aspects of the "old" code that may be useful in the future such as generation of ternary plots for block co-polymer experiments.
While some code could easily be removed, careful consideration would need to be given to certain parts based on future directions of the project. Similar to the current workflow, those parts that are useful could be added in separate PR's and integrated into the current workflow as separate modules before purging their legacy versions. i.e. there's no reason to purge something like the ternary plotting code and then have to re-write that code in the future.
Unfortunately, this option requires continuing to maintain the legacy code base, either by debugging issues that arise, capping some dependency versions, or finding other work-arounds. That being said, it may be best to maintain that code for the time being, until a meeting has been had regarding the integration of block co-polymer data into the workflow, at which time the useful aspects of the legacy code can be added to the current workflow in the manner described above and the rest can be purged out.
There is a substantial amount of code in the repo that is unused by the current
neat_mlworkflow to perform image analysis. This code is from early stages of the project (ca. 2023) and constitutes the majority ofmain.py,image_analysis_main.pyandlib.pyas well as their associated tests.There are trade-offs between the burden of maintaining the code and the potential usefulness of parts of that code for future development of the code-base. For example, the legacy code maintains separate implementations of
opencv.SimpleBlobDetector, classifier ensembling,lime/shapfeature importance, and data loading/handling functions, and is generally monolithic in nature due to early prototyping. Furthermore, we have already run into issues related to the maintainability of this code base (i.e. with the most recent release ofscipy (1.17.0)as discussed in #17 (comment)) and much of it is replaced in the current workflow by fully tested, modular functions/code. However, there are some aspects of the "old" code that may be useful in the future such as generation of ternary plots for block co-polymer experiments.While some code could easily be removed, careful consideration would need to be given to certain parts based on future directions of the project. Similar to the current workflow, those parts that are useful could be added in separate PR's and integrated into the current workflow as separate modules before purging their legacy versions. i.e. there's no reason to purge something like the ternary plotting code and then have to re-write that code in the future.
Unfortunately, this option requires continuing to maintain the legacy code base, either by debugging issues that arise, capping some dependency versions, or finding other work-arounds. That being said, it may be best to maintain that code for the time being, until a meeting has been had regarding the integration of block co-polymer data into the workflow, at which time the useful aspects of the legacy code can be added to the current workflow in the manner described above and the rest can be purged out.