enhance-pet / moose Goto Github PK

The volume of an organ also is an important biomarker. It will make a lot of sense to extract the volumes if CT images are provided. Make sure the calculation of the volume is done on the original CT volume to avoid errors arising from the large voxel sizes of the PET images. Also, the volume stats should be written in a separate 'volume-stats.csv' file.

Describe the bug

In MOOSE, we have identified an issue with Dicom to Nifti conversion using the dicom2nifti package. The issue is that dicom2nifti.convert_directory sometimes converts each Dicom slice into a new separate Nifti volume instead of combining them into a single volume. Note that this issue does not occur with every Dicom series but has been observed in a selected few.

To Reproduce

Steps to reproduce the behavior:

1. Run moosez on a set of Dicom images.
2. Observe that, for some Dicom series, multiple Nifti volumes are created for each Dicom slice instead of combining them into one.

Expected behavior

The expected behavior is that all the Dicom slices should be combined into a single Nifti volume for more coherent and straightforward analysis.

Screenshots

Not relevant.

Desktop (please complete the following information):

• OS: Windows 11
• Version: 2.2.35 (latest)
• Python Version: 3.9.2+

Additional context

1. The issue is specific to the moosez tool in our MOOSE repository.
2. Previously, we were using dicom_series_to_nifti from the dicom2nifti package, but it also had its set of issues.
3. Considering these recurrent problems, it might be beneficial to switch to using dcm2niix for more robust and reliable conversion, especially since our lionz package is already successfully using it.
4. This issue is critical when collaborating with medical partners like Hermes Medical Solutions, where data integrity and consistency are essential.
5. While this problem doesn't happen with every Dicom series, it is still an issue that compromises the robustness of our conversion process and needs addressing.

Is your feature request related to a problem? Please describe.
If the environment variables are not loaded, MOOSE fails silently like so:

✔ Converted DICOM images in /home/user/Data/... to NIFTI
- Only CT data found in folder /home/user/Data/..., MOOSE will construct noncerebral tissue atlas (n=37) based on CT 
- Initiating CT segmentation protocols
- CT image to be segmented: /home/user/Data/...._0000\.nii\.gz                            
✔ Segmented abdominal organs from /home/user/Data/..._0000.nii.gz                                     
Traceback (most recent call last):                                                                                                                                                                                 
    File "/usr/local/bin/moose", line 131, in <module>
        ct_atlas = ie.segment_ct(ct_file[0], out_dir)                                                                                                                                                             
    File "/home/user/Code/MOOSE/src/inferenceEngine.py", line 78, in segment_ct                                                                                                                                        
        out_label = fop.get_files(out_dir, pathlib.Path(nifti_img).stem + '*')[0]                
IndexError: list index out of range

Describe the solution you'd like
It would be nice to let the user know that the problem is that the nnUNet_raw_data_base, nnUNet_preprocessed, etc. env variables are not set.

Vascular bundles of upper extremity and thoracic aperture (A. subclavia/V. subclavia) often classified as skeletal muscles. Might lead to overestimation of SUV Values.
Not all instances recorded since it appears to be a general pattern

MOOSE currently segments all the 120 tissues and there is a very high chance that the users often just want a portion of it. I think it would make sense if the user can select which tissue compartment they are interested in segmenting. E.g. passing the compartment as input arguments.
Possible usage:

• To segment abdominal organs:
  moose -f /path/to/main/dir -t organs
• To segment bones:
  moose -f /path/to/main/dir -t bones

@LalithShiyam will implement the prototype
@Keyn34 suggests improvements and testing for now.

The following error occurred after using Moose with dynamic datasets of Vision lung cancer patients. All other segmentations and SUV extraction properly worked. No error occurred after re-running Moose with the corresponding static dataset.

