[caret-users] Set current directory with Caret v5.512

2008-01-23 Thread Mateus Joffily

Hi,

I have downloaded the snapshot version of Caret v5.512 for windows and, 
when I try to Set current directory... and  select a directory, the 
navigator always returns the error messagecaret5.exe has encountered a 
problem and needs to close.. Does anyone has experienced the same problem?


Thanks,
Mateus


Re: [caret-users] Set current directory with Caret v5.512

2008-01-23 Thread Mateus Joffily

Hi John,

Now, it is working. Thank you very much.

Best,
Mateus

John Harwell wrote:

Hi Mateus,

I downloaded the windows snapshot and it also crashed when I tried to 
set the current directory.  I have updated the windows snapshot 
version and the problem should be fixed so try downloading it again.


---
John Harwell
[EMAIL PROTECTED]

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave   Box 8108
Saint Louis, MO 63110



On Jan 23, 2008, at 10:36 AM, Mateus Joffily wrote:


Hi,

I have downloaded the snapshot version of Caret v5.512 for windows 
and, when I try to Set current directory... and  select a 
directory, the navigator always returns the error messagecaret5.exe 
has encountered a problem and needs to close.. Does anyone has 
experienced the same problem?


Thanks,
Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users


___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users







[caret-users] Surface Shape Cluster Analysis

2007-06-21 Thread Mateus Joffily

Hi,

I was trying to explore the operation 'Surface Shape Cluster Analysis' 
in the 'Surface region of Interest' dialog, but I am not sure I 
understand the reported values. After selecting a ROI from my surface, 
the operation returns a long list of 'Threshold Column Num-Nodes Area 
AreaCorrected COG-X COG-Y COG-Z' values. Could someone explain me what 
does it means each line of the reported list?


Thanks,
Mateus



Re: [caret-users] Latitude/Longitude

2007-06-15 Thread Mateus Joffily

Hi John,

Thank you very much. Sorry for the large attachment. I just realized the 
message size, after sending it.

My operating system is Linux.

Thanks again,
Mateus


John Harwell wrote:


Hi Mateus,

The copy of the file you included does not have valid latitude  
longitude values.  Latitude should range from -90 to +90 and  
Longitude should range -180 to +180.


The problem is that Caret is not reading binary format latitude  
longitude files correctly and I have just fixed this problem.  In  
addition, I have modified the Surface Region of Interest Dialog to  
allow node selection based upon a range of Lat/Long values.  Let me  
know which operating system you are using and I will make an updated  
version of Caret available for you to download.


Lastly, it is probably not a good idea to include caret data files in  
emails as they can make the messages very large.  If needed, we do  
have a website where files can be uploaded.


--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Jun 14, 2007, at 3:45 AM, Mateus Joffily wrote:


John,

Thank you for the detailed explanation.
I followed it, but I am not confident that I got the correct  result. 
To be sure that there was not a problem with my lat/lon  file, I 
decided to test it with CARET_TUTORIAL_SEPT06/PAL_B12.BOTH- 
HEMS.STANDARD-SCENES.73730.spec. I am attaching the images that I  
captured from the created metric columns LAT and LONG. The LONG  
column has only zeros and the LAT column has some strange values.  
Instead, I would expect a grading of values along the latitude- 
longitude isocontours. Is it correct? I am also attaching a copy of  
the latlon file (PALS_B12.LR.73730.latlon) converted to metric.


Thanks,
Mateus

John Harwell wrote:


Mateus,

We will add ROI node selection with latitude/longitude to our to- 
do  list.


First, convert the LatLon file to a Metric file:
* Write your latitude/longitude file and be sure that Data File   
Encoding at the bottom of the Save Data File Dialog is set to  
Ascii  (Text).

* Load the lat/lon file into a text editor.
* Change tag-version 1 to tag-version 2
* Change tag-number-of-columns 1 to tag-number-of-columns 4
* Save the lat/lon file
* Change then name of the lat-lon file so that it ends with  .metric.
* Select File Menu-Open Data File.  Set the type to Metric,  
choose  the file, and press the Open button.  A Dialog will appear  
listing  the columns for loading.  Set the names of the first two  
columns to  Long and Lat respectively.



Second, to select the ROI
* Use the Display Control to set the displayed metric to Lat.
* On the Surface ROI Dialog, set the selection method to Nodes  
with  Metric.

* Set the Thresholds to the range of latitudes you want to select.
* Press the Select Nodes button.
* On the Display Control Dialog, change the selected metric to  Long.
* On the Surface ROI Dialog, change Normal Selection to And   
Selection (Intersection).

* Set the thresholds to the range of longitudes you want to select.
* Press the Select Nodes button.

--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Jun 13, 2007, at 11:13 AM, Mateus Joffily wrote:


Hi,

I would like to select every node that is inside a certain range  
of  latitude/longitude coordinates.
I thought to create a metric column with the nodes' longitude  and  
latitude values and then use the 'Node with Metric'  operation 
from  'Surface Region of Interest' dialog to select the  nodes. But 
I am  not sure it is the easiest way of doing it...  Does anyone 
has any  suggestion?

Thank you very much.

Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users






[caret-users] Latitude/Longitude

2007-06-13 Thread Mateus Joffily

Hi,

I would like to select every node that is inside a certain range of 
latitude/longitude coordinates.
I thought to create a metric column with the nodes' longitude and 
latitude values and then use the 'Node with Metric' operation from 
'Surface Region of Interest' dialog to select the nodes. But I am not 
sure it is the easiest way of doing it... Does anyone has any suggestion?

Thank you very much.

Mateus


[caret-users] spm99 metrics projection

2007-04-26 Thread Mateus Joffily

Hello,

