On Tue, Aug 6, 2013 at 9:13 AM, Mark Plantz <markplantz2016@u.northwestern.edu> wrote:

I think that the registration turned out ok [well it isn't upside down]. I attached a few screenshots.

My bbregister command is:

bbregister --s CMH-8169 --mov /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz --init-fsl --reg /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat --t1 --o /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz

Subsequently, my mri_label2vol command is:

ingvalsons-imac:~ IngvalsonLab$ mri_label2vol --seg /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz --temp /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz --reg /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat --o /Users/IngvalsonLab/Desktop/output.mgz

Number of labels: 0
Annot File: (null)
Template Volume: /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz
Outut Volume: /Users/IngvalsonLab/Desktop/output.mgz

Registration File: /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat
Fill Threshold: 0
Label Vox Vol: 1
ProjType: (null)
ProjTypeId: 0
ProjStart: 0
ProjStop: 0
ProjDelta: 0.1
Subject: (null)
Hemi: (null)
UseNewASeg2Vol: 1
DoLabelStatVol 0
LabelCodeOffset 0

setenv SUBJECTS_DIR /Applications/freesurfer/subjects
$Id: mri_label2vol.c,v 1.34.2.5 2012/06/08 17:31:03 greve Exp $
Template RAS-to-Vox: --------
-1.000 0.000 0.000 128.000;

-0.000 -0.000 -1.000 128.000;
-0.000 1.000 -0.000 128.000;
0.000 0.000 0.000 1.000;
Template Voxel Volume: 1
nHits Thresh: 0
Loading registration from /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat

RegMat: --------
-0.994 -0.098 0.042 0.715;
0.043 -0.001 0.999 -14.682;
0.097 -0.995 -0.005 2.026;
0.000 0.000 0.000 1.000;
Label RAS-to-Vox: --------

0.994 0.098 -0.042 127.285;
-0.097 0.995 0.005 125.974;
0.043 -0.001 0.999 113.318;
0.000 0.000 0.000 1.000;
ASeg2Vol: Building LUT
ASeg2Vol: Sorting

ASeg2Vol: Mapping
ASeg2Vol: Reverse Map
nmisses = 9739499 (73560 filled)
ASeg2Vol: done
ingvalsons-imac:~ IngvalsonLab$

Is it significant that number of labels = 0? Or is that because I am using a segmentation volume instead of an actual .label file?

Other than that, I cannot seem to determine why the output images would be inverted by 180 degrees.

Thank you in advance
MP

On Mon, Aug 5, 2013 at 4:26 PM, Douglas Greve <greve@nmr.mgh.harvard.edu> wrote:

did you look at the registration with tkregister2? When bbregister finished, it would have printed out the command line to run (it is also at the end of the log file). If that looks ok, please send your bbregister command.
doug

On 8/5/13 1:47 PM, Mark Plantz wrote:

Thanks Doug. mri_label2vol worked well, except it looks like all of the files are inverted by 90 degrees. They appear inverted in both tkmedit and 'FreeView.' I read that inversions are common in "fslview" but not in tkmedit. Any idea what could be causing this problem?

My command line is:

mri_label2vol --seg /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz --temp /Users/IngvalsonLab/Desktop/temp.mgz --o seg_new.mgz --reg register.dat

I didn't encounter any errors with mri_label2vol nor bbregister [which was used to generate register.dat and temp.mgz].

Any ideas what could be causing this problem?

I can attach more images if this one doesn't portray the inversion well.

Thanks a lot

MP

On Mon, Aug 5, 2013 at 10:12 AM, Douglas Greve <greve@nmr.mgh.harvard.edu> wrote:

The file that you pass it with the --reg option is the registration file (eg, --reg register.dat). This can be used for input to mri_vol2vol or mri_label2vol. mri_label2vol is appropriate for a segmetation

doug

On 8/5/13 10:22 AM, Mark Plantz wrote:

Thank you. Do you know how to access the transform that is outputted by bbregister. I am just obtaining an output volume <volume.mgz>>?

On Thu, Aug 1, 2013 at 3:56 PM, Bruce Fischl <fischl@nmr.mgh.harvard.edu> wrote:

Hi Mark

you can use the transform that bbregister outputs and give it to mri_convert with -at <transform name>

cheers

Bruce

On Thu, 1 Aug 2013, Mark Plantz wrote:

One last question: Is there any flag I can use with 'bbregister' that
prevents the labels from changing in my segmentation volume? This is
occuring because the volume that I am moving has labels. For some reason,
the labels change ever so slightly in the output file.

On Thu, Aug 1, 2013 at 2:28 PM, Bruce Fischl <fischl@nmr.mgh.harvard.edu>
wrote:
glad it worked out
Bruce
On Thu, 1 Aug 2013, Mark Plantz wrote:

Just as an update, it turns out that my segmentation
volume had been
slightly altered during the conversion from .nii to
.mgz. I completely
forgot to use the -rt nearest flag to prevent the
labels from becoming
distorted. That is why the segmentation looked so
fuzzy with various regions
labeled incorrectly.
Apparently, I should check the basics before
overcomplicating the problem,
haha. Thanks for the help everyone!

On Thu, Aug 1, 2013 at 9:36 AM, Mark Plantz
<markplantz2016@u.northwestern.edu> wrote:
Sounds good. I also just realized that the
segmentation values
are varying from 0-255, which makes me think
that the file is
only designed for the grayscale/heat/etc.
settings [where 0 is
darkest regions and 255 is brightest regions].
Is that a valid
assumption? Also, if this is the case, would
it be impossible to
create a .gca file using mri_ca_train with
these files?
Thanks for the help.

MP

On Wed, Jul 31, 2013 at 8:43 PM, Douglas Greve
<greve@nmr.mgh.harvard.edu> wrote:

Just make sure that you create a new file and
do not
repeat index numbers.

On 7/31/13 2:02 PM, Mark Plantz wrote:
That makes sense. Wouldn't that cause there to
be
some overlap between different regions, since
the
same index #'s used by the two programs
(FreeSurfer
& MRIcro) correspond to different brain
regions?

On Tue, Jul 30, 2013 at 12:50 PM, Douglas Greve
<greve@nmr.mgh.harvard.edu> wrote:

for every line in that file, you will need to
create a line in the new LUT, something like

8 Frontal_Mid_R 0 255 0 0

This will make the right mid frontal green =
(0,255,0)

On 7/30/13 9:55 AM, Mark Plantz wrote:
Hmm, so I received the text part of the
LUT. Looks like this is completely
different from the segmented regions
that we would want. [attached]. Can't
seem to understand how this text file
could be related to the default
FreeSurfer LUT. It looks like the
labeling for an AAL map. This probably
wont' work will it?
- Mark

On Tue, Jul 30, 2013 at 8:47 AM, Bruce Fischl
<fischl@nmr.mgh.harvard.edu> wrote:
the UNC one? No, you should ask
them
On Tue, 30 Jul 2013, Mark Plantz
wrote:

---------- Forwarded message
----------
From: Mark Plantz
<markplantz2016@u.northwestern.edu>
Date: Tue, Jul 30, 2013 at
8:39 AM
Subject: Re: [Freesurfer]
infant atlas segmentation
To: Bruce Fischl
<fischl@nmr.mgh.harvard.edu>

Just opened up the default
FreeSurferColorLUT.txt file.
So it looks like all
I have to change is the #No.
column of the file, to match
the ones in the
other LUT used.
I actually just received the
MRIcro .lut file from the
UNC group. [attached]

Hopefully this will help
with the conversion.
However, I still have to
figure out how to open the
file. Any ideas?

On Tue, Jul 30, 2013 at 8:25
AM, Bruce Fischl
<fischl@nmr.mgh.harvard.edu>
wrote:
Hi Mark

creating a FreeSurfer
LUT really isn't that hard.
Have you
looked at our standard
one? Probably we have the
names you
already want and you
just need to change our
indices to match
the ones in your
segmentation file (and save
it as a different
LUT)

cheers
Bruce

On Tue, 30 Jul 2013,
Mark Plantz wrote:

Turns out that
the files had been labeled
using a
color LUT in a
program
called MRIcro. I
am now installing this
program
simply to access
the LUT.
Will it be as
simple as exchanging the
index values
from this LUT to
a
custom LUT in
FreeSurfer?

On Tue, Jul 30,
2013 at 12:35 AM, Douglas
Greve

<greve@nmr.mgh.harvard.edu>
wrote:

The
problem is that you need to
create a
completely new
LUT. The
labels
that get displayed with the
standard
LUT are going to
be
totally
random with respect to what
they
should display.

On 7/29/13
2:20 PM, Mark Plantz wrote:
Hi Doug,
Thanks for the
reply. I will definitely go
into
the LUT and
change those
values to some specific
region. My main
concern is
that I think all
of these "out of bounds"
labels are
the
symptoms of some
larger problem. The
segmentation
looks very
strange as
compared to a typical
segmentation (i.e.
an
'aseg.mgz'
file). In fact, the
segmentation appears
to be
labeling
"left-<region" in the right
hemisphere.
Have you seen a
segmentation
file that looks like the
once I
attached before?
I
am used to
seeing segmentation files
such as the one
attached to
this e-mail.

- Mark

On Mon, Jul 29,
2013 at 12:28 PM, Douglas
Greve

<greve@nmr.mgh.harvard.edu>
wrote:

Mark, the
only thing that is wrong
with the
out of
bounds
regions is that they are not
represented in
the LUT.
Once you add an index
corresponding
to the
index of
the segmentation to the LUT,
it will
not
show up as
"out of bounds". The brain
mask has
nothing to
do with it.
best
doug

On 7/29/13
12:50 PM, Mark Plantz wrote:
Sorry
about that. I received the
manual

segmentations from aUNCmedicalgroup<http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-in
fan
t-0-1-2
-atla
ses>. I
actually asked the main
researcher
about the
out of bounds regions. He
thinks
that as
long as the segmented file
lines up
with the
input volumes, a few out of
bounds
regions
might be OK. However, these
seg
volumes
look very different from a
typical
.aseg
volume that I am used to
seeing after
recon-all
is run.
Maybe the
segmentation is simply
incompatible with
FreeSurfer?

Thanks for the
help. These files are a
nightmare!

- MP

On Mon, Jul 29,
2013 at 11:40 AM, Bruce
Fischl

<fischl@nmr.mgh.harvard.edu>
wrote:
can you cc
the list please? Maybe we
should
start over. Where did you
get the
manual
segmentations from?

On Mon, 29
Jul 2013, Mark Plantz wrote:

Ahh,
right. So it looks like
the
red regions appear to be

averaged around 248. I am
not
sure why that is the
case
or if it has
any
significance. I attached
a
screen shot for

reference.

On
Mon, Jul 29, 2013 at

11:29 AM, Bruce Fischl

<fischl@nmr.mgh.harvard.edu>

wrote:

it isn't a

registration file. You

should just specify it as a

volume on the freeview

command line, the same as

brainmask.mgz

On Mon, 29 Jul 2013,
Mark
Plantz wrote:

I actually tried
to
view the brainmask.mgz
file
with the segmentation
file
[Freeview calls it

'registration

file' I believe].

For some reason,
the
file will load without

segmentation, but when I

attempt to add the

registration

file, I get an

error

message:

"Failed to load
MRI

~/.../../../brainmask.mgz

Could this

potentially be part of the

problem?

Thanks

MP

On Mon, Jul 29,
2013
at 10:57 AM, Mark

Plantz

<markplantz2016@u.northwestern.edu>

wrote:

It looks
like
the values vary from

20-120 depending on which

region I run the cursor

over.

However, aren't

those the

values
that
correspond to the

brain.mgz regions? Is there

another way to find the

segmentation

values?

On Mon, Jul 29,
2013
at 10:37 AM, Bruce

Fischl

<fischl@nmr.mgh.harvard.edu>

wrote:

I mean the

segmentation values that
give
you the "out of bounds"

message

On Mon, 29
Jul
2013, Mark Plantz wrote:

Hi

Bruce,

Do
you
mean the brainmask.mgz

values? I'm not sure what
the
segmentation #'s exactly
are.

Thanks!

MP

On
Mon,
Jul 29, 2013 at 10:17
AM,
Bruce Fischl

<fischl@nmr.mgh.harvard.edu>

wrote:

Hi
Mark

what #s are those

segmentations? It should be

trivial to just add them to
the
end of

the

LUT.
I
wouldn't let them be

out of bounds as there

might be code around that

might ignore them then.

cheers

Bruce

On
Mon, 29 Jul 2013, Mark

Plantz wrote:

Hi Doug,

Thanks for
the
reply. After doing some

research, it looks like

messing

with the

LUT

might be a

risky decision [and
way

out of my

abilities!].

If I were to use
this
segmentation file to

create a .gca atlas using
the

command

mri_ca_train, do you

think it would yield

problems or b
...

[Message clipped]