confused about 4D header formats ANALYZE/NIFTI

[Anna Barnes]

Hi
I'm using the import dicom sequence plugin to read in fMRI data sets and then saving them using the
ANALYZE(NIFTI-1) I/O plugin. However when I look at the header info for this new stack it still tells
me there are #slices (i.e total # of dicom files) rather than #volumes with #slices each. Further,
matlab won't read in the images as a 4D stack and still sees it as a stack of total # of slices. so is
there something in imagej I can do to correct the header and save it in such away that matlab will
read it? I'm doing it this way because the dicom capabilities in imagej are far superior to matlab and
take a fraction of the time !

thanks
Anna

[Wayne Rasband]

> I'm using the import dicom sequence plugin to read in fMRI
> data sets and then saving them using the ANALYZE(NIFTI-1)
> I/O plugin. However when I look at the header info for this
> new stack it still tells me there are #slices (i.e total #
> of dicom files) rather than #volumes with #slices each.
> Further, matlab won't read in the images as a 4D stack and
> still sees it as a stack of total # of slices. so is there
> something in imagej I can do to correct the header and save
> it in such away that matlab will read it? I'm doing it this
> way because the dicom capabilities in imagej are far
> superior to matlab and take a fraction of the time !

Are the dimensions of the DICOM stack specified correctly in the
Image>Properties dialog? The NifTi Input/Output plugins at
<http://rsb.info.nih.gov/ij/plugins/nifti.html> appear to support up to
five dimensions. They correctly save and reopen the the sample 4D
(256x256x20x10) stack at
<http://rsb.info.nih.gov/ij/images/4D-Stack(256x256x20x10).zip>.

-wayne

[Anna Barnes]

Dear Wayne
thanks for that tip. I managed to suss out what I needed to change in  
the properties dialogue box. Depth (z) to #slices per volume and  
frames = the # of volumes per stack.

Cheers
Anna

On Jun 21, 2006, at 3:37 PM, Wayne Rasband wrote:

>> I'm using the import dicom sequence plugin to read in fMRI
>> data sets and then saving them using the ANALYZE(NIFTI-1)
>> I/O plugin. However when I look at the header info for this
>> new stack it still tells me there are #slices (i.e total #
>> of dicom files) rather than #volumes with #slices each.
>> Further, matlab won't read in the images as a 4D stack and
>> still sees it as a stack of total # of slices. so is there
>> something in imagej I can do to correct the header and save
>> it in such away that matlab will read it? I'm doing it this
>> way because the dicom capabilities in imagej are far
>> superior to matlab and take a fraction of the time !
>
> Are the dimensions of the DICOM stack specified correctly in the  
> Image>Properties dialog? The NifTi Input/Output plugins at <http://
> rsb.info.nih.gov/ij/plugins/nifti.html> appear to support up to  
> five dimensions. They correctly save and reopen the the sample 4D  
> (256x256x20x10) stack at <http://rsb.info.nih.gov/ij/images/4D-Stack 
> (256x256x20x10).zip>.
>
> -wayne

[Anna Barnes]

ps Now I just have to try and script it all at command line :) any  
good teaching examples on this ?

anna

On Jun 21, 2006, at 3:37 PM, Wayne Rasband wrote:

>> I'm using the import dicom sequence plugin to read in fMRI
>> data sets and then saving them using the ANALYZE(NIFTI-1)
>> I/O plugin. However when I look at the header info for this
>> new stack it still tells me there are #slices (i.e total #
>> of dicom files) rather than #volumes with #slices each.
>> Further, matlab won't read in the images as a 4D stack and
>> still sees it as a stack of total # of slices. so is there
>> something in imagej I can do to correct the header and save
>> it in such away that matlab will read it? I'm doing it this
>> way because the dicom capabilities in imagej are far
>> superior to matlab and take a fraction of the time !
>
> Are the dimensions of the DICOM stack specified correctly in the  
> Image>Properties dialog? The NifTi Input/Output plugins at <http://
> rsb.info.nih.gov/ij/plugins/nifti.html> appear to support up to  
> five dimensions. They correctly save and reopen the the sample 4D  
> (256x256x20x10) stack at <http://rsb.info.nih.gov/ij/images/4D-Stack 
> (256x256x20x10).zip>.
>
> -wayne