We have 18 subjects that have been analysed with spm99. Their structural 
images have been normalized into a template from Marseille 
(http://irmfmrs.free.fr/formation/traitement_des_donnees/GuideSPM.htm) 
in MNI space.


Since, we didn't use spm99 standard template, I am not sure we can use 
Human.PALS_B12.LR.MULTI-FIDUCIAL_SPM99_fMRI-MAPPER.B1-12.LEFT.73730.spec 
for projecting the metrics. What would be the correct way of projecting 
the metric files of those subjects into a Caret/PALS surface?


Is there a Human.PALS_B12.LR.AVERAGE-FIDUCIAL_SPM96.RIGHT.73730.spec for 
spm99?


Thank you for your help.

Mateus


Re: [caret-users] spm99 metrics projection

2007-04-26 Thread Mateus Joffily

Ok, I will try it.
Thank you very much!

Mateus


Donna Dierker wrote:


On 04/26/2007 08:29 AM, Mateus Joffily wrote:


Hi Donna,

Wasn't SPM96 the single subject colin target?  I'm asking, because I 
really don't know the answer, but I think David may have told me 
this while working on his foci project.



I don't know, but I will check it.



It turns out my caret/data_files/fmri_mapping_files directory *does* 
have AVERAGE-FIDUCIAL_SPM95 and AVERAGE-FIDUCIAL_SPM96 spec files 
that almost certainly have to do with David's foci project.  Your 
version may be older and not yet have these files.  



Yes. I also have an AVERAGE-FIDUCIAL_SPM95. But I was wondering if it 
exists an AVERAGE-FIDUCIAL_SPM99.



But a worthwhile task might be to do this:

cd /usr/local/caret/data_files/fmri_mapping_files
caret5

Then, open whichever of these specs you think has the best chance of 
aligning:


Human.PALS_B12.LR.AVERAGE-FIDUCIAL_SPM95.LEFT.73730.spec
Human.PALS_B12.LR.AVERAGE-FIDUCIAL_SPM96.LEFT.73730.spec
Human.colin.SPM2.LEFT.71785.spec
Human.colin.SPM99.LEFT.71785.spec
Human.PALS_B12.LR.MULTI-FIDUCIAL_FLIRT_fMRI-MAPPER.B1-12.LEFT.73730.spec 

Human.PALS_B12.LR.MULTI-FIDUCIAL_MRITOTAL_fMRI-MAPPER.B1-12.LEFT.73730.spec 


Human.PALS_B12.LR.MULTI-FIDUCIAL_SPM2_fMRI-MAPPER.B1-12.LEFT.73730.spec
Human.PALS_B12.LR.MULTI-FIDUCIAL_SPM99_fMRI-MAPPER.B1-12.LEFT.73730.spec 



Then File: Open Data File: Volume anatomy file: and open your 
Marseille template

Switch to volume view ALL
D/C: overlay/underlay volume: settings: Toggle on Show surface 
contour checkbox
Scroll around and evaluate how well the fiducial contour intersects 
the surface



Ok. I will try it.

Finaly, if I choose to use a  MULTI-FIDUCIAL spec, I will need to 
project each individual metric to each  Buck_Case01:12 surface? 
After, how can I get an average fiducial map of the activations?


No:  If you decide MULTI-FIDUCIAL_SPM99 aligns nicely, then select 
SPM99 from the list of spaces in the Map to Atlas menu.  Then you'll 
see the entries that correspond to this spec file, select them, and 
select either map to average fiducial only; map to each of the 
subjects; and/or generate the average of the individual mappings.


In other words, the process is exactly the same; the only issue is 
first determining whether any of the existing surfaces intersects your 
template well enough, and if so, which intersects best.




Thank you very much.

Mateus

Perhaps even get a capture, if the alignment is excellent, and use 
this as your reason for using this target.  If none align well, then 
I don't have a good plan B for you.


Donna

On 04/26/2007 05:15 AM, Mateus Joffily wrote:


Hello,

We have 18 subjects that have been analysed with spm99. Their 
structural images have been normalized into a template from 
Marseille 
(http://irmfmrs.free.fr/formation/traitement_des_donnees/GuideSPM.htm) 
in MNI space.


Since, we didn't use spm99 standard template, I am not sure we can 
use 
Human.PALS_B12.LR.MULTI-FIDUCIAL_SPM99_fMRI-MAPPER.B1-12.LEFT.73730.spec 
for projecting the metrics. What would be the correct way of 
projecting the metric files of those subjects into a Caret/PALS 
surface?


Is there a 
Human.PALS_B12.LR.AVERAGE-FIDUCIAL_SPM96.RIGHT.73730.spec for spm99?


Thank you for your help.

Mateus




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users






Re: [caret-users] ROI center of gravity

2007-01-30 Thread Mateus Joffily

Hi Donald,

Thanks for your comments.

I would like to propose a 'new' method for calculating the surface's 
COG. To avoid the nodes density problem, I think it would be reasonable 
to calculate the COG of every tile on the surface and, after, to 
calculate the COG of the whole surface summing the COG of each tile 
multiplied by its own area and divided by the total surface area. I have 
done some tests using this method and compared the results with Caret's 
method.


On the attached capture (cog_m1.jpg), you can see a flat map of the 
primary motor cortex. Depending on the method used (caret vs. 'new' 
method) the COG can be shifted of up to 10mm. The 'new' method shows a 
COG more superior, consistent with the lower concentration of nodes at 
this region of the surface. Capture 'cog_m1_zoom.jpg' is just a zoom in 
on the tiles' CoG (green points).


I would appreciate any comment on this method.

I couldn't find the paper you cited. I guess it hasn't been published 
yet. Do you know when it will be available for download?


Best regards,
Mateus

DG MCLAREN wrote:


Mateus,

You raise a good point. 


In practice, it seems that you should keep the uneven distribution of nodes. 
The reason is as follows: If you resample the nodes to a more sparse uniform 
distribution, then you will distort the surface to some degree. The surface 
distortion will inevitable shift the center of gravity. I had thought about 
using the border points of a cluster to calculate the region; however, it seems 
that approach may unequally weight some parts of the cluster if there is an odd 
shape. It might be interesting to do a comparison between these methods.

In the end, it probably doesn't matter how you do the calculation for COG, as 
they should be similar, as long as the method is reported. I should also note, 
a recently accepted article: Cortical network for vibrotactile attention: A 
fMRI study in Human Brain Mapping describes the method and uses the traditional 
method; so there is an established standard that one could rely on and cite in 
future work.

Best Regards, Donald McLaren
=
D.G. McLaren
University of Wisconsin - Madison
Neuroscience Training Program
Tel: (773) 406 2464
=
This e-mail contains CONFIDENTIAL INFORMATION which may contain PROTECTED 
HEALTHCARE INFORMATION and may also be LEGALLY PRIVILEGED and which is intended 
only for the use of the individual or entity named above. If the reader of the 
e-mail is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that you are 
in possession of confidential and privileged information. Any unauthorized use, 
disclosure, copying or the taking of any action in reliance on the contents of 
this information is strictly prohibited and may be unlawful. If you have 
received this e-mail unintentionally, please immediately notify the sender via 
telephone at (773) 406 2464 or email.

- Original Message -
From: Mateus Joffily [EMAIL PROTECTED]
Date: Friday, January 26, 2007 12:12 pm
Subject: [caret-users] ROI center of gravity
To: Caret, SureFit, and SuMS software users caret-users@brainvis.wustl.edu


 


Hi,

I would like to calculate the center of gravity (COG) of a surface 
ROI. 
I see that 'Surface Region of Interest':'Statistical Report' gives me 

that information. However, if the nodes distribution over the surface 
is 
not uniform, the COG is biased toward the more dense regions.
I understand that, if someone wants to calculate the COG, taking into 

account the nodes-density, this is the right calculation. But, if I 
suppose that the surface density is uniform, is there a way of 
calculating the COG avoiding the nodes distribution effect?


Thanks,
Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users
   


___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users


 



inline: cog_m1.jpginline: cog_m1_zoom.jpg

Re: [caret-users] ROI - borders around clusters

2007-01-26 Thread Mateus Joffily

Hi Donna,

I replicated your probelm exactly with the roi.zip archive you 
uploaded.  It contained only the flat coord and cut topo; have you 
tried using the fiducial coord with closed topo?  It may not help, but 
it's worth a try.


Yes, the problem persists.



Although the clusters using metric2 appear smaller in area than the 
metric1 clusters, the nodes within the metric2 clusters are denser, 
which probably is a factor.  See the attached captures, shows the 
dense metric 2 clusters and the sparser metric 1 clusters, using 
drawing mode: Links (No Backside) on the D/C surface misc menu.  The 
top two clusters are only a single tile wide, so I'm not surprised 
Caret would have trouble drawing a border around them.  The two bottom 
ones also have places where they're only a tile wide, so maybe that's 
the problem.  If so, and switching coord/topo combos fails, then Im 
not sure what else to suggest.


Yes, probably the number of tiles is a limitation for drawing the 
borders. I see that borders are usualy not drawn around single tile 
metrics. However, I have other metrics with denser clusters that it 
doesn't draw the border neither (compare the top cluster (no border)  
with the bottom cluster (cyan border) in the attached capture). May be 
there is some other reason too... I will think a bit more about the 
problem and, if I find something new, I will let you know.


Thanks a lot for your help,
Mateus



Doing a very small amount of metric smoothing (Average neighbors, 1 
iteration, strength 1.0)  and reducing the threshold a tad would 
probably help (primarily just making the clusters larger), but I'm 
guessing this is something you'd be very hesitant to do.


On 01/25/2007 08:33 AM, Mateus Joffily wrote:


Hi Donna,

I restarted Caret and I created a new Spec file, including only the 
topology, flat coordinates, metric and surface shape files, and the 
problem persists. I did the following tests until now:


1) I tried the same operation, selecting only one of the clusters for 
which the program didn't draw borders before, but the program 
complains No clusters were found.


2) I tried the same operation with another metric that has even 
smaller cluster, and the program draws the borders correctly.


3) I tried some other operations on the selected nodes (e.g. Assign 
metric column to selected nodes, and Statistical report), and the 
program works fine for every cluster. Only 'Create Borders Around 
Clusters' doesn't work.


I uploaded my new Spec file (roi.zip)  with the two metrics included 
('metric1': problematic one; and 'metric2': with smaller clusters 
that works fine). If you have any other idea about what can be the 
problem...


Thank you very much,
Mateus


Donna Dierker wrote:

The only thing I can think to try is to restart Caret and repeat 
your selection of all nodes within threshold 1.0 to 5.0.  I can 
see from your capture that you did this and your green nodes include 
clusters for which it didn't draw borders.  My only guess is that 
perhaps somehow the create borders is still acting on a previous 
nodes connected to node number 33651 selection, even though this 
radio button isn't selected (and the green nodes show select nodes 
was pressed with All nodes within threshold selected).  Restarting 
simply removes any previous selections, if there is a bug lurking here.


Otherwise, my only other guess is that Caret has a minimum area for 
clusters, before it will generate a border around it, and the 
smaller ones fall below that threshold.  I'm not aware of such a limit.


If you upload your spec file (including coord, topo, and metric), I 
can see if my luck is any better than yours:


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

On 01/24/2007 10:55 AM, Mateus Joffily wrote:


Hi,

I am trying to use 'Surface Region of Interest' to create borders 
around metric clusters. The nodes on the surface are correctly 
selected, but when I select 'Create Borders Around Clusters'  only 
one of the clusters is surrounded by a border. I have tried the 
same operation with other metric columns and the program seems to 
work fine. I don't know why, for this specific metric, some 
clusters are left out.
I am attaching an image of caret windows. Any suggestion is well 
appreciated.


Thanks,
Mateus

 



 



___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users
  







___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] ROI - borders around clusters

2007-01-26 Thread Mateus Joffily

Hi Donna,

Thanks. I will look at the code and I let you know if I find something.

Mateus

Donna Dierker wrote:


Hi Mateus,

It's true the top cluster is mostly dense, but look at the node I've 
highlighed in red in the attached capture.  I wonder whether nodes 
like this that cinch the cluster cause the algorithm to give up.


Attached is some code I dug out of the source that might be what Caret 
is actually using.  (John would know for sure.)  Maybe it will prove 
helpful in deciphering what is the bottleneck, so to speak.


On 01/26/2007 07:14 AM, Mateus Joffily wrote:


Hi Donna,

I replicated your probelm exactly with the roi.zip archive you 
uploaded.  It contained only the flat coord and cut topo; have you 
tried using the fiducial coord with closed topo?  It may not help, 
but it's worth a try.



Yes, the problem persists.



Although the clusters using metric2 appear smaller in area than the 
metric1 clusters, the nodes within the metric2 clusters are denser, 
which probably is a factor.  See the attached captures, shows the 
dense metric 2 clusters and the sparser metric 1 clusters, using 
drawing mode: Links (No Backside) on the D/C surface misc menu.  The 
top two clusters are only a single tile wide, so I'm not surprised 
Caret would have trouble drawing a border around them.  The two 
bottom ones also have places where they're only a tile wide, so 
maybe that's the problem.  If so, and switching coord/topo combos 
fails, then Im not sure what else to suggest.



Yes, probably the number of tiles is a limitation for drawing the 
borders. I see that borders are usualy not drawn around single tile 
metrics. However, I have other metrics with denser clusters that it 
doesn't draw the border neither (compare the top cluster (no border)  
with the bottom cluster (cyan border) in the attached capture). May 
be there is some other reason too... I will think a bit more about 
the problem and, if I find something new, I will let you know.


Thanks a lot for your help,
Mateus



Doing a very small amount of metric smoothing (Average neighbors, 1 
iteration, strength 1.0)  and reducing the threshold a tad would 
probably help (primarily just making the clusters larger), but I'm 
guessing this is something you'd be very hesitant to do.


On 01/25/2007 08:33 AM, Mateus Joffily wrote:


Hi Donna,

I restarted Caret and I created a new Spec file, including only the 
topology, flat coordinates, metric and surface shape files, and the 
problem persists. I did the following tests until now:


1) I tried the same operation, selecting only one of the clusters 
for which the program didn't draw borders before, but the program 
complains No clusters were found.


2) I tried the same operation with another metric that has even 
smaller cluster, and the program draws the borders correctly.


3) I tried some other operations on the selected nodes (e.g. Assign 
metric column to selected nodes, and Statistical report), and the 
program works fine for every cluster. Only 'Create Borders Around 
Clusters' doesn't work.


I uploaded my new Spec file (roi.zip)  with the two metrics 
included ('metric1': problematic one; and 'metric2': with smaller 
clusters that works fine). If you have any other idea about what 
can be the problem...


Thank you very much,
Mateus


Donna Dierker wrote:

The only thing I can think to try is to restart Caret and repeat 
your selection of all nodes within threshold 1.0 to 5.0.  I 
can see from your capture that you did this and your green nodes 
include clusters for which it didn't draw borders.  My only guess 
is that perhaps somehow the create borders is still acting on a 
previous nodes connected to node number 33651 selection, even 
though this radio button isn't selected (and the green nodes show 
select nodes was pressed with All nodes within threshold 
selected).  Restarting simply removes any previous selections, if 
there is a bug lurking here.


Otherwise, my only other guess is that Caret has a minimum area 
for clusters, before it will generate a border around it, and the 
smaller ones fall below that threshold.  I'm not aware of such a 
limit.


If you upload your spec file (including coord, topo, and metric), 
I can see if my luck is any better than yours:


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

On 01/24/2007 10:55 AM, Mateus Joffily wrote:


Hi,

I am trying to use 'Surface Region of Interest' to create borders 
around metric clusters. The nodes on the surface are correctly 
selected, but when I select 'Create Borders Around Clusters'  
only one of the clusters is surrounded by a border. I have tried 
the same operation with other metric columns and the program 
seems to work fine. I don't know why, for this specific metric, 
some clusters are left out.
I am attaching an image of caret windows. Any suggestion is well 
appreciated.


Thanks,
Mateus

Re: [caret-users] ROI - borders around clusters

2007-01-25 Thread Mateus Joffily

Hi Donna,

I restarted Caret and I created a new Spec file, including only the 
topology, flat coordinates, metric and surface shape files, and the 
problem persists. I did the following tests until now:


1) I tried the same operation, selecting only one of the clusters for 
which the program didn't draw borders before, but the program complains 
No clusters were found.


2) I tried the same operation with another metric that has even smaller 
cluster, and the program draws the borders correctly.


3) I tried some other operations on the selected nodes (e.g. Assign 
metric column to selected nodes, and Statistical report), and the 
program works fine for every cluster. Only 'Create Borders Around 
Clusters' doesn't work.


I uploaded my new Spec file (roi.zip)  with the two metrics included 
('metric1': problematic one; and 'metric2': with smaller clusters that 
works fine). If you have any other idea about what can be the problem...


Thank you very much,
Mateus


Donna Dierker wrote:

The only thing I can think to try is to restart Caret and repeat your 
selection of all nodes within threshold 1.0 to 5.0.  I can see 
from your capture that you did this and your green nodes include 
clusters for which it didn't draw borders.  My only guess is that 
perhaps somehow the create borders is still acting on a previous nodes 
connected to node number 33651 selection, even though this radio 
button isn't selected (and the green nodes show select nodes was 
pressed with All nodes within threshold selected).  Restarting simply 
removes any previous selections, if there is a bug lurking here.


Otherwise, my only other guess is that Caret has a minimum area for 
clusters, before it will generate a border around it, and the smaller 
ones fall below that threshold.  I'm not aware of such a limit.


If you upload your spec file (including coord, topo, and metric), I 
can see if my luck is any better than yours:


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

On 01/24/2007 10:55 AM, Mateus Joffily wrote:


Hi,

I am trying to use 'Surface Region of Interest' to create borders 
around metric clusters. The nodes on the surface are correctly 
selected, but when I select 'Create Borders Around Clusters'  only 
one of the clusters is surrounded by a border. I have tried the same 
operation with other metric columns and the program seems to work 
fine. I don't know why, for this specific metric, some clusters are 
left out.
I am attaching an image of caret windows. Any suggestion is well 
appreciated.


Thanks,
Mateus





___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users
  








[caret-users] ROI - borders around clusters

2007-01-24 Thread Mateus Joffily

Hi,

I am trying to use 'Surface Region of Interest' to create borders around 
metric clusters. The nodes on the surface are correctly selected, but 
when I select 'Create Borders Around Clusters'  only one of the clusters 
is surrounded by a border. I have tried the same operation with other 
metric columns and the program seems to work fine. I don't know why, for 
this specific metric, some clusters are left out.
I am attaching an image of caret windows. Any suggestion is well 
appreciated.


Thanks,
Mateus
inline: roi_border.jpg

[caret-users] Create volume ROI from surface nodes

2007-01-11 Thread Mateus Joffily

Hi,

I am trying to create a volume ROI from selected nodes. I have selected 
the nodes inside a border, using the 'Surface Region of Interest' Query 
tab. Then I selected the 'Create Volume From Displayed Query Nodes' 
button and, after, I pressed OK in the 'Surface to Voulme Dialog'. The 
'Converting Surface' wait bar appears, but, when it is done, I can't 
find where the volume ROI is saved.
I see that a 'Segmention Volume' file is created, but I don't know how 
should I use it. What should I do next to create a volume ROI?


Thanks for your help.
Mateus




[caret-users] Flat surface crossovers

2006-12-11 Thread Mateus Joffily

Dear experts,

I am trying to flatten a surface. After medial wall and calcarine cut 
corrections, I obtain the attached flat surface with some crossovers. 
The 'initial Flattening Dialog' informs that cuts used to excise errors 
should begin and end outside the map perimeter. I am not really sure 
about what it means. Should I draw the new cuts inside or outside the 
borders (perimeter?) of the initial flat map. Could someone clarify it 
to me?


Thanks for your help,
Mateus
inline: initial_flat_surface.jpg

[caret-users] tailarach coordinate

2006-12-07 Thread Mateus Joffily

Hi,

I have registred one individual surface into PALS-B12 (using 
Human.PALS_B12.LR.REGISTER-with-INDIVIDUAL.73730.spec). I would like to 
know the talairach coordinate of a voxel in the registered surface. Is 
it possible?


Thanks for your help,
Mateus


Re: [caret-users] distance from a node

2006-11-30 Thread Mateus Joffily

Hi David,

Thanks for your reply. I asked for this capability because I am trying 
to perform a spherical registration. Many landmarks are defined as 
starting and terminating at a certain distance from an anatomical 
reference point. I thought that a tool, which allows the user to enter a 
reference point coordinate in the surface and, after, displays every 
node that is at a given geodesic distance from it, would be helpful
This capability is not essential for me. I was wondering if it was 
already implemented in Caret.


Best regards,
Mateus

David Vanessen wrote:


Mateus,

First, it is important to clarify whether your request pertains to  
nodes (as stated) or to foci.  In Caret terminology, nodes refers  
specifically to the points that make up a surface and have locations  
specified within a coordinate file.  Foci refers to stereotaxically  
identified locations (typically fMRI activation centers) that are  
specified within a foci file or foci projection file.  I'm guessing  
you are referring to foci, but let us  know.


At present, I don't think that the capability you are asking about  
exists for either nodes or foci.  If you can let us know what you  
will be using this for and whether this is a pressing need, it will  
help us to prioritize the request.  Also, if other Caret users would  
like to see this functionality, let us know.


Best regards,

David


On Nov 29, 2006, at 11:28 AM, Donna Dierker wrote:

If you were talking about geodesic distance (i.e., running along  the 
contour of the fiducial surface -- not as the crow flies  through the 
CSF/WM), then you could use the Surface: ROI feature  for this 
purpose. (First operation Geodesic Distance, and then  threshold the 
resulting metric at the desired distance.)


I'm not aware of something like that for 3D distances, but there's  a 
Make Sphere feature in Window: Script Builder.  Worst case, you  
could generate a sphere around the enclosing voxel and map that ROI  
volume to the surface.


On 11/29/2006 11:18 AM, Mateus Joffily wrote:


Hi,

In Caret5.5, is there a way of selecting a node and finding all  (or 
some) nodes that are at a given distance from it? I think I am  
looking for something similar to what is described in section  
2.17.2 (Foci Data Searches) of the 'Caret Tutorial – the Basics'.  
But Section 2.17.2 regards only WebCaret. Does it exist something  
similar to Caret5.5?


Thanks,
Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users


--
Donna L. Dierker
(Formerly Donna Hanlon; no change in marital status -- see http:// 
home.att.net/~donna.hanlon for details.)


___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users






[caret-users] projecting PALS-B12 atlas into individual brain

2006-11-30 Thread Mateus Joffily

Hi,

I have concluded the spherical registration of one individual surface 
into PALS-B12. Three spec files have been created:


(1) Human.Isa.R.spec (original spec file);
(2) deformed_Human.PALS_B12.LR.REGISTER-with-INDIVIDUAL.73730.spec;
(3) deformed_Human.Isa.R.spec;

Could you, please, precise me differences among those three specs and 
for what purpose should I use each one? Although the names seem to be 
informative, when I compare the surfaces linked to each one, they look 
very similar, if not the same.


In the next step, I would like to project PALS_B12 atlas (borders and 
paints) into the non-deformed individual surface. Could you, please, 
point me the documentation that explains how to do that, and how do I 
use the deformation map files?


Thanks again for your help.

Mateus


Re: [caret-users] Spherical registration

2006-11-30 Thread Mateus Joffily

Hi,

In the 'Caret5 Tutorial', during the spherical registration procedure, 
it is instructed to use the 'Human to Human' standard parameters (in 
Surface: Deformation: Run Spherical Surface Deformation: Spherical 
Parameters: Set Parameters). However, in Erin's cheat sheet, it is 
instructed to read params from: Def Map File: 
'TEMPLATE_REG-with-POP-AVG_4k_NoFid.deform_map'.


If I am using 'Human.PALS_B12.LR.REGISTER-with-INDIVIDUAL.73730' atlas, 
which procedure should I follow?


Thanks,
Mateus

Donna Dierker wrote:

I did remove the port numbers from the list, which seemed to have no 
ill effect on my end.  Perhaps it resolved the problem on your end.


On 11/29/2006 03:15 AM, Mateus Joffily wrote:


Hi Donna,

I don't know what happened, but now all the links work.

Thanks,
Mateus

Donna Dierker wrote:


Mateus,

Yes -- that's the right archive.

I don't understand why you're getting the time out errors; I can't 
replicate the problem on my end.


What happens when you try this link (i.e., same, except port number 
omitted):


http://sumsdb.wustl.edu/sums/archivelist.do?archive_id=6057499

On 11/28/2006 01:03 PM, Mateus Joffily wrote:


Hi Donna,

I don't know if I am the only one experiencing this problem, but I 
am also unable to access the location: 
http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6057499. 
I still get a 'time out error'.


However, I can access the SuMS database from 
http://sumsdb.wustl.edu/. Could you, please, confirm me if this is 
the atlas that I need to download: 
'Human.PALS_B12.LR.REGISTER-with-INDIVIDUAL.73730'?


Thanks,
Mateus


Donna Dierker wrote:


On 11/28/2006 11:48 AM, Mateus Joffily wrote:


Hi,

I am a little bit confused on how to proceed to register an 
individual surface into an Atlas.
The 'Caret5 Tutorial: Segmentation, Flattening, and Registration' 
explains how to perform a spherical registration using the 
'Human.colin.L.REGISTER-to-INDIVIDUAL.03-05.71785.spec' file. My 
questions are:


1) What spec file should I use to register into the right 
hemisphere?
2) If I choose to register into PALS-B12 atlas, what files should 
I use?




The answer to both 1) and 2) is use the PALS_B12 LR combo 
registration target dataset:


http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6057499

And use the template deform_map included in that dataset to preset 
your registration parameters.  See this page and Erin's cheat 
sheet (linked from the page below) for more details:


http://brainvis.wustl.edu/help/landmarks_core6/landmarks_core6.html

This is what we do.  There are separate landmark datasets for the 
left and right, but they differ very little, and using the LR 
combo enables you to do cross-hem or inter-hem analyses.  The way 
we look at it, there's very little down side to using the combo 
dataset, but a lot of up side to doing so.  So we routinely use 
the LR combo now.


We stopped using colin as a registration target a couple of years 
ago, but some documentation may still refer to it.




Thanks,
Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users






___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users








Re: [caret-users] distance from a node

2006-11-30 Thread Mateus Joffily

Hi Donna,

That's exactly what I did (although, there are some details in your 
example that I didn't understand well, see below). But, instead of keep 
going forth and back selecting nodes and subtracting their coordinates 
values (I had to do it quite often), I was wondering if there was not an 
utility that would automatically highlight all the nodes that are at a 
given distance from my reference point. I am not saying that it is a 
necessary utility, but, if it was already implemented, I could benefit 
from it...


Thanks,
Mateus



For example, there's a pretty big x and z offset between this 
occipital pole (first) and candidate most-posterior calcarine border 
point:


In this example, I though that the biggest offset was for Y (dX: 
15-28=-13; dY: -110 --78=32; dZ: -22 --6=-16). That's why you first 
chose to adjust the Y distance, no?




Node 20734
   Main Window Inflated XYZ: 15.015987396, -110.156700134, -22.251829147
   Shape: -2.904558420 -2.124466896

Node 32819
   Main Window Inflated XYZ: 27.664737701, -77.988800049, -6.281192303 
Distance: 38.076580048

   Shape: -10.455765724 -8.209010124


So I compute -110 - -78 = 32 -- so this point is 32mm from the 
occipital pole, so we need to find one whose y component of the 
inflated coordinate is closer to like -110 + 24 = -86.


Hope this helps!

On 11/30/2006 06:53 AM, Mateus Joffily wrote:


Hi David,

Thanks for your reply. I asked for this capability because I am 
trying to perform a spherical registration. Many landmarks are 
defined as starting and terminating at a certain distance from an 
anatomical reference point. I thought that a tool, which allows the 
user to enter a reference point coordinate in the surface and, after, 
displays every node that is at a given geodesic distance from it, 
would be helpful
This capability is not essential for me. I was wondering if it was 
already implemented in Caret.


Best regards,
Mateus

David Vanessen wrote:


Mateus,

First, it is important to clarify whether your request pertains to  
nodes (as stated) or to foci.  In Caret terminology, nodes refers  
specifically to the points that make up a surface and have 
locations  specified within a coordinate file.  Foci refers to 
stereotaxically  identified locations (typically fMRI activation 
centers) that are  specified within a foci file or foci projection 
file.  I'm guessing  you are referring to foci, but let us  know.


At present, I don't think that the capability you are asking about  
exists for either nodes or foci.  If you can let us know what you  
will be using this for and whether this is a pressing need, it will  
help us to prioritize the request.  Also, if other Caret users 
would  like to see this functionality, let us know.


Best regards,

David


On Nov 29, 2006, at 11:28 AM, Donna Dierker wrote:

If you were talking about geodesic distance (i.e., running along  
the contour of the fiducial surface -- not as the crow flies  
through the CSF/WM), then you could use the Surface: ROI feature  
for this purpose. (First operation Geodesic Distance, and then  
threshold the resulting metric at the desired distance.)


I'm not aware of something like that for 3D distances, but there's  
a Make Sphere feature in Window: Script Builder.  Worst case, you  
could generate a sphere around the enclosing voxel and map that 
ROI  volume to the surface.


On 11/29/2006 11:18 AM, Mateus Joffily wrote:


Hi,

In Caret5.5, is there a way of selecting a node and finding all  
(or some) nodes that are at a given distance from it? I think I 
am  looking for something similar to what is described in section  
2.17.2 (Foci Data Searches) of the 'Caret Tutorial – the Basics'.  
But Section 2.17.2 regards only WebCaret. Does it exist something  
similar to Caret5.5?


Thanks,
Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users


--
Donna L. Dierker
(Formerly Donna Hanlon; no change in marital status -- see http:// 
home.att.net/~donna.hanlon for details.)


___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users





___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users








Re: [caret-users] distance from a node

2006-11-30 Thread Mateus Joffily
I already started having fun with Caret! ;-) 
Thank you very much


Donna Dierker wrote:

Come to think of it, I would benefit from that utility, too.;-)  Even 
better would be an accurate, automated border drawing utility.  
Kidding aside, we recognize this is a highly desirable enhancement, 
but pretty tough to deliver right now.


John Harwell has added some caret_command features that can trim some 
of the easy ones (e.g., calcarine posterior, central dorsal/medial):


  SURFACE BORDER EXTREMA
 caret_command -surface-border-extrema \
input-topo-file input-coord-file input-border-file 
border-name


 List the extrema for the surface, the extrema for the border, and 
the

 difference between the extrema.
-- 

  SURFACE BORDER NIBBLER (remove border points within a distance to 
surface ext

rema)
 caret_command -surface-border-nibbler \
input-topo-file input-coord-file input-border-file 
border-name

output-border-file surface-extrema-name-or-node-indicator
 surface-extrema-offset-or-node-number pos-neg

 Remove points from the named border that are within that are on a .
 specified side of a surface extrema or node number.

But your idea is kind of interesting.

