thanks Tim, Matt I see what you mean about endianness. It does look like that in the workbench window. And thanks matt, possibly gifti lib is not up to date here.
as I posted surf2surf seems to fix it. That said it would be as well to know why in the interests of robustness and future proofing. It does look like endianness to the eye. Since surf2surf 5.04 resolves it I'll look at what changed. thanks again Colin On 23 August 2013 16:23, Colin Reveley <[email protected]> wrote: > actually it seems as simple as > > surf2surf -i <problem>.surf.gii -o <fixed>.surf.gii > > appears to fix it up so that caret5 will load matlab gifti saved surfaces. > > I was worried that moving the vertices in my script might have badly > broken the face defintions. Apparently it is fine. It actually works!! > > best, > > Colin > > On 22 August 2013 22:33, Colin Reveley <[email protected]> wrote: > >> I should say: it loads in workbench. it just doest work. >> >> images (gifti in matlab, same in workbench) attached. also the header I'm >> trying to load. You'll see the header has quite a lot of detritus. >> >> best >> >> Colin >> >> >> On 22 August 2013 22:24, Colin Reveley <[email protected]> wrote: >> >>> hi. >>> >>> we have a system (a bespoke system) for non-linear registration of >>> volumes. >>> >>> we wondered if we could take the output transform and use that data to >>> shift the vertices of a surf.gii so that it's transformed. >>> >>> much like wb_command and fnirt. >>> >>> we tried it. in matlab (using gifti lib) it works. >>> >>> unfortunately the resulting surface renders in matlab, but when saved >>> not in caret or workbench. >>> >>> there are a million reasons why that could be. And I'm happy to mess >>> with the headers till it works. >>> >>> but before i do I wondered if there might be an in-principle problem: >>> >>> we move the vertices. but the face definitions remain the same, as in >>> >>> gii = >>> >>> vertices: [211995x3 single] >>> mat: [4x4 double] >>> faces: [423986x3 int32] >>> >>> is that the basic problem, or is it just a question of messing with the >>> xml till caret or workbench accepts it? >>> >>> I accept it's complicated. But our code does appear to work in terms of >>> moving vertices and aligning to a nifti within matlab, so unless the face >>> definitions are the fundamental issue for loading in caret5/7 (mainly >>> caret5 for the moment) I can just twiddle with headers till it loads >>> hopefully. >>> >>> but if it's the faces I have a bigger problem. >>> >>> best wishes >>> >>> Colin >>> >> >> >
_______________________________________________ caret-users mailing list [email protected] http://brainvis.wustl.edu/mailman/listinfo/caret-users
