This post, along with Matt's earlier one triggered the important point that the CIFTI file format is coming along very fast -- progressing quickly from "nice idea in theory" to "David and Matt are using this all the time." It's covers a lot of data types:
http://www.nitrc.org/plugins/mwiki/index.php/cifti:ConnectivityMatrixFileFormats While I still tend to be very caret5-centric, because I'm wrapping up a multi-year project started in caret5, I know I need to start understanding this stuff. On May 29, 2013, at 10:40 PM, Colin Reveley <[email protected]> wrote: > thanks. > > It didn't occur to me to just open it. > > Sure enough the caret extensions are just text in there. > > That should provide a really simple solution, as long as the behavior is > predictable. > > Each user gets a novel volume. We can't keep header properties like this > between operations on the data. So it has to go through CARET first if we > want process it in that easy way, or else we have to build a header ourselves > which I'd feel safer with. > > But it looks nice thank you very much. I guess if we find we can't keep it > consistent in testing we'll maybe follow up. > > thanks again > > Colin > > > On 30 May 2013 02:52, Colin Reveley <[email protected]> wrote: > Hi - > > re: wb_command -volume-label-import > > what it appears to do is just vaporize the header. > > However, much could have gone wrong. The input volume is wholly constructed > in software (mainly imageJ and inhouse C) and is probably weird (although > it's been saved in CARET before trying to run this. I tried both ways. header > below has been through caret). and maybe I've got the format of the label > list wrong. > > I note that the output of the command is a float volume. I was pretty sure > paint volumes had to be unsigned char. I tried both float and uchar as inputs > anyway. > > my input header looks something like this. and my label file looks like what > follows under the header > > thanks for advice > > I appreciate it may not work. That is ok. It was a bit too good to be true > anyway. it doesn't dump core, or give an error (or any info at all). it just > thinks for a bit, removes most info from the header and outputs a float volume > > actually there's probably a debug swtich. I'll look at that now. > > thanks, > > Colin > > sizeof_hdr: 348 > data_type: > db_name: > extents: 0 > session_error: 0 > regular: r > dim_info: 0 > dim: 3 137 347 245 1 1 0 0 > intent_p1: 0.000 > intent_p2: 0.000 > intent_p3: 0.000 > intent_code: 1002 > datatype: 2 > bitpix: 0 > slice_start: 0 > pixdim: 1.000 0.250 0.250 0.250 0.000 0.000 0.000 0.000 > vox_offset: 41760.000 > scl_slope: 1.000 > scl_inter: 0.000 > slice_end: 0 > slice_code: 0 > xyzt_units: 0 > cal_max: 0.000 > cal_min: 0.000 > slice_duration: 0.000 > toffset: 0.000 > glmax: 0 > glmin: 0 > description: > > aux_file: > qform_code: 3 > sform_code: 3 > quatern_b: 0.000 > quatern_c: 0.000 > quatern_d: 0.000 > qoffset_x: -2.750 > qoffset_y: -48.750 > qoffset_z: -26.500 > srow_x: 0.250 0.000 0.000 -2.750 > srow_y: 0.000 0.250 0.000 -48.750 > srow_z: 0.000 0.000 0.250 -26.500 > intent_name: > magic: n+1 > > Intent Name: NIFTI_INTENT_LABEL > Intent Parameters:Label index > > First Voxel XYZ (method 1): 0.000, 0.000, 0.000 > Spacing: 0.250, 0.250, 0.250 > > QFORM: NIFTI_XFORM_TALAIRACH > 1.000 0.000 0.000 0.000 > 0.000 1.000 0.000 0.000 > 0.000 0.000 1.000 0.000 > 0.000 0.000 0.000 1.000 > Orientation: Left to Right, Posterior to Anterior, Inferior to Superior > First Voxel XYZ (Method 2): -2.750, -48.750, -26.500 > Spacing: 0.250, 0.250, 0.250 > > SFORM: NIFTI_XFORM_TALAIRACH > 0.250 0.000 0.000 -2.750 > 0.000 0.250 0.000 -48.750 > 0.000 0.000 0.250 -26.500 > 0.000 0.000 0.000 1.000 > Orientation: Left to Right, Posterior to Anterior, Inferior to Superior > First Voxel XYZ (Method 3): -2.750, -48.750, -26.500 > Spacing: 0.250, 0.250, 0.250 > > Data Type: NIFTI_TYPE_UINT8 > > Space Units: NIFTI_UNITS_UNKNOWN > Time Units: NIFTI_UNITS_UNKNOWN > > Extension 1 before byte swap > Size: 22816 > Code: 4 > Extension 1 after byte swap > Size: 22816 > Code: 4 > AFNI extension: > Extension 2 before byte swap > Size: 18592 > Code: 30 > Extension 2 after byte swap > Size: 18592 > Code: 30 > > > --- > > F3 > 107 50 5 240 255 > 8Bm > 77 50 10 5 255 > ABmc > 31 50 10 155 255 > Ig > 51 50 30 115 255 > G > 161 50 30 140 255 > Ld > 119 50 40 45 255 > LIPv > 20 50 40 120 255 > Ia > 87 50 55 15 255 > > > > _______________________________________________ > caret-users mailing list > [email protected] > http://brainvis.wustl.edu/mailman/listinfo/caret-users _______________________________________________ caret-users mailing list [email protected] http://brainvis.wustl.edu/mailman/listinfo/caret-users
