JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for FSL Archives


FSL Archives

FSL Archives


FSL@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

FSL Home

FSL Home

FSL  2004

FSL 2004

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: multi-volume data

From:

Mark Jenkinson <[log in to unmask]>

Reply-To:

FSL - FMRIB's Software Library <[log in to unmask]>

Date:

Tue, 14 Dec 2004 10:48:40 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (215 lines)

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,
        Mark


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]  http://www.fmrib.ox.ac.uk/~steve
>>>>
>>>>
>>>>
>>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager