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