Re: [Teem-users] proposed extension to NRRD file format

[Dr G. J. <jef...@mr...>]

Your proposal sounds fine to me. We do come across data like this e.g. from a multiphoton microscope where X scan system is a resonant scanner which moves with a sinusoid rather than linearly in time or where the objective is moving wrt to the sample changing Z again with a sinusoid or even something more complex. 

Of course one question is who might read this information. Amira (for which I have written a very basic reader) can handle the more general case that you mention (they call this rectilinear) as well as non-constant Z intervals (which they call stacked).

http://walnut.zib.de/documentation/521/amira/usersguide/grids.html

ImageJ for which I have written a reader might be able to fake non-constant Z, but even this is not so obvious and I wouldn't immediately see that it would be respected by any 3d processing operations.

What can Slicer do? And as David Weinstein asks how would e.g. resampling in unu work?

Best,

Greg.

On 17 Aug 2011, at 01:42, Gordon L. Kindlmann wrote:

> Hello,
> 
> I'd like to float a proposed extension to the NRRD file format.
> 
> The NRRD format currently handles grids of any dimension, which can contain an affine transform from the index space of the grid to some surrounding world space of any dimension, via http://teem.sourceforge.net/nrrd/format.html#space
> 
> One restriction with this is that the spacing between adjacent samples on an axis is fixed; the per-axis "space direction" vector gives that offset between any two subsequent samples along that axis.
> 
> However, there are circumstances where the spacing between samples is non-uniform; as with an imaging experiment that acquires the same spatial volume multiple times, but at non-periodic set of time points.  This question has come up in discussion of the NRRD format with the Slicer team at Brigham & Woman's hospital, and subsequent conversation with ITK developers highlighted how the same situation can arise with microscopy (the locations of z-slices may not be spaced with the intended regularity) and video.  So to be clear, this is not about turning NRRD into a general mesh file format- this is only about a loosening the restriction that inter-sample spacing along an axis must be constant.
> 
> Here's an example of what the format would look like:
> 
> NRRD0006
> type: float
> dimension: 4
> space: left-posterior-superior-time
> kinds: space space space time
> encoding: raw
> sizes: 256 256 14 65
> endian: little
> space directions: (1.0156,0,0,0) (0,1.00279,0.1608,0) (0,-0.94997,5.9243,0) (0,0,0,0.47)
> space locations: none none none (0.0, 1.01, 1.9, 2.0, 2.89, 4.15, 5.2, 6.09, 6.89, ...)
> space origin: (-142.704,-139.965,-61.2393,0)
> 
> The new field is "space locations".  For each axis, it gives either "none" or a list of numbers, with as many values as there are samples along the axis.  Whereas before, the sample location is determined by multiplying the (integral) sample index by the per-axis "space direction" (and then adding space origin), now, you would multiply the (non-integral) sample location by the per-axis space direction (and then adding space origin).  Note that the "magic" at the file start has incremented to the previously unused NRRD006.
> 
> We would have to determine restrictions on the list of values in the "space locations" field.  It has to follow the "sizes" field, or else it has to be parsed speculatively (which would be out of character for NRRD).  Certainly, there has to be one value per sample along that axis.  But:
> 
> * Should the numbers have to be monotonically increasing? (I'd say yes, or else the relative spatial positions of values can be unrelated to their memory locations, which also seems out of character for  NRRD).
> 
> * Should the list start with "0.0"?  (maybe yes, to preserve the current semantics of the "space origin" field, or maybe that's too restrictive).
> 
> * Can there be multiple axes with "space locations?"  I'd say yes, it allows us to handle rectilinear grids trivially, in addition the non-uniform time points.  Applications that can't handle that generality can balk at those NRRD files.
> 
> * Is it sensible to have a "space locations" field for an axis that doesn't have a "space directions" field?  I would say no, right? Does this mean the "space locations" field is only allowed after the "space directions" field?
> 
> * Besides listing a location for each and every sample, should there be some richer representation for something like, "30 samples with 0.3 spacing, one with 0.23 spacing, and then 40 more with 0.3 spacing"?  This could be handy for some applications, but with a high implementation cost.
> 
> * The NRRD format has always had an ASCII header, and there's probably no reason to change that, but you could argue that if you really want precise representation of sample locations, it would be better to use the 8 bytes of a double, rather than the 15 or whatever characters you need to reliably get the same information with ASCII.  Maybe you could have a base64-encoding of the list of sample location values?  Again, with a high implementation cost.
> 
> All this means that lines in the NRRD header could get very long, but I don't see this as a problem.  The current file format spec says "In the current definition of the format, there is no limit to how long a line can be", and I have no sympathy for non-conformant readers.
> 
> Let me know your thoughts,
> Gordon
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
> user administration capabilities and model configuration. Take 
> the hassle out of deploying and managing Subversion and the 
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> teem-users mailing list
> tee...@li...
> https://lists.sourceforge.net/lists/listinfo/teem-users

--
Gregory Jefferis, PhD                  jef...@mr...
Division of Neurobiology               LMB Lab:   +44 (0)1223 252943
MRC Laboratory of Molecular Biology,   LMB Office:+44 (0)1223 402333 [NEW NUMBER]
Hills Road,                            LMB Fax:   +44 (0)1223 402310
Cambridge, CB2 0QH, UK.                    

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu