hello again,
When using caret_command to do a -volume-map-to-surface i seem to be getting a bunch of zeros in the output metric file with at least some mapping algorithms. If i use caret_map_fmri version 5.51 I don't get zeros. Specifically, the command that produces non-zeros is: caret_map_fmri -a EV -v test.nii -s test.spec test.topo test.coord -m test.metric and the command that produces zeros is: caret_command -volume-map-to-surface test.coord test.topo \"\" test.metric METRIC_ENCLOSING_VOXEL test.nii note that the .coord and .topo files that i am using in both cases were produced by Caret 5.51. test.spec, test.topo, and test.coord are available at: http://rapidshare.com/files/152231400/test.spec.html http://rapidshare.com/files/152231401/test.topo.html http://rapidshare.com/files/152231402/test.coord.html test.nii is the same as before. in case it's useful, in attempting (and failing) to debug the problem, i observed what may be inappropriate units either being fed to or generated by the function convertCoordinatesToVoxelIJK. details below ----- in debugging the problem, i noticed that in the file BrainModelVolumeToSurfaceMapper.cxx, in the function getNeighborsSubVolume (which is called by some mapping algorithms), there is a call to convertCoordinatesToVoxelIJK. convertCoordinatesToVoxelIJK always returns FALSE in my case because it thinks the coordinates it is given are out of bounds. debugging convertCoordinatesToVoxelIJK, i notice that the numbers passed in as "xyz" seem to be in the thousands (i.e. numbers like 4150.34 -- probably in units of microns) whereas the result of getOriginAtCornerOfVoxel are in units of millimeters. the units of "spacing" are also millimeters. If, inside of convertCoordinatesToVoxelIJK, i temporarily replace the line: const float d = xyz[i] - originCorner[i]; with const float d = (xyz[i]/1000) - (originCorner[i]); then the output of convertCoordinatesToVoxelIJK is more reasonable (by which i mean, it doesn't return FALSE anymore). To me this suggests that the function convertCoordinatesToVoxelIJK should either be given its input in terms of millimeters, or should consult the header information and convert its input units if needed. however, even with the temporary modification, the result of caret_command -volume-map-to-surface is zeros, so there must be something else also. thanks, bayle ---------------------------------------- > From: [EMAIL PROTECTED] > To: caret-users@brainvis.wustl.edu > Date: Tue, 23 Sep 2008 12:00:00 -0500 > Subject: Re: [caret-users] Problem viewing NIFTI volume file in 5.6 > > Bayle, > > There are two ways to describe the coordinate system in a NIFTI volume > by using the qform_code and the sform_code. Your volume used only the > qform_code and Caret was processing it incorrectly. Some changes have > been made and Caret now appears to read your volume correctly. > > You can get an updated version of the caret5 executable from > "http://brainmap.wustl.edu/pub/john/ > ". Use the username "pub" and the password "download" to access the > website. There are three zip files whose names begin with > "caret5_exe" that contain updated versions of caret5. Download the > version appropriate for your operating system and install it. On > Windows, place caret5.exe in you Caret installations "bin_windows" > directory. On Linux, place caret5 in you Caret installation's > "bin_linux" directory. On Mac OSX, place caret5.app in you Caret > installation's "macosx_apps" directory. > > ----------------------------------- > John Harwell > [EMAIL PROTECTED] > > Department of Anatomy and Neurobiology > Washington University School of Medicine > 660 S. Euclid Ave Box 8108 > Saint Louis, MO 63110 > > > > > On Sep 23, 2008, at 8:27 AM, Donna Dierker wrote: > >> Hi Bayle, >> >> I removed your attachments and placed them in our upload directory, >> and >> I am forwarding your reply to caret-users that got held up due to >> message size constraints. I let the first attachment you sent >> through, >> because it was just a bit above the limit, but this message had three >> volumes attached exceeding 2.5Mb total. We don't want to fill up >> everyone's inbox. >> >> I'll try to have a look at this later today, but I wanted John Harwell >> to get a look before he takes a few days off later this week. >> >> Donna >> >> -------- Original Message -------- >> Subject: RE: [caret-users] Problem viewing NIFTI volume file in 5.6 >> Date: Tue, 23 Sep 2008 01:21:10 +0000 >> From: Baylis Shanks >> To: Caret, SureFit, and SuMS software users >> >> >> >> >> hi, >> >> thanks for looking into it. >> >>> When I view it in AFNI, I do see something that might be mouse cortex >> >> yes, it's mouse cortex, and that is what it is supposed to look >> like :) >> >> >>> R-to-L extent: 5688.600 [L] -to- 5700.000 [L] -step- 0.200 mm >>> [ 58 >>> voxels] >>> A-to-P extent: 7786.800 [P] -to- 7800.000 [P] -step- 0.200 mm >>> [ 67 >>> voxels] >>> I-to-S extent: -2700.000 [I] -to- -2692.000 [I] -step- 0.200 mm >>> [ 41 >>> voxels] >>> ... >>> If the voxdims are really cubic .2mm, which is consistent with the >>> mousy >>> look of what AFNI shows, then the field of view should be 11.6x13.4 >>> mm >>> -- not what is shown above. >> >> by "what is shown above", you meant this, right? >> >> there are indeed supposed to be 58, 67, and 41 voxels along the R-L, >> A-P, and I-S directions. the value of the "dim" header field is >> [ 3 58 67 41 0 0 0 0] (i think -- that is the >> value that i tried to put in there, but bear in mind that since i >> created the file i could have written out the header incorrectly). >> >> on to the displacement. i was trying to make the origin be the >> anterior commissure, which i believe to be near 5.7, 7.8, 2.7 mm. >> >> what are the units of the numbers 5700, 7800, 2692? my intent was >> for them to be microns. the values of the NIFTI header fields >> qoffset_x, qoffset_y, qoffset_ z are (i think) -5700, -7800, and >> -2700 respectively. the value of the NIFTI header field xyzt_units >> is (i think) NIFTI_UNITS_MICRON. but perhaps the units of the >> qoffset_* fields were supposed to be units of millimeters? >> >> 5700-5688.6 is 11.4, which is pretty close to 11.6 (58*.2 = 11.6) -- >> so it seems like 3dinfo is interpreting the 5700 as mm, and >> subtracting 11.4 mm from it to get the 5688.6. >> >> so, i tried changing header fields but i haven't yet figured out how >> to completely fix the problem (read on for details). >> >> before talking about that, i'd like to note something strange i >> noticed in the Caret's Volume Attributes Editor when viewing the >> original file that i included in the previous email, test.nii (when >> loading it as an Anatomy volume). The dialog shows the "Dimensions" >> as 1 in each direction, "Voxel Size" as 200, and Origin as -57, -78, >> and -27. This is odd, because one would think that the Voxel Size is >> correct and is displayed in units of microns, but one would think >> that Origin would be either -5700, -7800, -2700 (if the qoffset >> header fields are being read as microns and displayed as microns) >> -5700000, -7800000, -2700000 (if the qoffset header fields are being >> read as mm and displayed as microns), or it should be -5.7, -7.8, >> -2.7 (if the qoffset header fields are being read as microns and >> displayed as mm). >> >> now, i will describe the results of trying to change some of the >> header fields, yielding new test files (attached). >> >> first, i tried to simply scale the qoffset fields. I replaced -5700, >> -7800, -2700 with -5.7, -7.8, -2.7. The result is file test2_5.7.nii >> (attached). Caret has the same problem as before. Caret's Volume >> Attribute Editor shows "Dimensions" as 1 in each direction, "Voxel >> Size" as 200, and Origin as -0.057, -0.078, and -0.027. Again, this >> is odd; I would have expected one of 5700, -7800, -2700 (if the >> qoffsett header fields are being read as mm and displayed as >> microns) -5.7, -7.8, -2.7 (if the qoffset header fields are being >> read as microns and displayed as microns), or it should be -0.0057, >> -0.0078, -0.0027 (if the qoffset header fields are being read as >> microns and displayed as mm). >> >> second, i tried setting the header field xyzt_units to >> NIFTI_UNITS_MM. I changed the pixdim header field from [200 200 200] >> to [.2 .2 .2], and i left the qoffset fields as -5.7, -7.8, -2.7 >> (test3_mm.nii, attached). Now Caret displays something, and it even >> looks to be centered near the origin! However, the display looks too >> small for some reason, and the Volume Attributes Editor shows >> Dimensions as 286, 331, 201, Voxel Size as .2, .2, .2, and Origin as >> -57, -78, -27. So, both the Dimensions and Origin field seems to be >> wrong. >> >> third, i tried leaving xyzt_units as NIFTI_UNITS_MM, leaving the >> pixdim header field as [.2 .2 .2], and rescaling the qoffset fields >> by a factor of ten, to -.57, -.78, -.27, hoping to make the Origin >> fields in Caret's Volume Attributes Editor come out right (test4_mm_. >> 57.nii). Loading this file into Caret, you can see something, but it >> is really tiny, and not centered at the origin. The Volume >> Attributes Editor shows Dimensions as 286, 331, 201, Voxel Size as . >> 2, .2, .2, and Origin as -5.7, -7.8, -2.7. So, now if the units in >> the Volume Attributes Editor are interpreted as mm, the Voxel Size >> and Origin are both correct, however the Dimensions are still wrong. >> >> thanks, >> bayle >> >> >> ---------------------------------------- >>> Date: Fri, 19 Sep 2008 08:33:33 -0500 >>> From: [EMAIL PROTECTED] >>> To: caret-users@brainvis.wustl.edu >>> Subject: Re: [caret-users] Problem viewing NIFTI volume file in 5.6 >>> >>> Hi Bayle, >>> >>> Your problem replicates on my end -- i.e., I get an empty volume >>> when I >>> view test.nii in Caret (see test.nii.caret.jpg). >>> >>> When I view it in AFNI, I do see something that might be mouse cortex >>> (see test.nii.afni.jpg). >>> >>> The header does look unusual. Here is AFNI's 3dinfo output: >>> >>> it.wustl.edu 30% 3dinfo test.nii >>> ++ 3dinfo: AFNI version=AFNI_2007_05_29_1644 (Jan 29 2008) [64-bit] >>> >>> Dataset File: test.nii >>> Identifier Code: NII_-z--ofl-dASZaHy2pulrNg Creation Date: Fri Sep >>> 19 >>> 08:26:32 2008 >>> Dataset Type: Anat Bucket (-abuc) >>> Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST] >>> Storage Mode: NIFTI file >>> Storage Space: 637304 (637 thousand) bytes >>> Data Axes Tilt: Plumb >>> Data Axes Orientation: >>> first (x) = Left-to-Right >>> second (y) = Posterior-to-Anterior >>> third (z) = Inferior-to-Superior [-orient LPI] >>> R-to-L extent: 5688.600 [L] -to- 5700.000 [L] -step- 0.200 mm >>> [ 58 >>> voxels] >>> A-to-P extent: 7786.800 [P] -to- 7800.000 [P] -step- 0.200 mm >>> [ 67 >>> voxels] >>> I-to-S extent: -2700.000 [I] -to- -2692.000 [I] -step- 0.200 mm >>> [ 41 >>> voxels] >>> Number of values stored at each pixel = 1 >>> -- At sub-brick #0 '?' datum type is float >>> >>> If the voxdims are really cubic .2mm, which is consistent with the >>> mousy >>> look of what AFNI shows, then the field of view should be 11.6x13.4 >>> mm >>> -- not what is shown above. >>> >>> Let's start by verifying the voxdims and field of view. >>> >>> Donna >>> >>> On 09/18/2008 05:17 PM, Bayle Shanks wrote: >>>> Hi, I'm having trouble viewing the attached NIFTI functional volume >>>> file (test.nii) in Caret 5.56. I can view it fine in Caret 5.51. >>>> >>>> What happens is that when i open the file, there are no errors but >>>> it >>>> looks empty. The three coordinate selectors at the top (to the >>>> left of >>>> the D/C button) are each at 0 and can't be changed. >>>> >>>> I created the file >>>> myself so it's possible that it doesn't conform to the NIFTI >>>> standard >>>> in some way (of course, if so i'd like to correct that). >>>> >>>> I'm using Debian 2.6.18-6-amd64 (64-bit) (a mix of Debian stable and >>>> unstable). >>>> >>>> I've tried building Caret from source and also running the binary >>>> distribution. I've tried caret5 and also caret5_mesa. With >>>> caret5_mesa, some errors are displayed on the console (not sure if >>>> I was >>>> using CARET_DEBUG), I've copied them below. >>>> >>>> thanks, >>>> bayle >>>> >>>> ----- >>>> Time to read .caret5_preferences (0.00209236 MB) was 0 seconds. >>>> Caret Home Directory: /usr/local/caret >>>> NIFTI extension[0] 0 >>>> Unscaled range: 0 10.9652 >>>> Scaled range: 0 10.9652 >>>> >>>> OpenGL Error: invalid enum >>>> At end of drawBrainModelPrivate(). >>>> While drawing brain model VOLUME - test.nii >>>> In window number 0 >>>> Projection Matrix Stack Depth 1 >>>> Model Matrix Stack Depth 1 >>>> Name Matrix Stack Depth 0 >>>> >>> >> >> _________________________________________________________________ >> See how Windows Mobile brings your life together—at home, work, or >> on the go. >> http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/ >> >> _______________________________________________ >> caret-users mailing list >> caret-users@brainvis.wustl.edu >> http://brainvis.wustl.edu/mailman/listinfo/caret-users >> > > > _______________________________________________ > caret-users mailing list > caret-users@brainvis.wustl.edu > http://brainvis.wustl.edu/mailman/listinfo/caret-users _________________________________________________________________ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
