[Neuroimaging] NiBabel - Streamlines API - TRK header extension

[Marc-Alexandre Côté]

You are right there is no guarantee. I rely on the common sense of 
initializing memory to \x00. Especially, when that memory corresponds to 
a documented header field.

A more robust approach could be to replace \x00 by a checksum of the tag 
name. However, I don't think it is worth doing it right now.

Marc

On 16-05-30 09:45 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, May 26, 2016 at 5:07 AM, Marc <marc.cote.19 at gmail.com 
> <mailto:marc.cote.19 at gmail.com>> wrote:
>
>     Hi everyone,
>
>     I'm currently working on an API for streamlines in NiBabel and I
>     would like the feedback of the Nipy community about an unofficial
>     extension for the TRK header.
>
>     Right now, the TrackVis's file format for streamlines supports
>     conserving additional information for each point and/or
>     streamline. The format refers to that additional information as
>     "scalars" and "properties" respectively (ref:
>     http://www.trackvis.org/docs/?subsect=fileformat). There is a
>     field in the header to keep a tag name for the first 20 scalars
>     and the first 20 properties even though the format supports having
>     up to 2^16 scalars and 2^16 properties.
>
>     First, 20 is not a lot when you think of all the metrics one could
>     want to keep (e.g. color, FA, curvature, torsion, MD, cluster ID,
>     etc.) in its tractogram file. On top of that, some of these
>     metrics consist of more than one value, for instance the color is
>     in fact composed of three values (i.e. RGB). I find it a bit
>     wasteful to use up multiple tag names only because it is composed
>     of multiple values.
>
>     What I proposed is to encode that number of values in the tag name
>     at save time and take that encoded number into account when
>     loading a TRK file. I have two ways in mind and I would like your
>     opinion.
>
>     *1st approach*
>     A tag name can only have 20 characters/bytes. I would use the last
>     two bytes to encode the number of values associated to a given tag
>     name. The first byte would always be \x00 (EOL) so that TrackVis
>     doesn't try to interpret the last byte which will be set to the
>     number of values (since it is a uint8 the range is [0, 255]). The
>     upside of this approach is that TrackVis is not aware (read
>     doesn't crash) thanks to the \x00 "hack". The downside is that a
>     TrackVis's user will be less aware of what's going on behind the
>     scene but a NiBabel's user won't see a difference since we revert
>     the process when loading the TRK file.
>
>
> Just to check - how can you be sure when you find \x00 \x04 at the end 
> of the trackvis tag name, that this is really telling you this is a 
> nibabel hacked name with 4 values, rather than random cruft in the file?
>
> Cheers,
>
> Matthew
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20160531/22d5dba3/attachment.html>