Hi Again,

I appreciate your point about dim[0] being redundant, and I
agree, but as NIFTI-1 was intended to be backward compatible
with Analyze, then it was stuck with dim[0] (and 7, not 8 dims).
The specification of NIFTI-1, as contained in the nifti1.h file at:
   http://nifti.nimh.nih.gov/pub/dist/src/nifti1.h
states that:
"dim[i] = length of dimension #i, for i=1..dim[0]  (must be positive)"
  and:
"The 5th dimension of the dataset, if present (i.e., dim[0]=5 and
    dim[5] > 1), contains multiple values (e.g., a vector) to be stored
    at each spatiotemporal location."

This isn't absolutely clear that dim[i] for i>dim[0] should be 1,
but it does say that for dim[0]=5 then dim[5]>1 not dim[5]=1.
I believe that the intention behind this is that dim[i]=1 should
be the default.  In practice it shouldn't matter as beyond dim[0]
you can effectively ignore the values as you can't index these
dims anyway.

So, although I can see your point that other options could have
been implemented, I believe that the reporting of avwhd is the
closest to the standard and the legal examples in the nifti1.h
file that we could achieve.  I hope that this doesn't cause
problems for you.

All the best,
        Mark




On 28 Feb 2005, at 01:07, Lazar Fleysher wrote:

> Since avwhdr gives information about the header, no assumptions should
> be
> made, thus, the behaviour of avwhdr is incorrect.
>
> While one may argue that dimensions above used should be set to 1. (I
> actually agree with you that dim[N]=0 has no meaning, but this is not
> the
> specification of NIFTI, unfortunately). I also think that dim[0] is
> useless since if all dimensions are specified that one does not need
> the
> total counter. It is a waist of dim space. By doing this, NIFTI
> restricted
> itself to 7D data, while there is space for 8D.
>
> In other words NIFTI should have said that all data sets are 8D with
> dimensions specified by the values of dim[0] ... dim[7] and each dim[]
> can
> not be less than 1. Instead, they said that dim[0] is the number of
> used
> dimensions and the values of dim[dim[0]+1] and above are unspecified.
> This
> is a flaw in NIFTI format, but this discussion is useless --- format
> has
> been announced.
>
> Nevertheless, given the NIFTI format, I still think, avwhdr has a bug.
> With dim[0]=5 it is explicitly announced that the data set is 5D, so
> checking that the dim[5]=1 and stating that dim[0] = 4 instead of 5 (as
> written in the file) is a bug. Basically, my complaint is that avwhdr,
> sets dim[0] based on last non-singleton dimension instead of reading it
> from the file.
>
> Thanks to your explanations, I know what is happening, so I am less
> worried about it now. But, it is a bug. :-)
>
> Thanks for your kind help
>
> Lazar
>
> On Sun, 27 Feb 2005, Mark Jenkinson wrote:
>
>> Hi,
>>
>> This is actually sensible behaviour by avwhd and conformant with the
>> specification.
>>
>> If you consider a timeseries which has dimensions of x,y,z and t, then
>> you
>> would normally call it 4D, and dim[0] should be 4.  But if it only had
>> one
>> timepoint, then you'd actually consider it 3D, but with dim[4]=1.
>> Similarly,
>> for higher dimensions.  The default value for any dimension is 1, not
>> 0.
>> The total number of values stored in any dataset should be the product
>> of all dimensions (dim[1] to dim[7]) which doesn't work if higher
>> dimensions
>> are 0.  So given this, dim[0] is set to the highest dimension which is
>> greater
>> than 1.  So in your case, you just have a 4D dataset of size
>> 64x64x30x5
>> and it sets dim[0] to 4 - which is correct.  If you had more
>> dimensions
>> that
>> had more than one entry, say a 64x64dx30x5x2 dataset, then dim[0]
>> would be 5.
>>
>> I hope this makes sense to you, and please ask if there is anything
>> which
>> is still unclear.
>>
>> All the best,
>>         Mark
>>
>>
>>
>> On 27 Feb 2005, at 16:53, Lazar Fleysher wrote:
>>
>>>
>>> Hello
>>>
>>> Does some one happen to know if it is a design feature or a bug:
>>> avwhdr
>>> reports wrong dim[] values.
>>>
>>> For example, I made a file with
>>>
>>> dim[0] =  5
>>> dim[1] = 64
>>> dim[2] = 64
>>> dim[3] = 30
>>> dim[4] =  5
>>> dim[5] =  1
>>> dim[6] =  0
>>> dim[7] =  0
>>>
>>> and avwhdr returns
>>>
>>> dim[0] =  4 <--- wrong
>>> dim[1] = 64
>>> dim[2] = 64
>>> dim[3] = 30
>>> dim[4] =  5
>>> dim[5] =  1
>>> dim[6] =  1 <-- wrong, but do not care since true dim[0] = 5
>>> dim[7] =  1 <-- wrong, but do not care since true dim[0] = 5
>>>
>>> The header file is attached. It was slpit off from a nii file, so it
>>> has a
>>> magic of nifti 1-file format. Ignore it of the purposes of this
>>> question.
>>>
>>> Thanks for your help,
>>>
>>> Lazar
>>> <test.hdr>
>>