clin_mr_FVM release asset extracts with an extra top-level folder

[LalithShiyam]

Summary

The clin_mr_FVM_30032026.zip release asset extracts one directory level deeper than the layout expected by moosez.models.Model, causing clin_mr_FVM to fail after download even though the asset contains valid nnUNet weights.

Affected asset

• Release: moosez-v.3.2.0
• Asset: clin_mr_FVM_30032026.zip
• URL: https://github.com/ENHANCE-PET/MOOSE/releases/download/moosez-v.3.2.0/clin_mr_FVM_30032026.zip

Expected layout

moosez expects model folders directly under models/nnunet_trained_models, matching other assets such as clin_ct_organs:

models/nnunet_trained_models/Dataset501_FVM/
  nnUNetTrainer__nnUNetResEncUNetPlans_40G__3d_fullres/
  model_version.json

Actual layout after download

The FVM asset currently extracts as:

models/nnunet_trained_models/Dataset501_FVM/
  model_version.json

models/nnunet_trained_models/clin_mr_FVM/Dataset501_FVM/
  nnUNetTrainer__nnUNetResEncUNetPlans_40G__3d_fullres/

Because Dataset501_FVM/model_version.json matches the expected URL, subsequent runs treat the model as cached, then fail while looking for an nnUNet configuration folder.

Error

ValueError: No valid configuration folders found in .../models/nnunet_trained_models/Dataset501_FVM

Verification

After moving:

models/nnunet_trained_models/clin_mr_FVM/Dataset501_FVM/nnUNetTrainer__nnUNetResEncUNetPlans_40G__3d_fullres

into:

models/nnunet_trained_models/Dataset501_FVM/

the model loads successfully:

directory= .../nnunet_trained_models/Dataset501_FVM
configuration_directory= .../Dataset501_FVM/nnUNetTrainer__nnUNetResEncUNetPlans_40G__3d_fullres
folds= ('all',)
expectation= (['MR'], ['MR_'])
labels= {0: 'background', 1: 'structure'}
training= 34

The nnUNet predictor also initializes successfully from the corrected folder on CPU.

Suggested fix

Repackage and replace the release asset with the same filename, but with Dataset501_FVM/ at the zip root, matching the layout used by other MOOSE model assets. This should preserve the existing URL used by released moosez versions.

[LalithShiyam]

Real-data validation started

I am validating the local clin_mr_FVM layout fix against the DICOM dataset at:

/Users/nutellabear/Downloads/Test_Dataset_VM

Notes from inspection:

• The dataset contains DICOM series folders such as VM_36_T2w, VM_37_T2w, VM_36_T1w, etc.
• No NIfTI files are present in the source dataset at inspection time.
• A previous log in the source directory showed the run reached model download/extraction for clin_mr_FVM.
• After manually moving the nnUNet configuration folder from the nested extracted path into Dataset501_FVM/, models.Model("clin_mr_FVM") loads successfully and predict.initialize_predictor(..., "cpu") initializes successfully.

First real test will run on a writable temp copy of VM_36_T2w, not on the original source directory, to avoid mutating the input dataset during validation.

[LalithShiyam]

Real-data validation result

The local clin_mr_FVM layout fix was validated with a real DICOM T2w case.

Command:

.venv/bin/moosez -d /private/tmp/moose_fvm_realtest_nested -m clin_mr_FVM

Test structure:

/private/tmp/moose_fvm_realtest_nested/
  VM_36/
    VM_36_T2w/
      IM00001
      IM00002
      ...

Result:

• DICOM standardization completed.
• 1 out of 1 subject was MOOSE compliant.
• clin_mr_FVM inference completed.
• Output was written successfully.

Generated input image:

/private/tmp/moose_fvm_realtest_nested/VM_36/MR_VM_36_T2w.nii

Generated segmentation:

/private/tmp/moose_fvm_realtest_nested/VM_36/moosez-2026-06-03-21-05-23/segmentations/clin_MR_FVM_segmentation_MR_VM_36_T2w.nii.gz

Final CLI summary:

All predictions done! | Total elapsed time for 1 datasets, 1 models: 1.1 min | Time per dataset: 1.13 min | Time per model: 1.13 min

Additional note:

The DICOM conversion works when the input is structured as main_dir/subject/series_folder/DICOM files. A shallower test structure where the main directory directly contained the series folder (main_dir/VM_36_T2w/DICOM files) converted individual DICOM slices to IM000xx.nii files and yielded 0 compliant subjects, because no MR_*.nii file was created at the subject level.