lassoan / SlicerMONAIAuto3DSeg

Extension for 3D Slicer for running MONAI Auto3DSeg models
MIT License
66 stars 10 forks source link

ENH: use input channel specific normalize_mode when using multiple inputs #34

Closed che85 closed 8 months ago

che85 commented 8 months ago

model's config is checked for extra_modalities (empty if only one input image was provided)

Works with single and multiple image input.

fixes https://github.com/lassoan/SlicerMONAIAuto3DSeg/issues/32

lassoan commented 8 months ago

I've tested these changes with the "Abdominal organs TS2 - quick (v2.0.0)" model. Execution time is increased from 1 minute (original) to 3 hours (with changes in this pull request).

Are these changes from the autorunner? The autorunner is bad: it performs computations in a way that results in unnecessarily large and complex computations and uses several times more memory than actually needed, which leads to 10-100x slower execution time on systems that don't have that much RAM. We cannot blindly copy code from the autorunner because it would make the extension unusable on most computers.

Could you try to make the minimum amount of changes that performs the normalizations efficiently?

che85 commented 8 months ago

No, nothing was taken from the autorunner. Let me investigate.

che85 commented 8 months ago

@lassoan I made some code changes. The main reason was probably that I moved the cropping after the resampling step. Please test again if you get a chance. Performance should now be back to what it was before.

lassoan commented 8 months ago

Thank you! You can have a look at the commits around Feb 22, they made a huge performance difference.

For example, it matters if you perform costly processing operations before or after resampling. Something that has negligible computation time on GPU may require significant time on CPU. If you use double instead of float type and therefore increase the memory usage from 7GB to 14GB, then on a system with 16GB RAM the computation will be 100x slower. If you allocate a huge buffer and try to perform an operation at once, it can be 10-100x slower than performing that operating on smaller data chunks if the big buffer does not fit in memory.

che85 commented 8 months ago

That makes sense. Let me know if there are any other changes needed. I can also squash the commits.

lassoan commented 8 months ago

Thank you, this works well!

I've merged changes from @diazandr3s that added image resampling if additional inputs have different size. This of course caused merge conflicts. It would be great if you could resolve the conflict, I would then do a quick test, and it should be ready to merge.

che85 commented 8 months ago

@lassoan I resolved the conflicts and cleaned up some code (unused imports, pep8 style).