Dear Lazar,

Your description sounds fine.
The Data Format Working Group decided that dim[4] would
always be time to make things simpler, so I'm afraid that
the multi-channel index has to be in dim[5] as you have it.

As I said before, we haven't implemented any support for
the vector or matrix storage options (which use dim[5]) but
we do intend to do this.  We will treat this dimension as
the index in a multi-component vector which I think should
be sufficient for your needs if I understand them correctly.
If you do have specific requirements for processing
multi-channel data which you don't think will be covered
then please let us know.

All the best,

On 14 Dec 2004, at 03:12, Lazar Fleysher wrote:

> Dear Mark Jenkinson,
> Thank you very much for your thoughtful answer.
> The reason I have asked many questions about NIFTI support is that we
> have
> created our own image reconstruction system which takes raw data
> (k-samples) from an MRI scanner and reconstructs images. We want to
> make
> NIFTI our default format which our users use. We also want to make FSL
> our
> users' main tool for data analysis. Therefore, I am asking a lot of
> questions so we can build our system to be compatible with FSL. I
> completely understand that support of NIFTI is a difficult transition
> and
> it will not happen in a second.  Several steps are needed. On the other
> hand, we have to build our system too. :-)
> So, as I said, I would prefer, multi-channel data to be stored before
> time
> point as it is more logical (storing multi-channel data after time
> point
> causes sorting of data which is unnecessary...). But this is NOT what
> we
> do.
> Our current setup is that data is 5D and the 5th dimension is used for
> channels. In other words, Nchannel data is stored as:
> dim[0]= 5
> dim[0]= Nfrequency encode
> dim[1]= Nphase encode (y)
> dim[2]= Nphaze encode (z) or Nslices(z)
> dim[3]= Ntime points
> dim[4]= Nchannel
> This is consistent with the NIFTI NIFTI_INTENT_VECTOR specification.
> Notice, that in such a setup, if Nchannel=1, the data set is still 5D.
> As far as I understand, this way of storing data agrees with your
> "theoretical" answer.
> Now, we come to the practical situation....
> If Nchannel=1, FSL happily works.
> If Nchannel>1, FSL happily works too, but there is no way to switch
> between channels. (Or I do not understand how to do it.) It always uses
> the first index of the 5th dimension.
> Basically, I think, I am proposing to consider a possibility to add the
> switch in future FSL releases to consider the 5th dimension as the
> channel number.
> Once again, thank you for your kind help. With best wishes,
> Lazar
> On Mon, 13 Dec 2004, Mark Jenkinson wrote:
>> Hi Lazar,
>> Firstly, my theoretical answer:
>> The new nifti format does allow, in certain cases, the fifth dimension
>> to be utilised (e.g. for vector or matrix formats).  However, it
>> hasn't
>> been specifically arranged for separate "channels" to use this form.
>> The question is, would storing your separate channels as elements of
>> a vector (that is, a separate vector at each point) be sufficient?
>> If so, then the nifti standard is currently OK for what you want.
>> Note that nifti has been quite specific that dimension 4 is for time,
>> and so it is not possible to rearrange this.
>> Secondly, my practical answer:
>> At present FSL and AFNI do not support the full variety of
>> possibilities
>> that the new nifti format has created.  We are all working towards
>> implementing features that take account of the new options, such as
>> the higher dimensions, the qform/sform transformation information,
>> etc. but at the moment our first pass implementations don't do
>> everything.
>> In the near future we hope to implement the rest of the features
>> like the higher dimensions for vector or matrix images.
>> In the meantime, if you have multiple channels of 3D images, then
>> storing them as 4D images (and treating dimension 4 as channel
>> number rather than time) should work with most FSL programs,
>> as they do not make many assumptions about the time axis.
>> In many cases the images are just treated as a set of 3D images and
>> various programs will process things quite appropriately for a set
>> of different channels.
>> I hope this helps explain the general situation in theory and also
>> helps you get things done in the real world for the moment.
>> All the best,
>>     Mark
>> Lazar Fleysher wrote:
>>> Hello Steve,
>>> Hm....
>>> If dim[0] = 5, fslview happily displays the first image in 5th
>>> dimension.
>>> Do not take me wrong! I do not want you to fix this to "if (dim[0]
>>> >4) {
>>> do not know what to do}" even if you consider this as a bug!!! (like
>>> AFNI
>>> did) What I would propose is to have a switch to higher indecies of
>>> the
>>> 5th dimension so that people who store data from several channels in
>>> one
>>> file can access it.
>>> The problem is that saving channels in different files creates a
>>> bookkeeping problem of file multiplication.... Is it possible to
>>> agree
>>> that the 5th dimension is the channel number? (I would prefer it to
>>> be the
>>> 4th and the time be the last dimension used, by the way).
>>> What do people do for muti-channel data now? Do they combine the
>>> images
>>> into one image and thus not have multi-channel files or they save
>>> each
>>> channel in a separate file?
>>> Am I very far from the reality of the real word?
>>> Thanks for your help
>>> Lazar
>>> On Sat, 11 Dec 2004, Stephen Smith wrote:
>>>> Hi - none of the programs use the 5th (etc.) dimension yet - but
>>>> that
>>>> wouldn't necessarily make sense anyway as it wouldn't have been
>>>> defined
>>>> yet what the programs were expected to do with the 5th dimension....
>>>> Cheers, Steve.
>>>> On Thu, 9 Dec 2004, Lazar Fleysher wrote:
>>>>> Hello everybody,
>>>>> If MRI data is collected from several channels, it may be
>>>>> interesting to
>>>>> look at each of the channels separately. The natural thing is to
>>>>> use the
>>>>> 5th dimension in the NIFTI format for the channel number. However,
>>>>> it
>>>>> appears that fslview can access only the first index in dimensions
>>>>> higher
>>>>> than 4. (AFNI seems to choke even on that...)
>>>>> Is it something that no one needs accept us, here?
>>>>> If not, could it be considered as a feature request?
>>>>> Thanks
>>>>> Lazar
>>>> --
>>>> Stephen M. Smith  DPhil
>>>> Associate Director, FMRIB and Analysis Research Coordinator
>>>> Oxford University Centre for Functional MRI of the Brain
>>>> John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK
>>>> +44 (0) 1865 222726  (fax 222717)
>>>> [log in to unmask]