Hi Rick,
thanks for your quick reply.
rick reynolds Wrote:
-------------------------------------------------------
>
>
> 1) It seems that an attribute of the read dataset
> (the
> binary aspect) is stored for the INDEX_LIST upon
> read,
> and that overrides the request to write it as
> text.
The GIFTI dataset used as input is in ASCII format; the relevant part is:
<DataArray ArrayIndexingOrder="RowMajorOrder"
DataType="NIFTI_TYPE_INT32"
Dim0="4"
Dimensionality="1"
Encoding="ASCII"
Endian="LittleEndian"
ExternalFileName=""
ExternalFileOffset=""
Intent="NIFTI_INTENT_NODE_INDEX">
<MetaData>
</MetaData>
<Data>8 7 2 3 </Data>
but also removing the "Endian" field still gives binary node indices. Is there anything else you mean by the "binary aspect" in the input?
>
> While there options to ponder regarding that, let
> me
> suggest using simply 3dcopy (or other 3d*
> programs),
> but with the AFNI_NIML_TEXT_DATA env var set to
> YES:
>
> 3dcopy -DAFNI_NIML_TEXT_DATA=Y dset.gii
> dset.niml.dset
Thanks, that works very well. Still, wouldn't it make more sense if Convertdset with "-o_niml_asc" would only write ASCII data, not binary?
> Out of curiosity, how did you even notice this?
> Did
> you encounter software that cares?
I didn't encounter software that cares; I tried Convertdset, nibabel and the Matlab GIFTI toolbox, and they all seem to be fine with the NODE_INDEX field as the last DataArray. I noticed the issue when some experimental modifications I made to existing Matlab code made ConvertDset crash; to track this down I read the GIFTI standard documentation in detail and compared it with the output from Convertdset; that's how I found it. (The reason I crashed ConvertDset was due to a feature in experimental code; ConvertDset seems to be working fine otherwise).
best,
Nick