Meanwhile, if you choose reference points which differ primarily along 
the axis of interest, then the distance is a good proxy for the 
component difference, so no math required.  In either case, you'll be 
surprised how fast you get good at guessing.  Before long, you'll need 
only a few tries, and it's always fun when your first guess is right. ;-)


On 11/30/2006 12:52 PM, Mateus Joffily wrote:


Hi Donna,

That's exactly what I did (although, there are some details in your 
example that I didn't understand well, see below). But, instead of 
keep going forth and back selecting nodes and subtracting their 
coordinates values (I had to do it quite often), I was wondering if 
there was not an utility that would automatically highlight all the 
nodes that are at a given distance from my reference point. I am not 
saying that it is a necessary utility, but, if it was already 
implemented, I could benefit from it...


Thanks,
Mateus



For example, there's a pretty big x and z offset between this 
occipital pole (first) and candidate most-posterior calcarine border 
point:



In this example, I though that the biggest offset was for Y (dX: 
15-28=-13; dY: -110 --78=32; dZ: -22 --6=-16). That's why you first 
chose to adjust the Y distance, no?




Node 20734
   Main Window Inflated XYZ: 15.015987396, -110.156700134, 
-22.251829147

   Shape: -2.904558420 -2.124466896

Node 32819
   Main Window Inflated XYZ: 27.664737701, -77.988800049, 
-6.281192303 Distance: 38.076580048

   Shape: -10.455765724 -8.209010124


So I compute -110 - -78 = 32 -- so this point is 32mm from the 
occipital pole, so we need to find one whose y component of the 
inflated coordinate is closer to like -110 + 24 = -86.


Hope this helps!

On 11/30/2006 06:53 AM, Mateus Joffily wrote:


Hi David,

Thanks for your reply. I asked for this capability because I am 
trying to perform a spherical registration. Many landmarks are 
defined as starting and terminating at a certain distance from an 
anatomical reference point. I thought that a tool, which allows the 
user to enter a reference point coordinate in the surface and, 
after, displays every node that is at a given geodesic distance 
from it, would be helpful
This capability is not essential for me. I was wondering if it was 
already implemented in Caret.


Best regards,
Mateus

David Vanessen wrote:


Mateus,

First, it is important to clarify whether your request pertains 
to  nodes (as stated) or to foci.  In Caret terminology, nodes 
refers  specifically to the points that make up a surface and have 
locations  specified within a coordinate file.  Foci refers to 
stereotaxically  identified locations (typically fMRI activation 
centers) that are  specified within a foci file or foci projection 
file.  I'm guessing  you are referring to foci, but let us  know.


At present, I don't think that the capability you are asking 
about  exists for either nodes or foci.  If you can let us know 
what you  will be using this for and whether this is a pressing 
need, it will  help us to prioritize the request.  Also, if other 
Caret users would  like to see this functionality, let us know.


Best regards,

David


On Nov 29, 2006, at 11:28 AM, Donna Dierker wrote:

If you were talking about geodesic distance (i.e., running along  
the contour of the fiducial surface -- not as the crow flies  
through the CSF/WM), then you could use the Surface: ROI feature  
for this purpose. (First operation Geodesic Distance, and then  
threshold the resulting metric at the desired distance.)


I'm not aware of something like that for 3D distances, but 
there's  a Make Sphere feature in Window: Script Builder.  Worst

Re: [caret-users] Spherical registration

2006-11-29 Thread Mateus Joffily

Hi Donna,

I don't know what happened, but now all the links work.

Thanks,
Mateus

Donna Dierker wrote:


Mateus,

Yes -- that's the right archive.

I don't understand why you're getting the time out errors; I can't 
replicate the problem on my end.


What happens when you try this link (i.e., same, except port number 
omitted):


http://sumsdb.wustl.edu/sums/archivelist.do?archive_id=6057499

On 11/28/2006 01:03 PM, Mateus Joffily wrote:


Hi Donna,

I don't know if I am the only one experiencing this problem, but I am 
also unable to access the location: 
http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6057499. 
I still get a 'time out error'.


However, I can access the SuMS database from 
http://sumsdb.wustl.edu/. Could you, please, confirm me if this is 
the atlas that I need to download: 
'Human.PALS_B12.LR.REGISTER-with-INDIVIDUAL.73730'?


Thanks,
Mateus


Donna Dierker wrote:


On 11/28/2006 11:48 AM, Mateus Joffily wrote:


Hi,

I am a little bit confused on how to proceed to register an 
individual surface into an Atlas.
The 'Caret5 Tutorial: Segmentation, Flattening, and Registration' 
explains how to perform a spherical registration using the 
'Human.colin.L.REGISTER-to-INDIVIDUAL.03-05.71785.spec' file. My 
questions are:


1) What spec file should I use to register into the right hemisphere?
2) If I choose to register into PALS-B12 atlas, what files should I 
use?



The answer to both 1) and 2) is use the PALS_B12 LR combo 
registration target dataset:


http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6057499

And use the template deform_map included in that dataset to preset 
your registration parameters.  See this page and Erin's cheat 
sheet (linked from the page below) for more details:


http://brainvis.wustl.edu/help/landmarks_core6/landmarks_core6.html

This is what we do.  There are separate landmark datasets for the 
left and right, but they differ very little, and using the LR combo 
enables you to do cross-hem or inter-hem analyses.  The way we look 
at it, there's very little down side to using the combo dataset, but 
a lot of up side to doing so.  So we routinely use the LR combo now.


We stopped using colin as a registration target a couple of years 
ago, but some documentation may still refer to it.




Thanks,
Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users



___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users








[caret-users] border color file

2006-11-29 Thread Mateus Joffily

Hi Donna,

When I try to load the border files, after the surface alignement, I get 
the warning message: 'You have selected border files that require a 
border color file but no border color file is selected'. In Erin's 
document, it is said to:


File : Open Data File : File Type = Border Color Files
- Find ‘ForSPHERICAL.REGISTRATION_Human.Class3.bordercolor’
- Yes – Copy to current directory

But, I can't find this file anywhere. Do you know where it is saved? Is 
it 'Human.TEMPLATE-CUTS_STANDARD.03-05.bordercolor'?


Thanks again for your help.

Mateus



[caret-users] Spherical registration

2006-11-28 Thread Mateus Joffily

Hi,

I am a little bit confused on how to proceed to register an individual 
surface into an Atlas.
The 'Caret5 Tutorial: Segmentation, Flattening, and Registration' 
explains how to perform a spherical registration using the 
'Human.colin.L.REGISTER-to-INDIVIDUAL.03-05.71785.spec' file. My 
questions are:


1) What spec file should I use to register into the right hemisphere?
2) If I choose to register into PALS-B12 atlas, what files should I use?

Thanks,
Mateus


[caret-users] SuMS

2006-11-27 Thread Mateus Joffily

Hi,

Since last week, I am trying to connect to SumsDB homepage 
(http://brainmap.wustl.edu/sums), but I always get a time out 
connection. Could you, please, confirm me if it is online? I need to 
download:


   * Colin ref-for-landmarks left:
 Human.colin.LEFT.REG-with-PALS-B12.71785.spec
 http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6387328
   * Colin ref-for-landmarks right:
 Human.colin.RIGHT.REG-with-PALS-B12.71723.spec
 http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6387082

to help me drawing the registration borders.

Thanks,
Mateus


Re: [caret-users] nifti images

2006-11-17 Thread Mateus Joffily

Hi John,

Thanks. Now, I understand. I thought that the reported dimensions and 
voxel sizes refered to the volume (I,J,K) dimensions (voxel 
coordinates), and not to the (X,Y,Z) dimensions (real world 
coordinates). Please, correct me if I am still wrong?


I have another question: Does Caret take into account any rotation 
specified in the nifti-1 header? Or is there any incompatibility with 
transformations done by SPM5?


To better explain my question, let me describe the following test that I 
did:


1) I rotated my 3D_original.nii image of 45degrees around the X-axis 
(see 3D_original_rotated_spm5.pdf).
2) I saved this rotation in the image header, but I didn't reslice the 
image.
3) When I loaded the rotated image with Caret, I couldn't see anything 
in the P(YZ) and C(XZ) planes. However the H(XY) plane was displayed as 
if the image was not rotated. When I used the 'x', 'y' and 'z' control 
buttons to navigate through the image, the H(XY) slices were displayed 
as if it was the non-rotated 3D_original.nii. The reported dimensions 
and voxel sizes were 124x201x151 and 1.3x1.326x0.00, respectively.


Is it right?

Thanks,
Mateus

John Harwell wrote:


Mateus,

A volume has three-dimensions which are commonly indexed with I, J,  
and K.


When Caret loads a volume it always stores the voxels such that the  
voxels run left-to-right in the first dimension (I), posterior-to- 
anterior in the second dimension (J), and inferior-to-superior  
(K) in the third dimension.  This is commonly referred to as an  
LPI orientation and negative X points to the left side of the head,  
negative Y points to the back of the head, and negative Z points down  
into the neck.  This is the same orientation used by the Talairach  
atlas which places the origin at the anterior commissure.


Your volume has the voxels running anterior-to-posterior in the first  
dimension (I), inferior-to-superior in the second dimension (J),  
and left-to-right in the third dimension(K).  This is an AIL  
orientation.


Since Caret wants the volume in an LPI orientation and your volume is  
in an AIL orientation, Caret will reorganize the voxels in memory so  
that the volume is in an LPI orientation.  It is this reorientation  
operation that results in the voxel sizes and dimensions being permuted.




Output of 3DInfo for your volume and your volume saved by Caret with  
an LPI orientation:



Dataset File:3D_original.nii
Identifier Code: NII_Oo8IAJJUzJFWVH2nBnBIQA  Creation Date: Thu Nov  
16 13:44:28 2006

Dataset Type:Anat Bucket (-abuc)
Byte Order:  LSB_FIRST {assumed} [this CPU native = MSB_FIRST]
Storage Mode:NIFTI file
Data Axes Orientation:
  first  (x) = Anterior-to-Posterior
  second (y) = Inferior-to-Superior
  third  (z) = Left-to-Right   [-orient AIL]
R-to-L extent:   -80.652 [R] -to-79.248 [L] -step- 1.300 mm  
[124 voxels]
A-to-P extent:   -73.912 [A] -to-   113.588 [P] -step- 0.938 mm  
[201 voxels]
I-to-S extent:   -70.210 [I] -to-70.415 [S] -step- 0.938 mm  
[151 voxels]

Number of values stored at each pixel = 1
  -- At sub-brick #0 '?' datum type is float


-

Dataset File:3D_original_saved_with_caret.nii
Identifier Code: NII_Ffg_VXBk3o4b2q-dpSG84g  Creation Date: Thu Nov  
16 13:44:41 2006

Dataset Type:Anat Bucket (-abuc)
Byte Order:  MSB_FIRST {assumed} [this CPU native = MSB_FIRST]
Storage Mode:NIFTI file
Data Axes Orientation:
  first  (x) = Left-to-Right
  second (y) = Posterior-to-Anterior
  third  (z) = Inferior-to-Superior   [-orient LPI]
R-to-L extent:   -80.653 [R] -to-79.248 [L] -step- 1.300 mm  
[124 voxels]
A-to-P extent:   -73.912 [A] -to-   113.588 [P] -step- 0.938 mm  
[201 voxels]
I-to-S extent:   -70.210 [I] -to-70.415 [S] -step- 0.938 mm  
[151 voxels]

Number of values stored at each pixel = 1
  -- At sub-brick #0 '?' datum type is float

--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 16, 2006, at 11:39 AM, Mateus Joffily wrote:


Hi John,

Although the image orientation is fine and the origin is correctly  
localized at the AC, it still seems to have some problem with the  
image dimension and voxel size.


The correct image dimension and voxel size are 201 x 151 x 124 and  
-0.938 x 0.938 x 1.3 (X x Y x Z), respectively (see the  
3D_original_spm5.pdf file that I uploaded).  However, the values  
reported by Caret are 124 x 201 x 151 and 1.3 x 0.938 x 0.938.


Thanks for your help,
Mateus


John Harwell wrote:


Mateus,

To download updated versions of Caret:

1) Go to the website http://brainmap.wustl.edu/pub/john/;.  Use  
the  username pub and the password download to access the web  
site.
2) Download the file caret5_exe_linux.zip or  
caret5_exe_windows.zip  which contain the linux and windows

Re: [caret-users] nifti images

2006-11-16 Thread Mateus Joffily

Hi John,

Although the image orientation is fine and the origin is correctly 
localized at the AC, it still seems to have some problem with the image 
dimension and voxel size.


The correct image dimension and voxel size are 201 x 151 x 124 and 
-0.938 x 0.938 x 1.3 (X x Y x Z), respectively (see the 
3D_original_spm5.pdf file that I uploaded).  However, the values 
reported by Caret are 124 x 201 x 151 and 1.3 x 0.938 x 0.938.


Thanks for your help,
Mateus


John Harwell wrote:


Mateus,

To download updated versions of Caret:

1) Go to the website http://brainmap.wustl.edu/pub/john/;.  Use the  
username pub and the password download to access the web site.
2) Download the file caret5_exe_linux.zip or caret5_exe_windows.zip  
which contain the linux and windows versions of the caret5 executable.


To install:

1) Go into your Caret installation's bin directory and backup  
(rename) your current caret5 executable.
2) Place the downloaded file in the Caret installation's bin  
directory and unzip the downloaded file which will produce either  
caret5 or caret5.exe.  You might have to change the permissions on  
linux using the command chmod a+rx caret5.



As for the negative x voxel size, this usually means the the origin  
is specified on the right side of the volume and that the voxels are  
ordered right-to-left.  When Caret reads a volume and the volume  
contains valid orientation information, Caret flips the volume in  
memory to place the volume in an LPI (-x=left, -y=posterior, - 
z=inferior) orientation.  Visit the website http:// 
www.grahamwideman.com/gw/brain/orientation/orientterms.htm for more  
information.


--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 15, 2006, at 4:08 AM, Mateus Joffily wrote:


Hi John,

Thank you very much. The image looks good to me. I use Linux and  
Windows (preference for Linux).
Just one more question: How does Caret deals with the negative 'x'  
voxel size set by SPM5? Does it affect the way Caret displays the  
image? In the 'Volume Attributes Editor'  dialog - 'Resample' tab,  
the voxel size is always positive.


thanks,
Mateus

John Harwell wrote:


Hi Mateus,

I think I have the problem corrected and here is how  
3D_original.nii  appears in Caret.  If the images look good to you  
let me know which  operating system you are using and I will make  
an update available  for you to download.  This problem only  
occurred if the X-axis was  not left/right, the Y-axis was not  
posterior/anterior, or the Z-axis  not inferior/superior.



--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 13, 2006, at 3:33 AM, Mateus Joffily wrote:


Hi John,

I uploaded four files in Caret, their names are:

1) 3D_original.nii : original volume that doesn't display  
correctly  in Caret (case 1 described in my previous message)

2) 3D_original_spm5.pdf : capture of 3D_original.nii display in spm5
1) 3D_resliced.nii : same original volume but resliced (case 2   
described in my previous message)

1) 3D_resliced_spm5.pdf : capture of 3D_resliced.nii display in spm5

Thank you very much.

Mateus


John Harwell wrote:


Hi Mateus,

Can you upload the nifti volume that is not displayed correctly   
in  Caret at http://pulvinar.wustl.edu/cgi-bin/upload.cgi;.
Also, can  you capture and upload an image of the volume  
displayed  correctly in  SPM5 so that I know how it should appear.


After uploading the files, please email me the names of the   
files.   It may be a few days before I can look into this problem.


--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 10, 2006, at 9:42 AM, Mateus Joffily wrote:


Hi,

I am having some trouble to load nifti images with caret5.  The   
problem is the following:


1) When I try to load an image that has a rotation specified  in  
the  header, Caret seems not to apply it properly. The  
displayed  image  shows a strange orientation and the voxels  
size is wrong.


2) However, when the same image is resliced and no rotation  is   
specified in its header, Caret displays the image  correctly, 
the   voxels size are correct and the image origin  is also 
correctly   located.


Those same images, (1) and (2), are both correctly displayed   
with  SPM5.


The images extension is .nii, so I don't think this should be  
a   problem related to image format interpretation (like   
interpreting  nifti images as analyze and ignoring part of the   
header

Re: [caret-users] nifti images

2006-11-15 Thread Mateus Joffily

Hi John,

Thank you very much. The image looks good to me. I use Linux and Windows 
(preference for Linux).
Just one more question: How does Caret deals with the negative 'x' voxel 
size set by SPM5? Does it affect the way Caret displays the image? In 
the 'Volume Attributes Editor'  dialog - 'Resample' tab, the voxel size 
is always positive.


thanks,
Mateus

John Harwell wrote:


Hi Mateus,

I think I have the problem corrected and here is how 3D_original.nii  
appears in Caret.  If the images look good to you let me know which  
operating system you are using and I will make an update available  
for you to download.  This problem only occurred if the X-axis was  
not left/right, the Y-axis was not posterior/anterior, or the Z-axis  
not inferior/superior.



--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 13, 2006, at 3:33 AM, Mateus Joffily wrote:


Hi John,

I uploaded four files in Caret, their names are:

1) 3D_original.nii : original volume that doesn't display correctly  
in Caret (case 1 described in my previous message)

2) 3D_original_spm5.pdf : capture of 3D_original.nii display in spm5
1) 3D_resliced.nii : same original volume but resliced (case 2  
described in my previous message)

1) 3D_resliced_spm5.pdf : capture of 3D_resliced.nii display in spm5

Thank you very much.

Mateus


John Harwell wrote:


Hi Mateus,

Can you upload the nifti volume that is not displayed correctly  in  
Caret at http://pulvinar.wustl.edu/cgi-bin/upload.cgi;.   Also, 
can  you capture and upload an image of the volume displayed  
correctly in  SPM5 so that I know how it should appear.


After uploading the files, please email me the names of the  
files.   It may be a few days before I can look into this problem.


--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 10, 2006, at 9:42 AM, Mateus Joffily wrote:


Hi,

I am having some trouble to load nifti images with caret5. The   
problem is the following:


1) When I try to load an image that has a rotation specified in  
the  header, Caret seems not to apply it properly. The displayed  
image  shows a strange orientation and the voxels size is wrong.


2) However, when the same image is resliced and no rotation is   
specified in its header, Caret displays the image correctly, the   
voxels size are correct and the image origin is also correctly   
located.


Those same images, (1) and (2), are both correctly displayed  with  
SPM5.


The images extension is .nii, so I don't think this should be a   
problem related to image format interpretation (like  interpreting  
nifti images as analyze and ignoring part of the  header information).


Does anyone else has experienced this problem?  Thanks for your  help.

Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users





___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users
 





Re: [caret-users] nifti images

2006-11-14 Thread Mateus Joffily

Hi Donna,

Thanks for your help. I am sending you two histograms of 3D_resliced.nii:
(1) histogram_resliced_1.jpg is the same histogram you already sent to me;
(2) histogram_resliced_2.jpg is the histogram of 3D_resliced.nii after 
resampling at 1x1x1mm with Caret.


We can see that the spikes disapear in (2). It looks like much closer to 
the histograms described in your 'Peak Tweaking' document. As I don't 
have much experience with image segmentation, I was wondering if there 
was any problem with my images. I am glad to know that they look fine 
for you.


May be the problem is the one pointed by Simon. If this is the case, 
adjusting the histogram bins could minimize the effect. Do we have 
control over the histogram bins with Caret interface?


Thanks,
Mateus



Dierker wrote:


Hi Mateus,

I can't address your original problem with the NIfTI 
orientation/rotation, but I did have a look at your volumes, and this 
statement confuses me:


The histogram of my images (3D_original.nii and 3D_resliced.nii) 
shows several noisy sharp peaks. 


The attached captures show the histograms of 3D_original.nii 
(histogram_orig.jpg) and 3D_resliced.nii (histogram_resliced.jpg).  
The original has smoother looking peaks, but both have discernible 
gray and white matter peaks.  Neither look particularly bothersome.


Could you be more clear about what concerns you?

On 11/13/2006 05:43 AM, Mateus Joffily wrote:


John,

May I profit from the fact that I have already uploaded my images to 
ask you one more question about them? The histogram of my images 
(3D_original.nii and 3D_resliced.nii) shows several noisy sharp 
peaks. Do you know what do they mean? I know that, if I reslice the 
3D_resliced.nii to 1x1x1mm voxels size with Caret, they disappear. 
Thanks.


Mateus

John Harwell wrote:


Hi Mateus,

Can you upload the nifti volume that is not displayed correctly in  
Caret at http://pulvinar.wustl.edu/cgi-bin/upload.cgi;.  Also, can  
you capture and upload an image of the volume displayed correctly 
in  SPM5 so that I know how it should appear.


After uploading the files, please email me the names of the files.   
It may be a few days before I can look into this problem.


--
John Harwell
[EMAIL PROTECTED]
314-362-3467

Department of Anatomy and Neurobiology
Washington University School of Medicine
660 S. Euclid Ave.Box 8108
St. Louis, MO 63110   USA

On Nov 10, 2006, at 9:42 AM, Mateus Joffily wrote:


Hi,

I am having some trouble to load nifti images with caret5. The  
problem is the following:


1) When I try to load an image that has a rotation specified in 
the  header, Caret seems not to apply it properly. The displayed 
image  shows a strange orientation and the voxels size is wrong.


2) However, when the same image is resliced and no rotation is  
specified in its header, Caret displays the image correctly, the  
voxels size are correct and the image origin is also correctly  
located.


Those same images, (1) and (2), are both correctly displayed with  
SPM5.


The images extension is .nii, so I don't think this should be a  
problem related to image format interpretation (like interpreting  
nifti images as analyze and ignoring part of the header information).


Does anyone else has experienced this problem?  Thanks for your help.

Mateus
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users




___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users



___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users












___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://pulvinar.wustl.edu/mailman/listinfo/caret-users
 



inline: histogram_resliced_1.jpginline: histogram_resliced_2.jpg