Hi Ziad,

ziad wrote:
>>[Nick wrote:]
>> thanks again for your reply on the message board.
>> As I wrote there, I implemented a quick and dirty niml parsing
>> routine
>> that seems to work.
>> It's quite a hack and I would like to work more on it, but for
>> now it
>> can read at least *some* files.
>>
> That's good. Want to include them in the distribution? I so,
> make sure you credit and reference yourself for help in the
> help output.

I'm happy to include it in the distribution, but I think it's better if I work a bit more on it first in order to:
- clean up the code
- document the code
- implement a function that *writes* niml files (should be quite easy now)
- test the code on a few more datasets

>> As you can read on the message board, I have troubles with a
>> .niml.roi
> file. Any idea how to parse such a file?
> Sure. The format of the data is still a table, but the last
> column contains a vector, rather than one element. NIML allows
> you to store a column or arbitrary structure, and that can get
> complicated. You could choose not to parse some elements based
> on ni_type.

Yes, that may be wise.

> So, in this case ni_type is SUMA_NIML_ROI_DATUM
> searching for this string in the AFNI/SUMA code, you find
> something like this:
> SUMA/SUMA_SVmanip.c:2119: cf->nimlROI_Datum_type =
> NI_rowtype_define("SUMA_NIML_ROI_DATUM",
> "int,int,int,int[#3]");
> The last chunk shows that the datum in made up of 3 ints ( int,
> int, int ) followed by an int vector that is N elements long,
> where N is obtained from the 3rd element (3rd int).
> So if you want to read such an element, you need to know what
> SUMA_NIML_ROI_DATUM is and the only way to do it is to look in
> the C code.

Right, that makes it more complicated. Even *if* this would be implemented based on the C code, if the c code changes (which, if I understand correctly, is more or less the documentation, specification and reference implementation of the niml format), then the matlab function would not work anymore.

> Beyond reading this, interpreting the meaning of these ints and
> int vectors is a whole new ball of wax. This data format keeps
> track of the 'brushstrokes' used in drawing an ROI. It also
> stores multiple ROI that can overlap. If you just want a
> labeled dataset (one ROI value at each node) version of the
> ROI, you are better off calling ROI2dataset and making it write
> out the output in .niml.dset form. That output should be
> readable with your functions.

That seems like a much better idea. Personally I'm only interested in labelled datasets, so that would suffice. If others want to read a specific type of datasets like the ROI one (i.e. with a specific SUMA_* or other tag in ni_type), then this could be added later.

> Example:
> setenv AFNI_NIML_TEXT_DATA YES
> ROI2dataset -prefix ROI1.niml.dset -input ROI1.niml.roi

Cool, that's sweet. Maybe it's a good idea to support this directly, i.e. in case it finds such a ROI type it runs this ROI2dataset automatically? The same can be done with binary data I think (run ConvertDset from matlab).

About the file format:
- NIML files can have '#' as comments at the beginning of the line. Can I replace those by spaces? Or do they have meaning? Can they occur if the data is a string?

- can NIML files have mixed types of ascii and binary? For example one block with ascii data and the other with binary data?

thanks again for your help. I hope to have something ready next week.

best,
Nick