Information on metadata/tags in Mia (from .json after conversion in Mri_conv)

[servoz]

We need to know exactly what the data in the .json retrieved after switching from mri_conv to mia corresponds to (and even how it was obtained).

We discussed this a long time ago and I'm not thinking very clearly.

Some of the json keys are obvious, for example the dataset dimensions (Count, X,Y,Z,T...). On the other hand, some of them can be confusing!

Is there a conversion dictionary that lets we know exactly what each key in the json dictionary corresponds to?

Can we consider adding new json keys? The nifti/json standard are still vague, and I'm not sure there is an absolute standard yet, so why not add information that we think is interesting and easily accessible (for example, some information are available directly in the .PAR file for PAR/REC, I think it's the same for all formats)?

I can come and see you if it's easier!

[manuegrx]

Hi,

Just to say that I think that there is already lot of information in the json provided by mriconv but I agreed that it could be interesting to add some information in the json .

However, for DICOM data it could be really painful to get the correct information because depending on the manufacturer and on the DICOM type (enhanced or classic), the same information is not in the same tag.. So it could be a lot of work and maintenance to get the information for each DICOM tag (depending on how much new info we want to add).

Regarding the nifti/json standard, I think that the one proposed by BIDS is being more an more used. The benefit is that maintained software as dcm2niix allow to get it.
Here are some example to compare what is it obtain by dcm2niix and mriconv :
examples_json.zip

The json produced by dcm2niix complies with the BIDS standard and is therefore not organised in the same way as the mriconv json but there are of course a lot of common information. It does not contain the NIfTI header information (so not directly the dataset dimension for example).

[servoz]

We should create an internal converter for Mia. Mri_conv is very good, in fact it offers much more than we need.

A converter built into Mia (in python) would give us total control over what it does and allow us to act quickly when needed. It's on the todo list, but given that mri_con can do the job for now, there are other priorities to deal with first. However, in the meantime, it's essential that we have access to the exact meaning of every metadata in Mia, hence every json key in the nifti/json.

The addition of a few json keys would be highly desirable for the output of mri_conv.

[montigno]

Hello,

There is a dictionary in yaml format (DictionaryMRI_System.yml) which is located in the MRIManager.jar directory. For each key, there is a 'description' field which allows you to add information. This dictionary is perhaps not very practical, we can discuss that. The mri_conv json doesn't follow the Bids convention, but perhaps we could add an option that would allow the user to choose the form. Otherwise, for a long time I wanted to rewrite mri_conv in Python, the most difficult part in the conversion to Nifti is the reconstruction of the 4D and 5D images, you have to put them in the order and ImageJ (written in java) is practical for that. Most Nifti converters (dcm2niix, Dicomifier, brkraw, etc.) generate several files when the images are in 5D (and sometimes in 4D). We can do a small meeting between us next week to discuss all this. I will be available Tuesday afternoon, Wednesday, Friday (from 10 a.m.), or another week.

[servoz]

Tuesday 16 afternoon is fine. 14:00 ?

[montigno]

ok for me tuesday at 14:00

[servoz]

Quick summary of the meeting:

There are two types of JSON keys (metadata name).

1. Those coming from the header of the NIfTI file. In this case, it is not managed by mri_conv, and one needs to refer directly to the NIfTI documentation to try to find information about the data.
2. Those coming directly from the raw data. For example, by parsing the PAR file if we are dealing with Philips PAR/REC data. In this case, one indeed needs to look into the file DictionaryMRI_System.yml or DictionaryMRI_User.yml to find an explanation of what the key corresponds to. It is also possible to add a new entry in these files to retrieve a new key.

3. It seems there is currently an issue because we added:

   Scan Duration:
                 description: {info: "Experiment duration"}
   
                 wherePhilips:  {file: PAR ; Xml, keyName: Scan Duration, type: ~ ; ~, format: ~, units: ~}          
   
                 viewer: {category: MRI parameters}
                 json:   {tag_Json: ScanDuration, type: string, format: ~, units: ~}

   and it's not working right now. We are awaiting a fix for this issue, and I believe this ticket can be closed afterwards.

[servoz]

I found the solution on my own. This ticket can be closed now.

[montigno]

Hi,

Sorry for my late response, I had a lot of MRI manipulation and treatment. I will have a little more time in June. I'll start looking at this next week.

I remembered one thing, for Philips you have to put 2 values ​​(separated by ';') for each tag:

wherePhilips: {file: PAR ; Xml, keyName: Scan Duration ; Scan Duration, type: string ; float, format: "ss ; ~", units: ~}

The 1st value corresponds to that of PAR and the 2nd to that of Xml.