Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saving a Whole Subject #783

Open
justusschock opened this issue Dec 20, 2021 · 4 comments
Open

Saving a Whole Subject #783

justusschock opened this issue Dec 20, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@justusschock
Copy link
Contributor

justusschock commented Dec 20, 2021

馃殌 Feature

Hi,

Just wanted to propose to add a mechanism of saving a whole subject to a directory

Motivation
Currently to save a whole subject, I need to iterate over all images, save them individually and then save all the non-image stuff to a separate file as well.

This could be easier with an API like Subject.save(SAVE_PATH, image_type='nifti|dicom',meta_type='yaml|json').
The corresponding load function would then be something like Subject.from_directory(SAVE_PATH).

Pitch
An easy function

A simple function could look like this (haven't tested this yet):

def save(save_path: str, image_type: str = 'nifti', meta_type: str = 'json'):

    if image_type == 'nifti':
        image_ext = '.nii.gz'
    # QUESTION: Do we want to save as dicom series or single dicom file here?
    elif 'image_type == 'dicom':
        image_ext = '.dcm' 
    else: 
        raise NotImplementedError

    if meta_type == 'json':
        meta_save_fn = json.dump
    elif meta_type == 'yaml':
        ... # not sure which function to use here out of my head
    else:
        raise NotImplementedError

    save_dict = {}
    for k, v in self.items():
        if isinstance(v, Image):
            v.save(os.path.join(save_path, k + image_ext))
            save_dict[k] = v[TYPE]
        else:
            save_dict[k] = v

    save_fn(save_dict, os.path.join(save_path, 'subject.torchio'))

Note: This specific function has not been tested, but I have something similar in custom code already.

Open questions:

  • Do we want something like this at all
  • What file formats do we want to support? I think for images we definitely need multiple (especially nifti and dicom) but for metadata only using yaml or json should be fine as well
  • If we use multiple file types for the metadata, how do we detect which loader we have to use?

Alternatives
Manually save each image and all the metadata.

Additional context

cc @fepegar :)

@justusschock justusschock added the enhancement New feature or request label Dec 20, 2021
@fepegar
Copy link
Owner

fepegar commented Jan 18, 2022

Hi, @justusschock. Thanks for the suggestion.

What file formats do we want to support? I think for images we definitely need multiple (especially nifti and dicom) but for metadata only using yaml or json should be fine as well

All file formats supported by ITK or nibabel. It would be the user's responsibility to make the suffix compatible. JSON or YAML would be my choice too.

If we use multiple file types for the metadata, how do we detect which loader we have to use?

Looking at the extension? I might have misunderstood the question.

Do we want something like this at all

I'm not sure it's worth adding it to the library. It seems useful, but it might not be a common enough need for users. The community hasn't interacted with the post either...

@justusschock
Copy link
Contributor Author

Looking at the extension? I might have misunderstood the question.

What I mean: If the API is so that the user passes a directory for loading, for what files would we look? How would we handle YAML/JSON files that are not valid metadata files and what would we do if there are multiple possible files or none of them?

I'm not sure it's worth adding it to the library. It seems useful, but it might not be a common enough need for users. The community hasn't interacted with the post either...

Personally I need this almost all the time when I preprocess my data and then save the preprocessed state. But it's up to you, if you want that added :)

@romainVala
Copy link
Contributor

romainVala commented Jan 20, 2022

I also like the Idea, but I can understand fernando, that this is border line, in the sense that it can easily be implemented outside torchio, for you application purpose

but it still make things easier for the users, so I vote +1

About several files, I think we should keep it simple and make some choice in the save function :

one file for meta info something like subject_info.json, and image files

I think you also need to add the file path of the saved images in the save_dict, so that you know what image to load in addition to the torchio TYPE. (especially if you have multiple dicom for one volume)

@fepegar
Copy link
Owner

fepegar commented Jan 20, 2022

If you both think it would be useful, I'm happy to review your PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants