NIFTI data type/importer

[David Gutman]

Has anyone modeled up all the fields in a NIFTI file as well as build
an importer that reads all that stuff out/populates it?

I know you can add a NIFTI file as a scan level resource, but I also
wanted to in theory store all the other "stuff" as accessible like
x,yz matrix size, voxel size, qform, etc....



Shouldn't be a huge challenge in theory, but if someone already had
done it... would rather avoid the "wheel" reinventing we always speak
about.





--
David A Gutman, M.D. Ph.D.
Assistant Professor of Biomedical Informatics
Senior Research Scientist, Center for Comprehensive Informatics
Emory University School of Medicine

[Burns, Scott S]

I looked at this a while back but haven't worked on it recently. If you're in python and can load the nii with nibabel, something along these lines may (read: very untested) work:

> import nibabel as nib
> img = nib.load(NII_PATH)
> hdr = img.get_header()
> scan_attrs = {}
> loop = zip(['session_error', 'dim', 'datatype', 'descrip'],
[lambda x: 'Good' if x == 0 else 'Error', lambda x: str(x[4]), lambda x: str(x.dtype), lambda x: ' '.join(str(x).split())],
['validation_status', 'frames', 'dataType', 'series_description'])
> for hdr_key, func, xnat_attr in loop:
scan_attrs[xnat_attr] = func(hdr[hdr_key])
...
> scan.attrs.mset(scan_attrs)

There are probably a few more things that could be mapped (dimensions/voxel sizes/etc) but not many. Hope this helps.

-- Scott

> --
> You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
> To post to this group, send email to xnat_di...@googlegroups.com.
> To unsubscribe from this group, send email to xnat_discussi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/xnat_discussion?hl=en.
>
>

[David Gutman]

It does---- I have something similar coded in nibabel, I just haven't
added it as a "new" data type---

Probably something I'll work on and once it's done I'll post the data
model/python code to NITRC or whatever..


Thanks Scott...

[Tim Olsen]

Is there a good java api for working with NIFTI?

[Haselgrove, Christian]

> Is there a good java api for working with NIFTI?

There's the NIfTI Java reference implementation (niftijlib):

http://www.nitrc.org/frs/?group_id=26

c

--
Christian Haselgrove
christian....@umassmed.edu
508-856-5363
Fax: 508-856-8211

[Sanket Gupte]

Hey if you successfully make a NIFTI .nii datatype that can do that, can you share it here too. Or post it on Marketplace  when time comes ! That would be really good !
Thanks

>> To post to this group, send email to xnat_discussion@googlegroups.com.
>> To unsubscribe from this group, send email to xnat_discussion+unsubscribe@googlegroups.com.

>> For more options, visit this group at http://groups.google.com/group/xnat_discussion?hl=en.
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups "xnat_discussion" group.

> To post to this group, send email to xnat_discussion@googlegroups.com.
> To unsubscribe from this group, send email to xnat_discussion+unsubscribe@googlegroups.com.

[David Gutman]

Of course!! It's an open source world in which we live..

May be a couple of weeks-- but I've already basically done something
similar directly into MSQL tables--- I never had just bothered
actually making it an "XNAT" friendly schema...

>> >> To post to this group, send email to xnat_di...@googlegroups.com.

>> >> To unsubscribe from this group, send email to

>> >> xnat_discussi...@googlegroups.com.

>> >> For more options, visit this group at
>> >> http://groups.google.com/group/xnat_discussion?hl=en.
>> >>
>> >>
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "xnat_discussion" group.

>> > To post to this group, send email to xnat_di...@googlegroups.com.

>> > To unsubscribe from this group, send email to

>> > xnat_discussi...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/xnat_discussion?hl=en.
>> >
>>
>>
>>
>> --
>> David A Gutman, M.D. Ph.D.
>> Assistant Professor of Biomedical Informatics
>> Senior Research Scientist, Center for Comprehensive Informatics
>> Emory University School of Medicine
>

> --
> You received this message because you are subscribed to the Google Groups
> "xnat_discussion" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/xnat_discussion/-/G7gif4n8sUoJ.
>
> To post to this group, send email to xnat_di...@googlegroups.com.

> To unsubscribe from this group, send email to

> xnat_discussi...@googlegroups.com.

[Tim Olsen]

The idea of a NIFTI datatype scares me. What happens if you generate DICOM,
or analyze off of it? Do you need to create a new datatype?

Aren't the fields populated in NIFTI already present in the existing
mrScanData implementation (or imageScanData)? If not, they should be added.
I would imagine your script just creating an MRSession, adding the pertinent
scans, setting the properties on those scans from the NIFTI, and uploading
the files as a NIFTI resource of those scans. If you later added DICOM to
those sessions, you could just add them as DICOM resources of those scans.
This way it would look the same as a session that you added as DICOM and
converted to NIFTI.

What data type would you be adding? What properties would they have that
the existing xnat data types wouldn't? Or am I completely misunderstanding
things here?

Tim

-----Original Message-----
From: xnat_di...@googlegroups.com
[mailto:xnat_di...@googlegroups.com] On Behalf Of David Gutman
Sent: Tuesday, July 03, 2012 9:36 AM
To: xnat_di...@googlegroups.com
Subject: Re: [XNAT Discussion] NIFTI data type/importer

[David Gutman]

So that's a bad thing .... if there's a better way that's less likely
to break things.. I'm OK with it.



so just typing FSLINFO.. you get the following info (there's some
other stuff in the NIFTI header)....

Basically in my theoretical default NIFTI_TYPE I would want to be able
to access the x,y,z,t dims, the datatype (INT16/32/float/etc), the
pixel dimensions of the 4 axes... and also store the s_form and q_form
data that's hidden in the nifti header (although honestly I get a bit
lost following those)...


I imagine a scenario where I am storing "GUTMANS_BRAIN.nii.gz" and
GUTMANS_BRAIN_MASK.nii.gz and I want to render/overlay the two--- I
need/want to be able to first determine quickly if they have the same
basic dimensions before I even attempt to overlay them.... so I have a
little mySQL database I have used for similar things in the past, but
I am trying to XNATify this process in the long term....

Similarly I may also want to tag things (like CANONICAL_SPACE) or
something like that.. so I could say query all the patients /NIFTI
images that are say already in MNI152_2mm space or something like
that.....



data_type INT16
dim1 240
dim2 256
dim3 176
dim4 1
datatype 4
pixdim1 1.0000000000
pixdim2 1.0000000000
pixdim3 0.9999923706
pixdim4 0.0000000000
cal_max 0.0000
cal_min 0.0000
file_type NIFTI-1+
dagutman@cerebro:/drobo/SGE

[Archie, Kevin]

I agree with Tim that better than creating a NIfTI MR session data type would be to find ways to map the NIFTI metadata into the existing XNAT mrSession|ScanData type, adding fields as necessary. After all, mrScanData and mrSessionData were created before XNAT was able to handle DICOM -- the original data model was based on the old Siemens IMA format.

I further wonder how many of these fields really belong in the schema. I'm something of an extremist on this point: I think that metadata belongs in the XNAT database only if (1) somebody is going to use it for searches, or maybe (2) if it belongs on a report page.

If a field is something you'll only be using programmatically, there could be a service by which you can pull the fields directly from the data files. Deech built a DICOM dump service into XNAT 1.6 that retrieves (almost) all of the DICOM metadata for one file from a specified session or scan. I've been extending this (allowing the caller to enumerate which attributes will be returned, parsing Siemens shadow headers), although my changes haven't made it to the 1.6 dev branch yet.

A similar thing could be built for NIfTI, and then there's no overhead of trying to figure out how to map file-format-specific parameters into a general MR session/scan representation.

It's possible that this isn't as big a deal for NIfTI as for DICOM, because the NIfTI metadata model is so much smaller and more uniform. And it's possible that I'm just all wet -- I've previously admitted to extremism on this point.

- Kevin

________________________________

The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.