Re: [caret-users] medial wall override via caret_command

2015-08-19 Thread Donna Dierker
Could you elaborate on how you are using caret_command?

The Enable Medial Wall Override affects display, which is not applicable using 
caret_command, unless you are using -show-scenes, in which case you would 
select the medial wall paint column as an overlay on top of your functional 
overlay, in order to gray out the medial wall.  It gets more complicated if you 
want to exclude the medial wall from processing, but isn't too hard (search for 
"select" in the caret_command full help output).


On Aug 19, 2015, at 3:13 PM, "Yang, Daniel"  wrote:

> Dear Caret Experts,
> 
> In Paint Main, I can check “Enable Medial Wall Override” to gray out medial 
> wall. Is it possible to do so via caret_command?
> 
> Many thanks!
> Daniel
> ___
> 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


[caret-users] medial wall override via caret_command

2015-08-19 Thread Yang, Daniel
Dear Caret Experts,

In Paint Main, I can check “Enable Medial Wall Override” to gray out medial 
wall. Is it possible to do so via caret_command?

Many thanks!
Daniel
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users


Re: [caret-users] doubt regarding fiducial mapping

2015-08-19 Thread Donna Dierker
If you can find your *.params file, then don't worry about the find command, 
which was intended to help you locate it if you did not know its name/location 
already.

I looked at your dataset, and you must do two things to help me help you:

* Remove the spaces from the filenames.  Replace them with _ characters.  When 
I try to read, move, or otherwise manipulate these files, the spaces are 
misinterpreted by the Linux shell as separate arguments.

* Add the *.params file.

After you've made those changes, rename the directory john_renamed.  Then zip 
it and upload it.  I'll do my best to solve it.


On Aug 19, 2015, at 1:23 AM, j...@nbrc.ac.in wrote:

>> Hello Donna,
> 
> 1.I ve tried taking the XYZ min values from .PARAMS file and transformed
> the overlay. This appears very subjective and error prone.
> 
> 2. "Do this in your subject directory:
>> 
>> find /my/subject/dir -name "*.params" |sort | xargs grep -i min
> "
> 
> I am not sure i understood this step properly
> 
> 
> I am unable to coregister the functional image and anatomical image properly.
> I am sorry to trouble you again , but it would be great if you can take a
> look at the dataset again, which i have uploaded in a folder " data from
> john.zip" at http://pulvinar.wustl.edu/cgi-bin/upload.cgi
> 
> I doubt now that there is some issue within the procedure that we follow
> in doing the analysis. So it would be best if you can check/reanalyse the
> dataset from very initial step itself.
> 
> PS:
> -anatomical image.hdr\img---unaltered structural T1 image.
> -functional.hdr\imgbasic SPM8  T2*image which is to be mapped
> 
> Thank you.
> 
> 
> 
> 
> On Aug 18, 2015, at 2:19 AM, j...@nbrc.ac.in wrote:
>> 
>>> Hello Donna,
>>> Thank you for your reply.
>>> Two doubts i have
>>> 1. why even after loading metric as primary overlay it is not getting
>>> 'selectable' here in functional view (see attachment "capture")?
>> 
>> The metric is a vertex-intensity mapping.  It is not the volume.  You can
>> load the volume that was mapped using File: Open Data File: Volume
>> Functional files.  Then it will be selectable when you map to loaded
>> volume.  Or you can simply map to file on disk without loading.  But it is
>> not a bad idea to load the volume, too, to make sure everything aligns
>> properly:  Functional with surface is the important one, but the
>> anatomical volume is the link between functional and surface (i.e., how
>> they get aligned).
>> 
>>> 2. what is the meaning of this error message (attachment 2), which
>>> appears
>>> on selecting the functional volumes?
>> 
>> Again, the funky file naming of two of the volume files (e.g., space,
>> parentheses, leading dashes) impedes my ability to check them quickly.
>> But the whole brain anatomical does appear to be a NIfTI volume, rather
>> than just an Analyze .hdr file.  I loaded it as a functional volume, and
>> then tried to map it to your surface.  I got the same result as trying to
>> map it from disk (clicking OK on the stickup you captured).
>> 
>> That warning never got removed after support for nifti .hdr/.img pairs was
>> added, but based on my getting the same results using the two paths
>> mentioned above, I think you will solve your problem when you solve the
>> misalignment between your cropped volume and the whole brain anatomical
>> volume.  Alternatively, shift the surface to meet the whole brain /
>> functional volume.
>> 
>> Ideally, get the following loaded and aligned in caret:
>> 
>> * whole brain anatomy volume
>> * functional volume overlay
>> * surface (probably shifted version of what you have now)
>> 
>> Do this in your subject directory:
>> 
>> find /my/subject/dir -name "*.params" |sort | xargs grep -i min
>> 
>> Capture it to a file if it's a lot.  One of those files has the offset you
>> need.
>> 
>>> thank you.
>>> 
>>> 
>>> Hi John,
 
 Got your upload.  While I couldn't open the cropped volume in caret due
 to
 the way it was named, I was able to view the surface contour over the
 uncropped volume.  See attached capture, which shows an offset.
 
 If you have a SureFit/Caret .params file (not included in the zip), it
 might contain the [XYZ]min values from the cropping, which might be
 used
 to either adjust the functional volume's origin, or more likely apply
 an
 affine transform to the surface, to shift it back into alignment with
 the
 whole brain volume.  You don't have to blow away your existing coord;
 just
 rename the shifted version to indicate the offset.  This can be done
 via
 command line or using the Caret: Window: Transformation Matrix editor.
 The polarity of the shift (+ or -) depends on whether you're shifting
 the
 volume or surface, and I always get confused about it.  Usually I try
 it
 one way; look at the result like the capture below; and if it looks
 worse,
 I try it the other way. ;-)  One of the ways usually does the trick.
