I've gone through a few iterations re-working this code over the last month or so. The aparc+aseg (and wmparc) should respect the ribbon. So, voxels within the white surface but labeled as Cortex in aseg should be labeled as WhiteMatter in aparc+aseg. Voxels labeled as "None" should also be re-labeled as Cortex or WhiteMatter if they fall into those places on the ribbon.

There was a bug that was fixed in two stages, one on 8/6/08 and the other on 8/28/08. I'm not sure when our last stable version was cut, but we'll have a new version with these fixes in a few weeks.

doug



Michael Harms wrote:
Hi Doug,
I was comparing the aseg.mgz and aparc+aseg.mgz segmentations (FS
v4.0.2), and recalled a previous thread on this issue in which you
corrected me on an aspect of how the aparc+aseg.mgz is affected by the
surfaces.

>From what I can tell looking at this again, voxels labeled as "None" in
the aseg.mgz are also still ALWAYS labelled as "None" in the aparc
+aseg.mgz, even if those voxels are clearly interior to the final pial
surface.  However, voxels interior to the white surface that are labeled
as "Cortex" in the aseg.mgz get converted to "None" in aparc+aseg.mgz.
That is, it appears that a voxel must be in ribbon.mgz to be eligible
for one of the "ctx" parcellation labels in aparc+aseg.mgz, but not
necessarily all voxels in the ribbon will be labelled as "ctx" (some
will remain labeled as "None", apparently propagated from aseg.mgz).

Do I have this summary correct?

thanks,
Mike H.


On Tue, 2008-07-22 at 14:54 -0400, Doug Greve wrote:
  
Actually, the construction of aparc+aseg and wmparc do use info about
where the surface is to refine the aseg cortical boundaries. This
information is stored in ribbon.mgz (and it overrides the aseg
definition). At some point, we will use the surfaces to directly
refine the aseg boundaries.

doug




Michael Harms wrote: 
    
Hi Chris,
Doug, please correct me if I'm wrong, but the original gm/wm
segmentation contained in aseg.mgz is based on the 3D volume-based
tissue segmentation.  This original segmentation then forms the basis
for all subsequent additional segmentations of either GM or WM in the 3D
volume.  That is, aparc+aseg.mgz and wmparc.mgz make "use" of the
surface based parcellation, but only to decide the most appropriate
label to assign to GM/WM as defined in the already existing volume-based
segmentation that is contained in aseg.mgz.

Thus, since the GM/WM in aparc+aseg.mgz and wmparc.mgz is still based on
the 3D volume segmentation, there is no apriori reason that their
spatial extent will correspond precisely to the more accurate gray and
white mattes surfaces that come out of the surface-based processing
stream. (Although certainly we would hope that the discrepancies don't
become too large).

cheers,
Mike H.

On Thu, 2008-07-17 at 12:00 -0500, bell0368@umn.edu wrote:
  
      
I have sent two images created with the following commands.

tkmedit $subjid brainmask.mgz lh.white -aux T1.mgz -aux-surface rh.white 
-segmentation (aparc+aseg.mgz and wmparc.mgz) 
$FREESURFER_HOME/FreesurferColorLUT.txt

The wm segmenations go through the "main surface" and the "orig surface" 
into the gray matter, for example in the rh-supramarginal and 
rh-postcentral. From your last response I am unsure as to which pipeline 
creates the wm parcellations, the volume-based pipeline (.i.e aseg.mgz) or 
the surface-based pipeline (i.e. ribbon.mgz) or some combination of the 
two. It seems to me that the gm/wm parcellations are created using the 
surface pipeline and then transferred to the closest class-matched voxels 
from Left-Cerebral-Cortex and Left-Cerebral-White-Matter aseg 
segmentations. I guess the question is how are we getting from the surface 
parcellations back to volume space; is there a binary?
  In a related vein, the value from aseg.stats "surface-based-volume mm3 
lh-cerebral-white-matter" seems to be created with mri_segstats or is it 
from mris_wm_volume? Thanks for all your help!

Chris Bell





On Jul 17 2008, Doug Greve wrote:

    
        
When the volume is created, a decision has to be made at each voxel as
to what to classify it as. This is used when the aseg.mgz and
ribbon.mgz are created. aparc+aseg.mgz inherit these decisions from
these files. When using mri_segstats with --pv, it will take the
volume of a 1mm3 voxel and divide it up so that it can contribute to
more than one region. But there's not a way to put the partial volume
information into the segmentation itself. Not sure why that do not
appear alingned, but we've been recently looking into this for other
reasons. Can you send a pic.?

doug



On Wed, 16 Jul 2008, bell0368@umn.edu wrote:

      
          
I was wondering how the calculations of the wm volume were performed as 
well. The six values below are volume values from aseg I believe. I 
assume mris_wm_volume does more than sub-divide these regions into the 
wm parcellations, but probably also includes partial volume estimations 
along the wm/gm surface, is this correct? I basically have the same 
question for the gm volume values in aparc.stats; do they include 
partial volume calculations from the gm/pial and gm/white borders? Which 
binary is used to create these values for gm in aparc.stats... is it 
mri_segstats (with --pv)? I was assuming it would be an mris (surface) 
calculation as well. I am asking because if you use tkmedit to view the 
?h.surface files and load the aparc+aseg or wmparc segmentation volumes 
in also, the surfaces and the segmentations don't seem to line up. Is 
there a way to create a segmentation volume that includes 
partial-volumed voxels at the gray/white and gray/pial boundries? Thanks 
for your help.

Chris Bell




the interior voxels are only included in the volume if they are one of 
the following in the aseg.mgz:

  case Left_Cerebral_Cortex:
       case Right_Cerebral_Cortex:
       case Left_Cerebral_White_Matter:
       case Right_Cerebral_White_Matter:
       case Left_WM_hypointensities:
       case Right_WM_hypointensities:

cheers,
Bruce



On Tue, 15 Jul 2008, Marin Richardson wrote:

  OK, so aparc.stats is better for cortical gray matter. I want to look 
at the
  parcellated white matter volumes as well - is the only/best option to 
use the
   wm volumes from wmparc.stats?

  Also, when using mris_wm_volume to calculate total white matter, I 
saw the
  result defined as the volume within the white matter surface minus 
non-WM
   structures?   Can you tell me which regions are and are not included?

  Marin




              Doug Greve <[EMAIL PROTECTED]> 7/15/2008 12:02 PM >>>

   It is better to use the aparc as it is derived from surface
   measurements, which have sub-voxel resolution. The wmparc.stats are
   generated by counting 1mm^3 voxels.

  doug

  Marin Richardson wrote:


      Hi all,

       I noticed that the gray volumes for parcellated cortical regions 
in
       wmparc.stats are different from those for the same region in 
aparc.stats (e.g.
      ctx-lh-middletemporal = 8419 in wmparc.stats, middletemporal = 
9466 in
      lh.aparc.stats). Why are the values different and which one is a 
better
       measure to use?

       Thanks,
       Marin






_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer



        
            
      
          
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
    
        
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


  
      
-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
greve@nmr.mgh.harvard.edu
Phone Number: 617-724-2358 
Fax: 617-726-7422

In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting

    


  

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
greve@nmr.mgh.harvard.edu
Phone Number: 617-724-2358 
Fax: 617-726-7422

In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting