Nick wrote:

> Hi Ziad,
>
> ziad wrote:
>
> > You are correct, 1D is no good for header info preservation.
> To
> > preserve header information, NIML is the way to go. But
> > unfortunately there is no matlab API for it. Parsing a niml
> > element is relatively simple, look at function
> afni_nel_parse.m
> > for an example. Also, one could as you suggest relatively
> > easily write ASCII NIML format but it would be a hack and if
> > the library changes your matlab version might break.
>
> I had a look at afni_nel_parse.m and ToyTalk.m (pretty cool
> btw), but these also seem to require ASCII NIML format. You say
> that's a hack, i.e. the ASCII format is not official and may
> change in the future?

No the ASCII format is part of the NIML (NeuroImaging Markup Language, a simplified XML based format that allows binary data - Bob's own) standard. It would be easiest to write a matlab ASCII only NIML API. If you encounter binary NIML elements you can pass them through a C command line converter first.
btw: I assume you're familiar with the tools demonstrated in @drive_afni, @drive_suma, and @DO.examples ...

>
> In any case, I could not find anything about encoding in [1];
> is there more documentation available?

There is a NIML description here [afni.nimh.nih.gov] . The rest of the documentation is in the code...

>
> > The best
> > way would be to write a MATLAB API that uses AFNI's minl
> > C-library directly. But I am not sure how much work that
> would
> > be.
>
> A lot of work for me, probably, as I'm quite good in reading C
> but not very good in writing it. So writing something entirely
> in matlab may be easier for me.

A NIML ASCII only I/O in matlab should be relatively easy.

>
> > The advantage of a NIML API is that you can use it to
> > communicate with AFNI and SUMA. That is why afni_nel_parse
> was
> > written; to communicate with SUMA. But if all you want is
> I/O,
> > then perhaps you should use GIFTI (
> > [www.nitrc.org] ). THe surface-based
> NIFTI
> > equivalent.
>
> Had a look at the specification, nice work. Seems like a pretty
> cool format spec to me.
>
> For future work, I have two different aims.
>
> 1) easier visualization and better organized data storage of
> surface analysis results. Currently I have tables with z and t
> scores hanging on the wall of my office which is not exactly
> using all of the potential computational power under my desk.
> Furthermore with a large number of result columns (frames) it
> becomes easy to confuse different analyses. So for this reason
> I'm looking for a better way of data storage than 'dumb' than
> .1D files
NIML or GIFTI would help there. GIFTI is more portable, that is why I recommended it. But don't get me wrong, I'd love to have a NIML API in matlab!

>
> 2) development of a matlab toolbox for surface analyses that
> preferably supports a general data format. I'm collaborating
> with a few people who use SPM / caret, and currently the
> toolbox supports suma ascii surface and .1D data files well,
> while nifti and caret require some dirty hacks. We would like
> to write something that is more general than that.
>
> It seems that for (1), a niml I/O would be best. For (2), gifti
> seems more appropriate. Does that make sense?

GIFTI is fine for both 1 and 2. AFNI and SUMA have GIFTI support built in.

> In addition, what does NIML mean for using AFNI/SUMA programs?
> A lot of the 3d* programs support .1D but not NIML, right?

That's wrong, AFNI programs that work with .1D take in .niml.dset. Many programs also output niml formatted files if you add .niml.dset to the prefix.

In
> other words, what do I lose in terms of AFNI application
> support if I would store data in NIML?

NOTHING.

>
> > GIFTI will be supported by a decent number of
> > surface-based software (Caret, BrainVoyager, FreeSurfer,
> > BrainVisa, AFNI/SUMA etc.).
>
> "*will* be supported" - what's the current status? As far as I
> know AFNI/SUMA do not support gifti, is that correct? Are there
> any plans for, say, gifti - niml conversion support?
GIFTI support is pretty solid in all these applications. There are some aspects still being ironed out.
In terms of GIFTI <--> NIML conversions, SUMA's ConvertSurface and ConvertDset programs can do it for you. Note that some of the header content in NIML format is not supported by the GIFTI standard, so some things will get lost in the translation.
>
> > Guillaume Flandin has generously written a matlab API for I/O
> > of geometry (surfaces) files. Perhaps your effort would be
> most
> > fruitful in expanding it to deal with data on the surfaces.
> > This expansion should be relatively simple, as the mechanisms
> > for parsing and encoding are already there. I suspect this
> > route would be best for everyone.
> > [www.artefact.tk]
>
> Yes, that looks like fine code to me, and as far as I
> understand the gifti format from the specification, adding
> support for data files would require adding support for certain
> headers right?
Pretty much yes.

>
> With respect to the previous goals, do you think it would be
> hard to write a gifti to niml conversion tool? Then I could do
> analyses with gifti files but view the results in niml.

See above.

>
> Well, I have to remind myself that my PhD is in cognitive
> neuroscience and not in computer science.... seems there is
> still a lot to implement.

That is why I figured GIFTI might be a better bet for you, though I would love to have someone write a NIML API in matlab!

>
> > As you probably know, I will be at Princeton Jan. 27 until
> Jan.
> > 29. If you like we can discuss this at length there.
>
> Thanks, but unfortunately I don't work in princeton anymore;
> I've started a PhD in Bangor in north Wales (UK), you know,
> where it rains so much. Yes, I would like to discuss a few
> things, but I'm afraid it will have to be over the internet. In
> any case, I hope you have a good time during your princeton
> visit.
>
> Thanks a lot for your comments, and I look forward to hearing
> your thoughts.
>
> best,
> Nick
>
> [1]
> [afni.nimh.nih.gov]

Opps, I guess you found the manual already.

cheers,
z