Brain found in field-of-view of PET/CT data...                         
- Cropping brain from PET image using the aligned CT brain mask
Traceback (most recent call last):
  File "/usr/local/bin/moose", line 215, in <module>
    cropped_pet_brain = iop.crop_image_using_mask(image_to_crop=pet_file[0],
  File "/home/mz/Documents/Softwares/MOOSE/src/imageOp.py", line 237, in crop_image_using_mask
    out_of_bounds = upper_bounds >= img_dim
ValueError: operands could not be broadcast together with shapes (3,) (4,)

Problem

Inference is a tad bit slow when it comes to large datasets.

Solution
Performance gains can be achieved by using Intel's Neural Compressor: https://github.com/intel/neural-compressor/tree/master/examples/pytorch/image_recognition/3d-unet/quantization/ptq/eager. And Intel has already provided an example on how to do so. So we just need to implement this for getting a lean model (still need to check the performance gains)

*Alternate solution

Is to bring in a fast resampling function (torch or others...)

In case of mucosal congestion in the nasal cavity and paranasal sinuses -> missclassification as skeletal muscles.
This appears often but I think the effects are minor, hence MINOR bug.
All instances recorded

Right now MOOSE breaks when there is no brain in the PET image. The elegant way would be to figure out if there is a brain in the FOV of PET and initiate the segmentation protocols accordingly. It seems to be quite hard to determine if a given image has a brain in the field of view with hand-engineered features. The smartest way would be to generate a MIP or the middle slice of the PET image (if given) and use a 2D CNN based binary classifier for figuring if the brain is in the FOV or not.

The game plan is the following:

• Extract the middle slice (coronal plane)

• Convert it from DICOM to .png and transform the PET intensities between 0-255 (Graylevels)

• Curate 80 slices (50 PET with no brain, 50 PET with a brain) and perform the training.

• Implement a 2D CNN binary-classifier (PyTorch <3 fastai)

• Make sure the data augmentations of the 2D CNN have random cropping

• Then use the trained model to infer whether a given volume has a brain or not.

MOOSE fails when presented with a dynamic PET in the latest version. It works as expected with static 3D images.

MOOSE probably doesn't need to do anything special with the 4D dynamic images, but it should probably still produce the segmented CT output. Additionally, it would be great to have a registration between the CT and the final frame of the PET. Motion correction of the PET could then be performed with FALCON, and mapped back to the CT.

Problem
MOOSE is based on nnUNet and the current inference takes a lot of memory on total-body datasets (uEXPLORER/QUADRA, upper limit: 256 GB). This is not a normal memory usage for most of the users. The memory usage bottleneck is explained here: MIC-DKFZ/nnUNet#896

Solution
The solution seems to be to find a 'faster/memory efficient' resampling scheme than the skimage resampling scheme. People have already suggested solutions for speed, based on https://pytorch.org/docs/stable/generated/torch.nn.functional.interpolate.html and an elaborate description can be found here: MIC-DKFZ/nnUNet#1093.

But the memory consumption is still a problem. @dhaberl @Keyn34 : Consider these alternative options of Nvidia's cuCIM cucim.skimage.transform.resize in combination with Dask for block processing (chunks consume way less memory and I have used this for kinetic modelling).

Impact
This would result in a faster inference time and hopefully also obviates memory bottleneck for MOOSE and for any model inference via nnUNet.

Fluid dense tissue surrounding the bladder often delineated as bladder while bladder delineation often only partial, probably hard to fix due to many instances of gravity dependend ascites in malignancies and cervical cancers as cohort.
All instances recorded

Thanks for providing version 2 of your fantastic tool MOOSE!

When following your installation instructions and finally starting moose via:

moosez -h

I received the following error:

Traceback (most recent call last):
  File "/home/[...]/MOOSE2.0/moose-env/bin/moosez", line 5, in <module>
    from moosez.moosez import main
  File "/home/[...]/MOOSE2.0/moose-env/lib/python3.9/site-packages/moosez/__init__.py", line 7, in <module>
    from . import moosez
  File "/home/[...]/MOOSE2.0/moose-env/lib/python3.9/site-packages/moosez/moosez.py", line 36, in <module>
    from moosez import image_processing
  File "/home/[...]/MOOSE2.0/moose-env/lib/python3.9/site-packages/moosez/image_processing.py", line 32, in <module>
    import cv2
  File "/home/[...]/MOOSE2.0/moose-env/lib/python3.9/site-packages/cv2/__init__.py", line 181, in <module>
    bootstrap()
  File "/home/[...]/MOOSE2.0/moose-env/lib/python3.9/site-packages/cv2/__init__.py", line 153, in bootstrap
    native_module = importlib.import_module("cv2")
  File "/software/all/Anaconda3/2021.11/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ImportError: libGL.so.1: cannot open shared object file: No such file or directory

I am working remotely via SSH on a supercomuting cluster. I believe the error is generated via the opencv-python which installs GUI functionality.

I could fix the error by installing:
pip install opencv-python-headless

opencv-python-headless is a version of opencv-python that doesn't include the GUI features, so it also doesn't depend on the graphics libraries. It seems to be a good solution for setups that don't have a full graphical environment.

First of all I would like to congratulate you for the amazing tool provided. I have been using v0.1 and now v2.0 and the improvements in usability and efficiency are very noticeable.

For my usage, I am mainly interested in the bone segmentation over CT images, specifically on spine segmentation. In previous version released v0.1, there is an output segmentation label for all bones (with internal labels) that was ideal for my purpose. Now in v2.0, there are two modes that work for bones which are "clin_ct_peripheral_bones", which does not include spine, and "clin_ct_vertebrae", that tries to segment every vertebrae separately. I tried the second model, the segmentations are very precised but several of the upper vertebae are not detected nor segmented, which is a major problem for my usage.

Is there any chance that you may include previous spine/bones segmentation model in v2.0?

Thanks a lot for your incredible work.

Hi,
I am reaching out to inquire about the possibility of sharing the training data used for the MOOSE project on GitHub. I believe that access to this data would greatly benefit the development community by enabling us to train even better models and further enhance their accuracy.

The MOOSE project has garnered significant attention and has proven to be an invaluable resource for various tasks. I am impressed by the capabilities of the models developed by your team. However, I believe that by sharing the training data, the QIMP Team can unlock even greater potential for innovation and advancement in the field.

Having access to the training data would allow developers to experiment with different techniques, fine-tune models for specific use cases, and potentially discover new insights. This would not only enhance the accuracy of the existing models but also facilitate the creation of new models tailored to specific domains or languages.

I understand that there might be challenges associated with sharing training data, such as privacy concerns or intellectual property considerations. However, I believe that by implementing appropriate safeguards and anonymizing the data, these challenges can be overcome while still maintaining the integrity of the models.

In conclusion, I kindly request that the QIMP Team considers the possibility of sharing the training data for the MOOSE project on GitHub. Doing so would empower developers to train better models, leading to improved accuracy and ultimately benefiting the entire development community.

Thank you for considering this request. I appreciate your time and look forward to hearing your thoughts on this matter.

Description
A potential error where moosez/torch cannot detect cuda. This happened twice, once on Windows and once on Ubuntu.

To Reproduce
Steps to reproduce the behaviour:

1. Create a virtual environment for moosez
2. pip install the latest or specified moose version
3. Prepare a dataset according to the moosez folder structure and run moosez on it
4. If moosez/torch has trouble finding the correct cuda version, the error/warning will be displayed as below.

Expected behaviour
moosez/torch recognizes the correct cuda version and determines the GPU as the prediction accelerator.

Screenshots
This might be the error/warning. The prediction will run on the CPU afterwards.

System information:

• OS: Windows and Ubuntu
• moosez Version: encountered at 2.2.8, but might be version independent.

Fix
The fix for both was to reinstall torch with the corresponding command from https://pytorch.org/get-started/locally/

Discussed in #71

Adrenals often only partially delineated. Aprox. 50% of cases. Not all instances recorded

Analysis request for prostate cancer cohort as follows:

• MOOSE cohort -> Validation of Segmentations by me
  • Extract PET-Parameters from MOOSEd Segments
• [x ] Delete all hand drawn PET-Segmentations starting with cubic*
• Merge all the remaining Segmentations (pb*, sv*, pln*...) on a patient level by the following convention:
  • all Segmentations to a Master_VOI -> extract PET-Parameters (SUVmax, mean... + Metabolic Tumor volume)
  • VOIs named: pb* + sv* -> Prostate_Sum_VOI -> extract PET-Parameters (SUVmax, mean... + Metabolic Tumor volume)
  • VOIs named: dln* + pln* + rln* -> Lymph_node_Sum_VOI -> extract PET-Parameters (SUVmax, mean... + Metabolic Tumor volume)
  • VOIs named: bone* -> Bone_Sum_VOI -> extract PET-Parameters (SUVmax, mean... + Metabolic Tumor volume)
  • VOIs named: adrenal* + liver* + pleura* + lung* + rectum* + skin* + peritoneal* + org* + organ* + psoas* + testis* + lung* + cavern* -> Organ_Sum_VOI -> extract PET-Parameters (SUVmax, mean... + Metabolic Tumor volume)

Hi,

I am trying to run MOOSE on a bunch of patients with whole-body CTs. For two of the patient, MOOSE fails with the following error

✔ Segmented psoas from /home/user/Data/....IMA_0000.nii.gz                                              
- Conducting automatic error analysis in similarity space for: /home/user/Data/.../labels/MOOSE-Non-cerebral-tissues-CT-....nii.gz
Traceback (most recent call last):
  File "/usr/local/bin/moose", line 139, in <module>                                                                                                                                                        
    ea.similarity_space(ct_atlas, sim_space_dir, segmentation_error_stats)                                                                                                                                         
  File "/home/user/Code/MOOSE/src/errorAnalysis.py", line 147, in similarity_space
    shape_parameters = iop.get_shape_parameters(split_atlas)
  File "/home/user/Code/MOOSE/src/imageOp.py", line 86, in get_shape_parameters
    label_img = SimpleITK.Cast(SimpleITK.ReadImage(label_image), SimpleITK.sitkInt32)
  File "/home/user/miniconda3/envs/moose/lib/python3.9/site-packages/SimpleITK/extra.py", line 346, in ReadImage
    return reader.Execute()
  File "/home/user/miniconda3/envs/moose/lib/python3.9/site-packages/SimpleITK/SimpleITK.py", line 8015, in Execute
    return _SimpleITK.ImageFileReader_Execute(self)
RuntimeError: Exception thrown in SimpleITK ImageFileReader_Execute: /tmp/SimpleITK/Code/IO/src/sitkImageReaderBase.cxx:97:
sitk::ERROR: The file "/home/user/Data/.../labels/sim_space/similarity-space/MOOSE-Split-unified-PET-CT-atlas.nii.gz" does not exist.

Do you know what could be the problem if the file not existing? It works for the other patients.

Describe the bug
When we try to install moosez in a python3.9 environment (as mentioned in ReadMe). The installation works fine but when we try to run moosez via moosez -h, we encounter issues as dask[distributed] mandates python 3.9.2 or above, please refer the known error here: dask/distributed#7956.

To Reproduce
Steps to reproduce the behavior:

1. Create moose-env as suggested in readme
2. pip install moosez
3. and type moosez -h
4. See error

Expected behavior
Please suggest users to use python 3.9.2 or above.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Ubuntu

(moose-env) E:\data>moosez -d ./input -m clin_ct_organs_v2

 __  _______  ____  ________  ___   ___ 
/  |/  / __ \/ __ \/ __/ __/ |_  | / _ \

/ /|/ / // / // /\ / / / __// // /
// //_/_/// /()_/
A part of the ENHANCE community. Join us at www.enhance.pet to build the future of PET imaging together.

� CITATION:

Shiyam Sundar LK, Yu J, Muzik O, et al. Fully-automated, semantic segmentation of whole-body 18F-FDG PET/CT images based on data-centric artificial intelligence. J Nucl Med. June 2022.
Copyright 2022, Quantitative Imaging and Medical Physics Team, Medical University of Vienna

� NOTE:

Imaging: Clinical | Modality: CT | Tissue of interest: Organs | nnUNet version: v2
Required modalities: ['CT'] | No. of modalities: 1 | Required prefix for non-DICOM files: ['CT_']
Warning: Subjects which don't have the required modalities [check file prefix] will be skipped.
CUDA not available on this device. Predictions will be run on CPU.

� MODEL DOWNLOAD:

A local instance of Dataset123_Organs has been detected.

� STANDARDIZING INPUT DATA TO NIFTI:

Processing subjects... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0% -:--:--
Standardization complete.
Number of moose compliant subjects: 0 out of 0

� PREDICT:

Traceback (most recent call last):
File "D:\anaconda3\envs\moose-env\lib\runpy.py", line 197, in _run_module_as_main
\ Initiating return _run_code(code, main_globals, None,
File "D:\anaconda3\envs\moose-env\lib\runpy.py", line 87, in run_code
exec(code, run_globals)
File "D:\anaconda3\envs\moose-env\Scripts\moosez.exe_main.py", line 7, in
File "C:\Users\DELL\AppData\Roaming\Python\Python39\site-packages\moosez\moosez.py", line 199, in main
time_per_dataset = total_elapsed_time / len(moose_compliant_subjects)
ZeroDivisionError: float division by zero

Hello,

would it be possible to skip a patient and process the next one in case of an error (e.g. empty CT dir) and not stop the process?

And then maybe in the end you get a list of the patient IDs that failed.

Dear MOOSE team,

I mentioned the following issue in another issue and wanted to create a new one for it:

I don't know if adding the env variables to `.bashrc` is the best place to do it. Some users might use zsh and others might use nnUnet seperately.  

Originally posted by @chris-clem in #42 (comment).

As a quick solution, I added a env_vars.sh file in the MOOSE repo dir that I source instead of .bashrc. In the meantime, I have searched how people are handling the problem in general and found the following possibilities:

1. Create a .env file in the repo dir and load it with python-dotenv as explained here.
2. Create a .env file in the repo dir and recommend users to use direnv, which then automatically loads the env variables when changing in the MOOSE dir.
3. Recommend users to create a MOOSE conda environment and enable loading and unloading the env vars when activating/ deactivating the conda environment as described here.

The downside of 1. is that it requires a new dependency, the downside of 2. that it requires a new program, and the downside of 3. is that it requires conda for managing the environment.

What do you think is the best option?

When MOOSE fails to infer the dataset, the command is stopped and the folders are left with temporary files given in this structure:

Newly created folders: CT, PT, labels, stats, temp and 2 .JSON files.

In order to clean these datasets and make them executable again, it would be nice to have a command to revert them into their original states. The command which can manually be used is listed here.

root@meta-zoo:/home/mz/Documents/Projects/"Work-Directory"/faulty# find -maxdepth 2 -name CT -exec rm -rf {} \;
root@meta-zoo:/home/mz/Documents/Projects/"Work-Directory"/faulty# find -maxdepth 2 -name PT -exec rm -rf {} \;
root@meta-zoo:/home/mz/Documents/Projects/"Work-Directory"/faulty# find -maxdepth 2 -name labels -exec rm -rf {} \;
root@meta-zoo:/home/mz/Documents/Projects/"Work-Directory"/faulty# find -maxdepth 2 -name temp -exec rm -rf {} \;
root@meta-zoo:/home/mz/Documents/Projects/"Work-Directory"/faulty# find -maxdepth 2 -name stats -exec rm -rf {} \;

I have followed your work for a while and Im a researcher in the similar filed. I just guess that if you use totalseg dataset to train the moose2 zoo. I just feel that the ribs and lung and some new categories suffer a low performance.

I am not sure if I send the wrong direction CT image. I seed the standard direction CT image as input (ct_itk.GetDirection()=(1,0,0,0,1,0,0,0,1) with 1.5 mm spacing). I use Moose2 to inference the low dose CT image, which is the data from 2016 low dose CT image challenge.

However, I just feel the performance is not as good as I expected since moose1 was trained in a supervised way.

In summary, I just want to mention that if you use the totalseg dataset to construct moose2, totalseg was a full dose CT dataset and there might be a domain gap.

Generally, MOOSE is a amazing tool. PS: i also has a question, if I want to compare with MOOSE in my research, should I compare with MOOSE1 or MOOSE2...

I am running MOOSE in a patient folder with two subfolders for CT and PET under DCIOM format. However, I am getting this error message:
✔ Segmented abdominal organs from /data/111111111/CT/1.2.156.112605.189250954672781.211222004834.3.9684.76929_0000.nii.gz
✔ Segmented Bones from /data/111111111/CT/1.2.156.112605.189250954672781.211222004834.3.9684.76929_0000.nii.gz
✔ Segmented skeletal muscle, subcutaneous and visceral fat from /data/111111111/CT/1.2.156.112605.189250954672781.211222004834.3.9684.76929_0000.nii.g z
✔ Segmented psoas from /data/111111111/CT/1.2.156.112605.189250954672781.211222004834.3.9684.76929_0000.nii.gz
Traceback (most recent call last):
File "/usr/local/bin/moose", line 140, in
ct_atlas = ie.segment_ct_3mm(ct_file[0], out_dir)
File "/MOOSE/src/inferenceEngine.py", line 427, in segment_ct_3mm
logging.info(f"Non-cerebral tissues segmented and saved in {fop.get_files(out_dir, 'MOOSECTnii.gz')[0]}")
IndexError: list index out of range

I debugged as follows but didn't get the results I should have. The function sum_image_stack() does not seem to work.：

from imageOp import sum_image_stack
sum_image_stack("/data/111111111/labels", "*nii.gz", "/data/111111111/labels/all.nii.gz")
Sum image stack!!!
current work path: /data/111111111/labels
wild_card: *nii.gz
out_img: /data/111111111/labels/all.nii.gz
list of current dir path: ['sim_space', 'plans.pkl', 'Organs_1.2.156.112605.189250954672781.211222005615.4.16884.16127.dcm.nii.gz', 'Bones_1.2.156.112605.189250954672781.211222005615.4.16884.16127.dcm.nii.gz', 'Fat-Muscle_1.2.156.112605.189250954672781.211222005615.4.16884.16127.dcm.nii.gz', 'Psoas_1.2.156.112605.189250954672781.211222005615.4.16884.16127.dcm.nii.gz']
cmd: c3d *nii.gz -accum -add -endaccum -o /data/111111111/labels/all.nii.gz
finish!

There are any suggestion？
Thanks.

Allow users to select the GPU to run moose. Makes a lot of sense if the user has a large server. Would be pivotal for multimoose.

• @LalithShiyam to develop the prototype
• @Keyn34 to test it

MOOSE fails with index error when trying to run on WSL, due to wrong installation. There is no moose-files folder created when the algorithm is installed.

Steps to reproduce the behavior:
Install through WSL as described in github.

Moose-files folder should be created when installed, and moose should run as required.

Screenshots of the errors:

Windows 11 22H2

Problem description:
In your MOOSE paper (DOI: 10.2967/jnumed.122.264063), it introduced that a model was trained to segment 83 brain subregions from PET data combined with T1-weighted MR images. However in this repository the only PET segmentation model provided is for tumors in FDG PET, and there is no sign of that cerebral region segmentation model.

Desired behavior:
The aforementioned model for segmenting 83 brain subregions is present.

Alternatives:
Or probably this model is already uploaded. Please point me to where it could be found.

Thank you very much for providing such a powerful image processing tool!

The values spewed by similarity space in the excel sheet are garbage. The values seem to be off by a ridiculous amount in comparison to the original MOOSE version present in the QIMP-Team repository. Need to see where the implementation went wrong in the current version.

@josefyu Please test if the similarity space csv files are actually producing the right results.

Nothing new I guess - not all instances recorded since it appears to be a general issue

Hi,
I have tried to use the package for bones segmentation and I have initially installed the latest release using pip.
Everything works fine, except for the vertebrae segmentation model, which fails with the error:

 File "Python310\Scripts\moosez-script.py", line 33, in <module>
    sys.exit(load_entry_point('moosez', 'console_scripts', 'moosez')())
  File "moosez\moosez.py", line 201, in main
    predict.predict(model_name, input_dir, output_dir, accelerator)
  File "moosez\predict.py", line 78, in predict
    postprocess(original_image_files[0], output_dir, model_name)
  File "moosez\predict.py", line 131, in postprocess
    predicted_image = file_utilities.get_files(output_dir, '.nii.gz')[0]
IndexError: list index out of range

Inspecting the code, the error was due to an un-catched error of the nnUNet_predict command, which fails with the following error:

$ nnUNet_predict -i .\moosez-clin_ct_bones_v1-2023-10-18-13-24-08\CT\temp -o .\moosez-clin_ct_bones_v1-2023-10-18-13-24-08\segmentations -t 111 -m 3d_fullres --fold all --disable_tta

RuntimeError: Could not find a task with the ID 111. Make sure the requested task ID exists and that nnU-Net knows where raw and preprocessed data are located (see Documentation - Installation). Here are your currently defined folders:
nnUNet_preprocessed=None
RESULTS_FOLDER=None
nnUNet_raw_data_base=None
If something is not right, adapt your environemnt variables.

According to the issue 63, I have tried also to downgrade the package version to 2.2.8, trying to use the old version of bone segmentation.
However, I get the same issues due to the ID 517 related to this database.

I'm currently working under Windows 10 OS.

Is there something I missed?
Thanks in advance

Describe the bug
moose_uninstaller.sh doesn't work as intended, because we are using unset which is not right. Better to use sed to detect the substring and remove the line.

To Reproduce
Steps to reproduce the behavior:
Basically run moose_uninstaller.sh and the variables won't be removed.

Expected behavior
When moose_uninstaller.sh is run, every environment variable should be removed.

Desktop (please complete the following information):

• OS: ubuntu
• Version 20.04.4

Currently MOOSE is running on server configuration. So there is a good chance that the user is using a DGX or so. In that case, it would make sense to fully utilise the capabilities of the hardware. Similar to falcon, moose should run in parallel based on the hardware capabilities.

I use the latest moosez version.

I have 2 computers, one is Dell 7960, with 512GB RAM, and 2 A6000 GPU, Ubuntu 20.4 LTS, in the terminal, moosez running properly,

but for another computer Dell 5820, with 256GB RAM, and 1 1080ti GPU, Ubuntu 22.04 LTS: the GPU is working fine for other program, but not for moosez, as shown in below, CUDA detection is OK, but problem occurs at postprocessing stage, it cannot find the segmentation nifty file, if I forcedly change the device to CPU, it works fine, I try to update the GPU driver to 545, still not work for gpu. any idea what the problem could be, thanks a lot.

############################################################################
CUDA is available on this device with 1 GPU(s). Predictions will be run on GPU.

🌐 MODEL DOWNLOAD:

A local instance of Dataset123_Organs has been detected.

🔍 STANDARDIZING INPUT DATA TO NIFTI:

Processing s1... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Standardization complete.
Number of moose compliant subjects: 1 out of 1

🔮 PREDICT:

⠦ [1/1] Preparing data for prediction for s1.../home/hyperion/PycharmProjects/moosedata/Falcon1/s1/moosez-clin_ct_organs-2023-10-31-21-28-59/CT
⠋ [1/1] Running prediction for s1 using clin_ct_organs...original_image_files[0] /home/hyperion/PycharmProjects/moosedata/Falcon1/s1/moosez-clin_ct_organs-2023-10-31-21-28-59/CT/CT_3_standard_375_0000.nii.gz
Traceback (most recent call last):
File "/home/hyperion/anaconda3/envs/moosez/bin/moosez", line 8, in
sys.exit(main())
File "/home/hyperion/anaconda3/envs/moosez/lib/python3.9/site-packages/moosez/moosez.py", line 201, in main
predict.predict(model_name, input_dir, output_dir, accelerator)
File "/home/hyperion/anaconda3/envs/moosez/lib/python3.9/site-packages/moosez/predict.py", line 80, in predict
postprocess(original_image_files[0], output_dir, model_name)
File "/home/hyperion/anaconda3/envs/moosez/lib/python3.9/site-packages/moosez/predict.py", line 133, in postprocess
predicted_image = file_utilities.get_files(output_dir, '.nii.gz')[0]
IndexError: list index out of range

Within the most recent version of MOOSE I cannot use the "clin_ct_body" prediction - even in cases, where prediction worked fine previously. Other models work fine (as usual).
MOOSE runs into the following error:

â ´ [1/1] Running prediction for *** using clin_ct_body...Traceback (most recent call last):
  File "/.../MOOSE2.0/moose-env/bin/moosez", line 8, in <module>
    sys.exit(main())
  File "/.../MOOSE2.0/moose-env/lib/python3.9/site-packages/moosez/moosez.py", line 198, in main
    predict.predict(model_name, input_dir, output_dir, accelerator)
  File "/.../MOOSE2.0/moose-env/lib/python3.9/site-packages/moosez/predict.py", line 78, in predict
    postprocess(original_image_files[0], output_dir, model_name)
  File "/.../MOOSE2.0/moose-env/lib/python3.9/site-packages/moosez/predict.py", line 131, in postprocess
    predicted_image = file_utilities.get_files(output_dir, '.nii.gz')[0]
IndexError: list index out of range

Does anyone else experience that error?

Need to manually start again:

Calculated SUV image for SUV extraction!

• Brain found in field-of-view of PET/CT data...
• Cropping brain from PET image using the aligned CT brain mask
  Traceback (most recent call last):
  File "/usr/local/bin/moose", line 214, in
  cropped_pet_brain = iop.crop_image_using_mask(image_to_crop=pet_file[0],
  File "/home/mz/Documents/Softwares/MOOSE-V.1.0/src/imageOp.py", line 228, in crop_image_using_mask
  bbox = np.asarray(label_shape_filter.GetBoundingBox(1))
  File "/usr/local/lib/python3.8/dist-packages/SimpleITK/SimpleITK.py", line 36183, in GetBoundingBox
  return _SimpleITK.LabelShapeStatisticsImageFilter_GetBoundingBox(self, label)
  RuntimeError: Exception thrown in SimpleITK LabelShapeStatisticsImageFilter_GetBoundingBox: /tmp/SimpleITK-build/ITK-prefix/include/ITK-5.2/itkLabelMap.hxx:151:
  ITK ERROR: LabelMap(0x9547bd0): No label object with label 1.

HU units of the CT can also serve as a biomarker. Therefore, it would make sense to extract the HU units - if the CT scans are provided. Include them in the separate ct-hu-values.csv file. All the stats files should go to a separate folder called 'stats'.

Issue
collection.sort() does not sort the files as expected when single-digit numbers are used in the filename (1, 10, 11,...,19, 2, 20....)

How to reproduce
The issue seems to be the naming convention of files regarding the numbering of single digits:
Using 1, 2, 3, ..., 9 within a filename causes unexpected sorting
Using 01, 02, 03, ..., 09 within a filename works fine

Proposed fix
Changing collection.sort() to usage of natsort package

Problem.
Since MOOSE is pretty much used in servers, it might be worthwhile to have a Docker Image for MOOSEv0.1.0.

Solution
Need to make one with the docker image hosted at IBM cloud.

Is your feature request related to a problem? Please describe.

I propose the addition of a new feature to MOOSE that would enable the calculation of volumes for each label in multilabel segmentations. Furthermore, this feature should include the capability to export these volume measurements into a CSV file. This functionality will significantly enhance MOOSE's utility in medical image analysis, particularly in studies where volume quantification is essential.

Describe the solution you'd like

1. Volume Calculation: Implement a function to calculate the volume of each segmented label in a 3D image. The volume calculation should account for the voxel dimensions to provide accurate real-world measurements.
2. CSV Export Functionality: Develop a feature to export the calculated volumes into a CSV file.The CSV should include columns for 'Label ID', 'Volume', and any other relevant metadata.

The stool has a similar Houndsfield unit to fat. In patients with watery stool, the visceral label segmentation includes the stool. In more constipated patients the differentiation works better.
This finding will affect volumetry-based studies (cachexia). A temporary solution will be to use the L3 approach, where only the relevant label segmentations are considered.

Dear MOOSE group,

I am trying to use moose for the segmentation of a patient's CT data using the bellow commands but I get an error suggesting there is no moose complying subject. Is this the write way to run moose? any suggestions, please?

(moose-env) PATH-TO\moose-env>moosez -d "C:\\Users\NAME\\Box\SEG\\CLINICAL\\S1\\AC-CT"  -m clin_ct_organs

Imaging: Clinical | Modality: CT | Tissue of interest: Organs
Required modalities: ['CT'] | No. of modalities: 1 | Required prefix for non-DICOM files: ['CT_']
Warning: Subjects which don't have the required modalities [check file prefix] will be skipped.
CUDA is available on this device with 2 GPU(s). Predictions will be run on GPU.

🌐 MODEL DOWNLOAD:

A local instance of Dataset123_Organs has been detected.

🔍 STANDARDIZING INPUT DATA TO NIFTI:

Processing subjects... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0% -:--:--
Standardization complete.
Number of moose compliant subjects: 0 out of 0
❌ No moose compliant subject found to continue! 💡 See: https://github.com/QIMP-Team/MOOSE#directory-structure-and-naming-conventions-for-moose-%EF%B8%8F

Thank you

Inside the vertebra, the spinal canal including the spinal cord is misclassified as skeletal muscle.
Fixing strategy:

• Take vertebra segmentation, fuse it, fill up the hole and use it as mask
• Wrongly classified spinal cord inside vertebra can be subtracted from the mask and labelled as spinal cord
• @LalithShiyam to retrain model

I am currently trying to run your MOOSE software on the PET/CT DICOM Images.
However, although I the RESULTS_FOLDER variable has been set, the same index error as issue 41 seems to occur.

Might there be any possible reasons for this?
My data folder is

base_folder
 |_ 01
    |- CTIMAGE
       |- xx.dcm 
       ..
    |- PETIMAGE

and I have run the moose -f base_folder command.

Thanks

I am running MOOSE in a patient folder with two subfolders for CT and PET under DCIOM format. However, I am getting this error message:

moose_ct_atlas = ie.segment_ct(ct_file[0], out_dir)
File "/export/moose/moose-0.1.0/src/inferenceEngine.py", line 78, in segment_ct
out_label = fop.get_files(out_dir, pathlib.Path(nifti_img).stem + '*')[0]
IndexError: list index out of range

Any suggestion, please?

Thanks,

Hi guys,

have you ever thought about exporting the calculated segmentations as RT structure sets?
It could enhance the MOOSE usage on non-NIfTI imaging software suites :)

Best
Michael