>>>

Re: [caret-users] doubt regarding fiducial mapping

2015-08-19 Thread john
> Hello Donna,

1.I ve tried taking the XYZ min values from .PARAMS file and transformed
the overlay. This appears very subjective and error prone.

2. "Do this in your subject directory:
>
> find /my/subject/dir -name "*.params" |sort | xargs grep -i min
"

I am not sure i understood this step properly


I am unable to coregister the functional image and anatomical image properly.
I am sorry to trouble you again , but it would be great if you can take a
look at the dataset again, which i have uploaded in a folder " data from
john.zip" at http://pulvinar.wustl.edu/cgi-bin/upload.cgi

I doubt now that there is some issue within the procedure that we follow
in doing the analysis. So it would be best if you can check/reanalyse the
dataset from very initial step itself.

PS:
-anatomical image.hdr\img---unaltered structural T1 image.
-functional.hdr\imgbasic SPM8  T2*image which is to be mapped

Thank you.




On Aug 18, 2015, at 2:19 AM, j...@nbrc.ac.in wrote:
>
>> Hello Donna,
>> Thank you for your reply.
>> Two doubts i have
>> 1. why even after loading metric as primary overlay it is not getting
>> 'selectable' here in functional view (see attachment "capture")?
>
> The metric is a vertex-intensity mapping.  It is not the volume.  You can
> load the volume that was mapped using File: Open Data File: Volume
> Functional files.  Then it will be selectable when you map to loaded
> volume.  Or you can simply map to file on disk without loading.  But it is
> not a bad idea to load the volume, too, to make sure everything aligns
> properly:  Functional with surface is the important one, but the
> anatomical volume is the link between functional and surface (i.e., how
> they get aligned).
>
>> 2. what is the meaning of this error message (attachment 2), which
>> appears
>> on selecting the functional volumes?
>
> Again, the funky file naming of two of the volume files (e.g., space,
> parentheses, leading dashes) impedes my ability to check them quickly.
> But the whole brain anatomical does appear to be a NIfTI volume, rather
> than just an Analyze .hdr file.  I loaded it as a functional volume, and
> then tried to map it to your surface.  I got the same result as trying to
> map it from disk (clicking OK on the stickup you captured).
>
> That warning never got removed after support for nifti .hdr/.img pairs was
> added, but based on my getting the same results using the two paths
> mentioned above, I think you will solve your problem when you solve the
> misalignment between your cropped volume and the whole brain anatomical
> volume.  Alternatively, shift the surface to meet the whole brain /
> functional volume.
>
> Ideally, get the following loaded and aligned in caret:
>
> * whole brain anatomy volume
> * functional volume overlay
> * surface (probably shifted version of what you have now)
>
> Do this in your subject directory:
>
> find /my/subject/dir -name "*.params" |sort | xargs grep -i min
>
> Capture it to a file if it's a lot.  One of those files has the offset you
> need.
>
>> thank you.
>>
>>
>> Hi John,
>>>
>>> Got your upload.  While I couldn't open the cropped volume in caret due
>>> to
>>> the way it was named, I was able to view the surface contour over the
>>> uncropped volume.  See attached capture, which shows an offset.
>>>
>>> If you have a SureFit/Caret .params file (not included in the zip), it
>>> might contain the [XYZ]min values from the cropping, which might be
>>> used
>>> to either adjust the functional volume's origin, or more likely apply
>>> an
>>> affine transform to the surface, to shift it back into alignment with
>>> the
>>> whole brain volume.  You don't have to blow away your existing coord;
>>> just
>>> rename the shifted version to indicate the offset.  This can be done
>>> via
>>> command line or using the Caret: Window: Transformation Matrix editor.
>>> The polarity of the shift (+ or -) depends on whether you're shifting
>>> the
>>> volume or surface, and I always get confused about it.  Usually I try
>>> it
>>> one way; look at the result like the capture below; and if it looks
>>> worse,
>>> I try it the other way. ;-)  One of the ways usually does the trick.
>>>
>>> Donna
>>>
>>>
>>>
>>> On Aug 12, 2015, at 9:14 AM, Donna Dierker 
>>> wrote:
>>>
 Could you upload your dataset in a zip archive here:

>>>
 http://pulvinar.wustl.edu/cgi-bin/upload.cgi

 Specifically I need:

 * functional volume being mapped
 * anatomical volume with which functional volume aligns
 * anatomical volume used to generate segmentation -- *cropped*
 * fiducial coord file
 * topology file

 I am wondering if the centers of the volumes between the cropped
 volume
 used to generate the surface and the whole brain anatomical volume.


 On Aug 12, 2015, at 1:11 AM, j...@nbrc.ac.in wrote:

>>
>
> Ya, sorry for the incomplete query.
> Our interest is to view and threshold fMRI/voxel correlation data
>>>