Generate a variety of testing data

[etpeterson]

Feature description

Currently the only testing data we have is a single b-value set, we want a variety to choose from.

Describe the solution

We generated a csv testing file from binary files now on zenodo using this script. It would be good to have a variety of files to choose from. This would involve running the script with a variety of b-values, generating files, and adding them to the repository.

Describe alternatives

No response

Additional context

No response

Are you working on this?

None

[Unique-Usman]

@etpeterson I will like to work on this also.

Some questions which I have. reference_output.csv - is this the generated output file if not can you kindly point to them ? How many b-values( are available )and how many files do we want to generate ? Is there a reference/ documentation for the script used for generation ? I quite do not understand the binary file as the script does not have any parameter portion which take in a file.

[etpeterson]

Sure. This is related to this pull request. That pulls the data from zenodo when the script is run, so you probably want that branch or to wait for it to be merged.

The output file is generic.json and others. That is then fed into the testing. The goal is to generate this file.

The specific b-values are those referenced in this issue but you could use some placeholders for now. Using what we have currently and modifying them slightly with more or less numbers, perhaps ending higher or lower (800 to 1200). But always start at 0.

Unfortunately no documentation. Maybe that would be a good first pull request for this issue is to document how to run the script and from there start modifying code?

I'm not sure about the raw data structure either, but it looks like it's loaded here, so you could imshow there and see what you're looking at. Keep in mind intensities might vary so you might need to rescale the numbers from 0 to 256. What is output in the end though is the text file and some binary images in nifti format. You can find viewers for that format online, so you can view the output if you can get it to run.

Does this help? Unfortunately we're just wrapping up a repository reformat where the data got moved so it's just now getting settled again.

[Unique-Usman]

thanks, I will look into, if I have any question. I will definitely let you.

[Unique-Usman]

Hi @etpeterson. Thank for the information. I was able to get the code to run and generate the generic.json file and the other six binary images in nifti format. I was also able to wrote some python script to visualize the nifti image. And I was also able to write some python script to visualize the loaded the image (.mat) this. Which I got from the Zenodo website. I just download the zip from the Zenodo file and then extract the XCAT5D_RP_1_CP_1.mat.

What I noticed is that XCAT5DRP(1-21)_CP_1.mat has about 21 of it kind and they all represent the same image with little differences.

When I also changed some of the b-values, I notices some differences in the generated nifti images.

My question now is that, how many placesholders of b-value do we want to generate till get some specific b-values #10 . Also, right now in the script, the generic.json generated is just for XCAT5D_RP_1_CP_1.mat. Are generating for other 20 types also.

[Unique-Usman]

One example of the nifti image show by my python script

Image of the raw data(.mat file)

[Unique-Usman]

@etpeterson If I may ask also, can you please give some brief explanation of the usefulness of generating this testing data and it application in IVIM. Thank you.

[etpeterson]

Glad you got it running. I see the first .mat file is used unless there's motion, in which case all are used. I see it's just turned off by default here.

If you see differences in the images generated when you change the b-values, then you probably have it correct. In terms of the placeholders, maybe just 4 or so for now? That part doesn't need to be too fancy, what would be nice would be to allow for the choice when the script is run. Right now that's hardcoded, so making that a choice would be great. Probably also changing the name of the output file based on the chosen bvalues so they can all coexist. And going above and beyond, making input arguments to this, so it can be run purely from the command line and not changing the script for different choices.

To summarize

• Make the b-values flexible: choose from a map for example.
• Change output name of the json file based on the input.
• (optional) make into scrip that takes command line parameters, argparse for example.

And to answer your question about why we want this testing data. We want to test the algorithms as best we can. Ideally we'd have real data from real MRI images, but in that case we don't know the actual true values to compare against. This is a digital simulation of the body that we generate, so we know the true values. It can simulate motion and acquisition timing, so it's a better example of what might happen in reality. So this gets us a little closer to the truth. And as to why we want to generate the json file. The binary files are large and we don't want them in the repository. It also takes a long time to run the fitting on all the voxels in the images, so we don't really need it all. That script reduces the images down to a reasonable set for testing, and it also contains all the configuration information we need, like the b-values.

[Unique-Usman]

@etpeterson Thanks for your well detailed reply, I really appreciate it. To follow up with your response.

What we are changing here is just the b_values and we should use one constant value of the .mat(the first one -> XCAT5D_RP_1_CP_1.mat). ?

Should the script accept all the paramter passed to def phantom(bvalue, noise, TR=8000, TE=80, motion=False, rician=False, interleaved=False): or just the b_values ?

Also, what are we going to be pushing to the repository. All generic.json and the script right. We are not adding the binary files "nifti files"(.nii.gz) ?

Thank you.

[etpeterson]

We want to just change the bvalues. No need to change the source image mat file.

I think all options would be good to accept, with defaults of course. I think the bvalues will be a name string that will be converted to the array, like a map key. The current set could be called "original" for example.

The repo update should be the json and script, correct.

[Unique-Usman]

@etpeterson I made necessary and it is working well now. Kindly check it from your end also. I created another pull request for it(https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/issues/41)

[etpeterson]

Closed with the merge of #55