TODO and Bugs


Jump to: navigation, search

NOTE: This page is out of date.

Bugs should be reported on the Vistasoft GitHub page:

Related pages:



Get remove SVN directory into everybody's path

Simplify the analysisScripts directory in mrDiffusion

Create visualization directory for DTI stuff. Implement simple visualizers for bvecs and related. Build up from existing surface code that is in the GUI already.

Continue the validate development.

ROI management tools. Both selection and visualization.

Make it easy to create an m2html manual every so often (monthly?)

Training scripts for reading data sets. These scripts will be similar to the v_ (validate) scripts that show how to read in, visualize and do simple computations.

USER-CENTERED TUTORIALS: These tutorials should bring a person (e.g., a new collaborator) to do basic computations using the software by streamlining a step-by-step analyses. Ideally these analyses should go from data collected raw to a graph.

Initial projects

Make it easy to put up a mesh from a NIFTI that contains a set of points close to a surface. Probably use itkGray or possibly FSL's viewer.

Create a tool for reading out a ROI from multiple NIFTI files

Visualize the TBSS skeleton (see Jessica and Michael)


This page is for reporting on bugs in mrVista. Although we would love for the code to be completely bug free, and spend a significant amount of time working on maintaining stability, we are realistic about the likelihood that you will encounter a bug at some point.

Please follow the instructions below to report a bug. Most of the principal developers watch this page, meaning we will be notified when this is edited; so adding a report to this page will have the same latency of response as sending an email, but may reach more people. (It will also help other users who can also be aware of what's being buggy lately.) As we fix bugs, we will mark the fix here, and try to provide details if necessary. The actual fixed code will be uploaded to our SVN repository.

When should I report a bug?

Although we hate bugs, we welcome people reporting them. It's much better to know about one than not know about one. However, it helps us a lot to know if a bug is generally reproducible, and to know as many details about how you encountered it as possible.

Therefore, we ask that you do the following before reporting a bug:

  • Make sure the bug persists if you restart MATLAB and repeat your steps;
  • If possible, ensure that it happens on more than one data set;
  • Check the Troubleshooting page to see if this an issue with a known fix;
  • Provide a description of the bug, the steps you took to encounter the bug, your computer operating system and MATLAB version, how often you have encountered the bug, and any error messages that MATLAB may produce
  • If possible, try downloading a sample data set and see if you can reproduce the bug on that data set.

Many thanks.

How do I report a bug?

The VISTASOFT software is now on github. We manage bug reports and pull requests there.

You should also download the current version from that site.

Bugs / Known Issues, by MATLAB version


MATLAB r2008a

  1. Building meshes on MATLAB r2008a under linux produces a strange glitch in the rendered mesh (the mesh is shifted around the mid-coronal plane). May be specific to particular machines / graphics cards. (Tested on moach.)


MATLAB r2006b

  1. build_mesh MEX-file does not seem to work.
  2. mrFlatMesh The unfold code gets hung up. This bug doesn't seem to reoccur with newer versions of MATLAB.

MATLAB r2007b

  1. myCinterp3 MEX-file does not seem to work. Recompiling does not appear to fix the bug.
  2. mrManDist MEX-file (w32) does not crash but returns null values. If you try code which calls this function -- for instance, makeROIdiskGray which makes an ROI disk, all disks will be exactly one voxel in size.


TR off on Windows

Initializing from Lucas Center mag files on Windows boxes, the frame period (TR) would sometimes be off by a factor of 10.

  • FIXED 08/2007: an obsolete file to read mag headers was floating around the KGS lab, not part of the main repository. This file has been deleted.

Initial display of mesh crashes: crashes in mrmInitMesh stage the first time you load a mesh, need to re-display it.

  • FIXED 09/02/2007: small bug fix.

Flattening Code Issues

mrFlatMesh crashes / gets hung up at the stage in which it allocates large matrices (some step early in unfoldMeshFromGUI )

  • Fix 06/23/2008: there were actually 2 bugs: one occurred when it tried to compute the area of each triangle (in order to produce some output figures), and another is when allocating a large sparse matrix froze up (in find3DNeighbourDists ). The first bug was code-related; it was fixed by adding a TRY/CATCH loop. The second bug was found to be MATLAB-related; version 2006a apparently had problems with the double sparse method, but r2006b and newer worked.

.dll crashes on 32-bit Win boxes

Some compiled functions which had previously worked on 32-bit windows boxes now fails ( mrManDist , Nestares alignment routines). This also seems to affect some compiled SPM functions which we use ( spm_bsplinc ). It's also machine-specific: some machines are ok, other machines have the problem, despite similar architectures.

    • Partial Fix 09/10/2007: Some of the problem seems to be the new myCinterp3.mexw32 mex file. This was created recently during the same recompile as for the 64-bit processors (*.mex64). Unforunately, on my machine at least, the 32-bit version crashes. Removing it, and relying instead on the older file (myCinterp3.dll) fixes the problem.
    • Update 8/01/2008: For MATLAB r2007a and later, none of the .dll files work, and the solution is to recompile the required MEX files. This is needlessly complicated right now (sometimes using the MEX command alone works, sometimes not); this bug will be considered fix when there's a simple, reliable way to compile everything before getting started. (I envision a function named something like mrVistaCompile which you run the first time you use it, which compiles and checks all the needed files.) For MATLAB r2006b and earlier, the .dll files seem to be more stable, and the main issue is probably just their being shadowed by .mexw32 files that other people have compiled and checked in. (So, if you're reading this, Please don't check in Windows .mexw32 files.)

mrInit2 crashes for file patterns

Selecting the 'Add File Pattern...' button to add a set of images (such as ANALYZE files) in the mrInit2 GUI causes the code to crash.

  • Fixed 05/15/08: code update fixed this bug.

Mex file problems

This is a set of ongoing problems with MATLAB mex files, in which the files will not work on particular operating systems and MATLAB systems. As of fall 2008, the lab will look into a combined fix for these issues.

grow_gray just plain doesn't work.

I've tried various MEX versions of this file on Windows and linux, and have not gotten it to work consistently. I haven't heard from anyone who has gotten it to work. I grow a gray graph using mrGray and save the result for use in segmentations. Sayres 13:10, 22 September 2008 (PDT)

Can not use NIFTI files as segmentations.

Bob wrote some code to read in segmentations saved as NIFTI files. This hasn't worked for me. After asking around the lab, I see that some people have used this successfully, while for others (as well as myself), it simply does not work. I see on the Anatomical_Methods page that people use VTKGray to segment, then go through mrGray for the last steps.Sayres 13:08, 22 September 2008 (PDT)

rmPlotGUI no longer works for modeling all time points.

  • Fixed 06/26/08: the problem had to do with the stimulus specification step. When stimuli are produced, the stimulus images are cropped to exclude regions where no stimulus was present--but the sampling grid (params.analysis.X and Y) are not updated to reflect the change. This didn't create problems if you made the stimulus once, but if you remade the stimulus (e.g. to generate all time points in a fitting), they got out of synch. I recommend keeping the stimulus and sampling grid closer together (in the structure) to make sure they're not dissociated.

Applying a 'deconvolution' GLM to a data set doesn't work

This bug was reported by folks at SKERI a few weeks ago: although the 'deconvolve' option works in the Time_Course UI, if you try to use this option and apply a GLM to a whole data set, the code crashes badly. I have checked in a few changes that can prevent the crash for small data sets, but there is still an issue of running out of memory. I have also not been able to fully debug the fix, so I am not marking this bug as fixed just yet. Sayres 23:27, 23 September 2008 (PDT)

Cannot use Update Mesh or 'Recompute Vertex/Gray Map' on matalbr2006a (64-bit linux)

While using matlabr2006a, I come across this error after using "Recompute vertex/gray maps" on a loaded mesh:

Setting distThresh to 2 Masking out layers > 1 ??? Invalid MEX-file '/home/alinal/vistasoft/trunk/mrAnatomy/VolumeUtilities/nearpoints.mexa64': /home/alinal/vistasoft/trunk/mrAnatomy/VolumeUtilities/nearpoints.mexa64: undefined symbol: mxCreateNumericMatrix_700.

Error in ==> mrmMapVerticesToGray at 126 [v2gMap, sqDist] = nearpoints(double(vertexCoords'), double(grayCoords'));

??? Error using ==> MSH = viewGet(VOLUME{1}, 'Mesh'); vertexGrayMap = mrmMapVerticesToGray( meshGet(MSH, 'initialvertices'), viewGet(VOLUME{1}, 'nodes'), viewGet(VOLUME{1}, 'mmPerVox'), viewGet(VOLUME{1}, 'edges') ); MSH = meshSet(MSH, 'vertexgraymap', vertexGrayMap); VOLUME{1} = viewSet(VOLUME{1}, 'Mesh', MSH); clear MSH vertexGrayMap Invalid MEX-file '/home/alinal/vistasoft/trunk/mrAnatomy/VolumeUtilities/nearpoints.mexa64': /home/alinal/vistasoft/trunk/mrAnatomy/VolumeUtilities/nearpoints.mexa64: undefined symbol: mxCreateNumericMatrix_700.

??? Error while evaluating uimenu Callback

Thanks- Alina 12:24, 25 September 2008 (PDT)Alina

Thanks for posting that, Alina. I've added that this bug seems to happen specifically on 64-bit linux, with that version of MATLAB. Recompiling the MEX files is the obvious fix, but can be time-consuming and a pain; see Troubleshooting#Compiling.2FMEX_issues for more info on that. However, a simpler solution is to try newer MATLAB versions, and see if it works.

The long-term solution is to have a script compile all MEX files for your OS and version of MATLAB. This is underway, but will likely take a few months to be useable. I'll mark here when something like that solution becomes available. Cheers, Sayres 12:34, 25 September 2008 (PDT)

problem viewing contrast map in inplane window after computing

here are the conditions in which i can replicate the bug:

  1. start mrvista on the following subject: W:\projects\Kids\fMRI\localizer\[session communicated privately]
  2. compute contrast (ctrl+4) on the GLMs datatype scan1 (example: child man > indoor outdoor abstract cars)
  3. i can now see the bicolor colorbar but no voxels that pass my threshold even though i know they are there from previous contrasts.
  4. however if i load another parameter map of another contrast, i can see the correct overlay

i wasn't able to replicate this bug on another dataset --when i computed the same contrast, the overlay loaded fine and there was no issue. but, even after SVN updating and restarting matlab a couple of times, i keep getting the same error on this particular dataset. something i noticed that may or may not be related is a warning printed to the command window:

Warning: Log of zero.
> In log10 at 20
In glm_contrast at 180
In computeContrastMap2 at 160
In contrastGUI>callComputeContrastMap at 550
In contrastGUI at 31
Saved Contrast Map in
Time to compute map: 0 min, 35.8 sec.

Reply: Hi Davie, thanks for letting me know. I just checked the data, and the described map loaded fine. The issue appeared to be the cothresh slider: the map may have been saved with some unusual data loaded into the 'co' slot. (On your screenshots, I see it's set to 0.40, which -- if you're using the cothresh to restrict both sides of a contrast -- is quite high.)

I fixed the map. If something like this crops up again, you can repeat the steps I took:

  1. Set the cothresh slider to zero.
  2. Load the map. (All the data should display; this was true before as well.)
  3. Select the bicolor cmap: right-click on the color bar, and select "Bicolor (Winter + Autumn)".
  4. Save the map again: File | Parameter Map | Save Parameter Map. (It's okay to save over the old version.)

Just to clarify: the bicolor map includes a shortcut to map both sides of the contrast into the 'co' slot. It does the following steps: takes the absolute values of the contrast map, and divides by 100 (to fit in the range [0 1]). So, to threshold by, say, p < 10^-5, you just need to click out 5 steps: cothresh=0.05. (There's also a menu option in the File menu to do this explicitly, without futzing with the color map; the bicolor call just does several convenient steps together. You can also always use the map window, and look at one side of the contrast at a time.)

Hope this clears things up. Cheers, Sayres 00:48, 10 October 2008 (PDT)

Talairach coordinates are "pulled" backward and left

When I run mrGray(after alignment using mrAlignMI) and create Talairach coordinates the system consistently distorts the coordinate system so the (0,0,0) point is at the posterior apex of the left ventricle, rather then at its proper place.thanks. Opher 03:27, 9 December 2008 (PST)

Reply: Hi Opher, thanks very much for reporting this. I'm a little unclear on the bug, though. Is this in mrGray, or in a mrVista gray window? (I'm not sure if mrGray deals with Talairach coordinates). Also, are you using the 'computeTalairach' tool to look up the Talairach coordinates for a point, or have you actually applied a Talairach transform to an anaatomy. Thanks much. Sayres 09:57, 9 December 2008 (PST)

Hi Rory, thanks for the prompt response and sorry that I took so long to get back to you.The bug is when I create a Talairach coordinate system for the brain in the 3-view volume window of mrVista- I confused it with the Gray window.Opher 01:17, 14 December 2008 (PST)

mrVista Volume Window Mesh Bugs

Volume: ROI-> create-> createDiskRoi(Choose start point)

This problem applies to several subjects in my project directory: Biac2/kgs/projects/Kids/fmri/localizer (adults # 2, 4, 5, 6, 7, 8, 9, listed alphabetically). I tried to create a disk ROI in the gray view volume window from a posterior point in that subjects fusiform gyrus. However, it always creates the disk centered around some point that is a lot more anterior and lateral. For example, if I tried to enter the start coordinates for the ROI as (104, 171, 119) the disk center would jump to position (143, 118, 117). This is a description of what happens in the right hemisphere. The left hemisphere is even stranger, so if I pick a start point in the left posterior fusiform e.g. (72, 177, 130), it still creates a disk in the anterior RIGHT hemisphere (140, 128, 116). The error seems very systematic but at the same time totally incomprehensible.

Update: After looking through the code, I realized the the coordinates of the cursor position are not pulled correctly if the radio button on the view is not set to Sag on the mrVista volume 3-view window (getCurSlice does not get a unique value if the radio button selects Cor or Axi instead; one of the coordinates is repeated and the disk shows up in some other place). Can't think of a quick way to fix it for the moment, so I'm "unimplementing" the options that don't work -- now an error will result directing you to select the Sag button. Is it ok to just leave it at that? --Davie 12:27, 30 December 2008 (PST)

Gray-> Mesh ROI-> GetCursorPositionFromMesh

This problem applies to several subject in: biac2/kgs/projects/Kids/fmri/localizer (adults #1, 3, 10, 11, listed alphabetically). First, I am on the mesh and use Toggle Mesh Cursor to pick a point in the anterior temporal lobe (e.g. anterior tip of collateral sulcus). Then, I go back to the gray view volume window and try to get the coordinates of that cursor position by using : 'get cursor position from mesh.' However, it will not report the coordinates and instead throws an error. It only does this if I put the mesh cursor in a point on the anterior portion of the temporal lobe, it happily reports coordinates from more posterior locations. It only does it for some of the subjects listed above. When I tried to choose 'recompute vertex', matlab didn't appear to do anything i.e. there was no progress bar as there is usually, but no error was shown. Alina will take a look as well, but we are not optimistic about figuring this one out on our own. I have included the error below:

??? Subscript indices must either be real positive integers or logicals.

Error in ==> meshCursor2Volume at 42

   volCoords = volView.coords(:,layerOneVolumeIndex)';

??? Error using ==> pos = meshCursor2Volume(VOLUME{1}); VOLUME{1} = viewSet(VOLUME{1}, 'CursorPosition', pos); VOLUME{1} = refreshScreen(VOLUME{1}); Subscript indices must either be real positive integers or logicals.

??? Error while evaluating uimenu Callback

??? Subscript indices must either be real positive integers or logicals.

Error in ==> meshCursor2Volume at 42

   volCoords = volView.coords(:,layerOneVolumeIndex)';

??? Error using ==> pos = meshCursor2Volume(VOLUME{1}); VOLUME{1} = viewSet(VOLUME{1}, 'CursorPosition', pos); VOLUME{1} = refreshScreen(VOLUME{1}); Subscript indices must either be real positive integers or logicals.

??? Error while evaluating uimenu Callback

Update: Bob had a look, and we realized that meshCursor2Volume was failing because it required the cursor position to fall within the zone where functional data was collected (where layer 1 node positions are computed). We therefore checked in a change to the code that would translate any cursor position to a volume coordinate, even if the layer 1 node position was not computed, by grabbing the cursor position at the gray/white boundary (which is about 1mm off from where the layer 1 node position would be). The larger problem is that I would like nodes computed for locations in the gray matter that extend beyond the locations where fMRI data was collected. Some information on where in the mrVista code nodes are computed, and ideas for how to compute and store a gray matter graph even where functional data was not collected would be very welcome! --Davie 12:34, 30 December 2008 (PST)

Resolved ~01/2009: Met with Davie and clarified how the mapping worked.

Personal tools