About configurations of the foundation models

[BearCleverProud]

Thanks for the fantastic repo!

I have a question regarding the configuration of the foundation models. Different foundation models are trained on different resolutions and magnification. How's your thoughts on a fair comparison: on the same resolution and magnification, or resolutions and magnifications that would result in optimal performance of each foundation model?

Also, if the two foundation models share the same resolution and magnification, would it be possible to use the same root dir, as the only differences lie in the feature extraction, and the segmentation and everything should be the same.

Thank you!

[guillaumejaume]

Thanks @BearCleverProud!

How's your thoughts on a fair comparison: on the same resolution and magnification, or resolutions and magnifications that would result in optimal performance of each foundation model?
==> I don't think there is a good or bad decisions here. As long as you're transparent with the experiments you do, it's all good. Pure performance is only one facet of the quality of a model. Others are also important: (1) robustness, (2) is it magnification-agnostic?, (3) is it modality-agnostic (eg IHC, special stains supported?)? (3) it is language-aligned?

Also, if the two foundation models share the same resolution and magnification, would it be possible to use the same root dir, as the only differences lie in the feature extraction, and the segmentation and everything should be the same.
==> Correct. Say you extract 10 different configurations, always set the same root. Everything will be handled automatically (eg has the segmentation been run? If yes, reuse them, Have these patches been extracted? If yes, reuse them).

Let us know how to improve your user experience.

[BearCleverProud]

Thanks for your quick response!

After using your fantastic tool, I indeed have some feedback, or actually more likely some design thoughts that you might be interested in.

1. CLAM, developed also by your lab, chose to use torch.save to save the files into .pt format. I was actually quite curious why trident chose to save the features of each patch into .h5 file? Are there any specific reasons behind that?

2. The logs and configs now are dispersed around the folders. Would it be possible to include a log/ folder to wherever the logs will be saved? Also, the folder structure could be possibly more hierarchically organized.

I can show an example here:
In xxxxxx/20x_512px_0px_overlap/ folder, there are: _config_coords.json, _config_feats_xxxx.json, _logs_coords.txt, _logs_feats_xxxx.json, patches/, visualization/, features_xxxx/

This can be organized into the following:
configs/_config_coords.json, _config_feats_xxxx.json
logs/_logs_coords.txt, _logs_feats_xxxx.json
features/features_xxxx/
patches/
visualization/

But overall, these are just minor improvements that originate from my writing habits. Trident is really a great tool which can improve the working efficiency of the whole community!

[guillaumejaume]

1. Why h5 is better than pt: (a) framework-independent with no dependency on pytorch and (b) easy to store metadata like patch size, slide level, etc, and (c) features and coords are stored in the same file, which is need for spatial-aware models like titan.

2. thanks for the input. I'll check it's worth cleaning this up.

Feel free to suggest additional features that you think could benefit the community.

[BearCleverProud]

Thank you very much for your response!