Hello Mark,
The way I see it, avwhdr is designed to report what is written in the
header, not to interpret it. If I am correct, there is a bug, as dim[0] is
missreported. If avwhdr function is other, than I have no problem, even
though, in the latter case, I do not know what the fuction of avwhdr is.
The avwhdr report created a confision, but so far no other side effects.
There is a difference between examples of how to use the file format and
file format specificatinos. I do not see how dim[5]>1 is limitted to
"vector" representation.
Once again, thank you for resolving the confusion. With best wishes,
Lazar
On Mon, 28 Feb 2005, Mark Jenkinson wrote:
> 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>
> >>
>
|