Dear freesurfers,
I'm trying to exploit CUDA capabilities by using recon-all with -use-gpu.
On the freesurfer wiki I found an approximate speedups for the main CUDA
implementations in Freesurfer (
http://ftp.nmr.mgh.harvard.edu/fswiki/CUDADevelopersGuide).
But I can't found mri_watershed_cuda and
Hi Marcel,
First, you will find a lot of details about the usage of mri_cvs_register
if you use the --help flag in the terminal.
See detailed responses to your questions below:
I'm trying to use mri_cvs_register (whose registration accuracy is, by the
way, jaw-dropping) for EPI images. Ho
Hello Lilla,
thank you the clarifications. I managed to get mri_vol2vol running, but I
have one remaining obstacle - when I use the CVS template as target volume,
the EPIs get resampled to 1mm isotropic voxels. I need to get a 3x3x3mm
resolution. I tried to use mri_convert -vs 3 3 3 norm.mgz norm3
Thank you for your answer, Doug.
Cheers,
Marcos
Em Qua, 2013-08-07 às 19:32 -0400, Douglas N Greve escreveu:
> Hi Marcos, we're not really set up to do this kind of thing. The
> subcortical structures in fsaverage are not appropriate for
> surface-based analysis. We do not generate surface for s
you could try using --scale to scale the intensities of the
001.mgz up
On Wed, 7
Aug 2013, Abid Qureshi wrote:
I'm using 4.5.0. The earliest subjects were done using 4.5.0 so for consistency
we are sticking with 4.5.0. -
Abid
On Wed, Aug 7, 2013 at 6:52 PM, Bruce Fischl wrote:
Hi
Dear Freesurfer experts,
We are using mri_glmfit and wanted to compare our results to qdec to
decide which method we prefer for group analysis. The results are
consistent between the two methods, except for the monte carlo results.
When we run mri_glmfit-sim to do the monte carlo simulations
Hi Doug,
Thanks for the response. Is this masking out of the cortical regions in the
volume analysis a newer aspect of the processing stream? Previously I have seen
this activation in the volume.
It would be great if you could let me know the flags to see the full volume
analysis.
Thanks!
E
Hi Marcel, We have encountered this problem before, but we have not come
up with the perfect solution yet. As you dais, either the volume gets
resampled twice or the high res tranformation needs to be downsampled.
Neither of these is ideal, but I am planning on implementing applying the
morph
> Hello,
>
> I am working with freesurfer to segment MRI images and I need to obtain a
> binary mask of the Corpus Callosum. Using the aseg.mgz file I was able to
> identify it segmented into 5 different structures (labels 251 to 255).
> However when looking at the mask of the union of those 5
Thank you Lilla, this explains my case. The accuracy of mri_cvs_register is
legendary and incorporating this into standard fMRI processing pipeline is
most desirable:) Could you please inform the group once this feature is
implemented? Thank you!
Best regards,
Marcel
2013/8/8 Lilla Zollei
>
>
The 001.mgz actually looks good in this case (in terms of intensity) so
I'm not sure if it makes sense to scale it up further. The problem is with
the nu.mgz being too dark. I'll try it out though if you think it will
also work in this case.
- Abid
---
you could try using --scale t
Hi João
I'm not sure I understand. What is wrong with the cc? Note that mri_cc
takes a parameter (-t I think) that specifies how far
laterally the cc should extend. Is that what you mean - that it doesn't
extend laterally far enough?
cheers
Bruce
On Thu, 8 Aug 2013, Joao Pedro Battistella
maybe try scaling up the orig.mgz then? I never really understood why the
nu darkens it sometime. Alternatively you could scale up the nu, but you
will have already lost dynamic range
On Thu, 8 Aug 2013,
aqure...@nmr.mgh.harvard.edu wrote:
> The 001.mgz actually looks good in this case (in ter
Hi David - The fact that it's taking so many tries to initialize the left
ILF tells me that something has gone wrong with the data, either with the
T1 to DWI registration, or with the mask, or something like that. Have you
looked at any of the output files of the pre-processing? The FA map, th
QDEC does not do its own calculations, it uses mri_glmfit and
mri_glmfit-sim, so any differences you are seeing are due to differences
in the parameters used to run the analysis. QDEC creates a glmdir output
folder. You can check if the two methods have the same design by
comparing the Xg.da
I think it is because n3 sometimes creates a few voxels that are very
bright (or can't handle a very bright voxel that is there), then the
conform step ends up compressing a lot of voxels into the dark range to
handle the few bright voxels. I put some stuff in recon-all to try to
reduce the ef
Run mri_preproc with the -no-subcort-mask option
Before you do that, delete the mni305 files in your run directories,
otherwise it will not regenerate them.
doug
On 08/08/2013 11:17 AM, Emily Boeke wrote:
> Hi Doug,
>
> Thanks for the response. Is this masking out of the cortical regions
> in
Hi again, Raja.
Which labels and meshes to use depends on what you want to do. If you
extract all the priors corresponding to all the labels in the atlas (the
list is in $FREESURFER_HOME/data/GEMS/compressionLookupTable.txt), you
would have a volumetric version of the atlas (rather than a mesh)
Hello,
I can confirm that mri_watershed_cuda, mri_ca_label_cuda and some of the
other mri*cuda binaries on that list have not been included the previous
freesurfer release, or any the the recent releases. Also, looking at the
CVS log history for mri_watershed I do not see any mention of cuda go
Hello Experts,
This QDEC error is one that appears in the archives, but I did not see a
solution that solves my problem. The error (after some information about
initialization of the program) is as follows:
SUBJECTS_DIR : /home/freesurfer_ocd
Parsing the .stats files
ERROR: The stats file /hom
Dear freesurfers,
I am experimenting qdec with one of my discrete variables. Besides
qdec.table.dat file, I do have a .levels file with the two levels of the
variable (say level1 and level2). However, I keep getting the following
error message:
Reading discrete factor levels from config file
/$SU
Okay. I'm still a little unclear. So I'm looking at the compression lookup
file (left in this case) and seeing this:
24 2 CSF 60 60 60 255
2 0 Left-Cerebral-White-Matter 0 225 0 255
3 1 Left-Cerebral-Cortex 205 62 78 255
17 3 Left-Hippocampus 220 216 20 255
550 5 lef
V
ery funny indeed...so, just for absolute clarification is there a
one-to-one correspondence between the order listed in the mesh collection
and the order in the lookup tables? i.e. does label 2 (CSF) correspond to
position -1 (reference)? Does label 8 (left subiculum) correspond to
position 9?
A
Hi all,
I need to perform segmentation of the whole Corpus Callosum but I don't really
know how the determine which thickness should I use to extract all of it (or at
least most of it).
Does anyone know what would be typical thickness of CC (the distance along
coronal axis) or if is there a wa
How did you create the levels file? Eg, did you use a windows computer?
Or did you use msword or some other word processor. If not, can you send
the levels file?
On 08/08/2013 03:49 PM, ye tian wrote:
> Dear freesurfers,
>
> I am experimenting qdec with one of my discrete variables. Besides
> qd
Ken, can you send the offending file and the file from the 6th subject?
doug
On 08/08/2013 03:09 PM, Rando, Kenneth wrote:
> Hello Experts,
>
> This QDEC error is one that appears in the archives, but I did not see
> a solution that solves my problem. The error (after some information
> about in
Dear Doug,
It is a mac. I made the meditation.levels file using emacs.
emacs meditation.levels --> type "Normal" (level1) --> hit enter --> type
"TM" (level2) --> save file
Thank you very much!
Sincerely,
Ye
On Thu, Aug 8, 2013 at 4:22 PM, Douglas N Greve
wrote:
> How did you create the lev
When I looked at orig.mgz it is actually too bright. It's very hard to
differentiate white and gray matter from how bright the image is. Maybe
that is the root of the problem. I tried correcting it with mri_convert
like this:
cp orig.mgz holder_orig.mgz
mri_convert --scale 3 holder_orig.mgz orig.m
Hi Abid
--scale specifies a floating point number to multiply each voxel intensity
by, so --scale 0.5 will make every intensity half as much
cheers
Bruce
On Thu, 8 Aug 2013, aqure...@nmr.mgh.harvard.edu wrote:
> When I looked at orig.mgz it is actually too bright. It's very hard to
> differen
29 matches
Mail list logo
