Re: [caret-users] doubt regarding fiducial mapping
> Hello Donna, Thank you for your response. I think now the functional and anatomical is aligned properly once i do a reslicing(in SPM) of functional and aligning it in par with anatomical image parameters in caret. Thank you for your kind help, john Hi John, > > My trials with your data are detailed here: > >> http://brainmap.wustl.edu/pub/donna/IN/JOHN/align.html >> login pub >> password download > > > I suspect there are better ways of dealing with oblique data, and I hope > others will chime in if they have alternative suggestions. (They don't > have to be "better" -- just offering other perspectives, even.) This was > the best I could do with the information I have. > > Donna > > > On Aug 20, 2015, at 12:43 PM, j...@nbrc.ac.in wrote: > >>> Hi Donna, >> There were no steps that involved any de-obliquing, flipped, or >>> shifted, AC-centered "LPI" orientation. >> i loaded the image, anatomical and in volume attributes I checked the >> orientation, put the crossline at AC after shifting the image manually >> through co ordinate values, and selected the option to keep AC position >> as crossline position in main window. after this i gave coordinates of >> posterior comm, and middle fissure and checked voxel size etc... >> then i saved it as AC centered image. >> >> >> >> Hi John, >>> >>> Those tweaks were very helpful. I looked at the volumes with the >>> surface >>> overlaid, and here's what I found: >>> >>> http://brainmap.wustl.edu/pub/donna/IN/JOHN/align.html >>> login pub >>> password download >>> >>> I don't trust Caret to handle oblique volumes properly. Quoting the >>> link >>> above, "Can you go back through the history of this volume's processing >>> -- >>> specifically what happened to generate anatomical_ac_centered.hdr from >>> anatomical_image.hdr? Were there steps the de-obliqued, flipped, or >>> shifted the anatomical to get it AC-centered and probably in "LPI" >>> orientation, as Caret required to segment?" >>> >>> Donna >>> >>> >>> On Aug 20, 2015, at 1:02 AM, j...@nbrc.ac.in wrote: >>> Hello Donna, I've made the necessary changes and uploaded the file. john. 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
Re: [caret-users] doubt regarding fiducial mapping
Hi John, My trials with your data are detailed here: > http://brainmap.wustl.edu/pub/donna/IN/JOHN/align.html > login pub > password download I suspect there are better ways of dealing with oblique data, and I hope others will chime in if they have alternative suggestions. (They don't have to be "better" -- just offering other perspectives, even.) This was the best I could do with the information I have. Donna On Aug 20, 2015, at 12:43 PM, j...@nbrc.ac.in wrote: >> Hi Donna, > There were no steps that involved any de-obliquing, flipped, or >> shifted, AC-centered "LPI" orientation. > i loaded the image, anatomical and in volume attributes I checked the > orientation, put the crossline at AC after shifting the image manually > through co ordinate values, and selected the option to keep AC position > as crossline position in main window. after this i gave coordinates of > posterior comm, and middle fissure and checked voxel size etc... > then i saved it as AC centered image. > > > > Hi John, >> >> Those tweaks were very helpful. I looked at the volumes with the surface >> overlaid, and here's what I found: >> >> http://brainmap.wustl.edu/pub/donna/IN/JOHN/align.html >> login pub >> password download >> >> I don't trust Caret to handle oblique volumes properly. Quoting the link >> above, "Can you go back through the history of this volume's processing -- >> specifically what happened to generate anatomical_ac_centered.hdr from >> anatomical_image.hdr? Were there steps the de-obliqued, flipped, or >> shifted the anatomical to get it AC-centered and probably in "LPI" >> orientation, as Caret required to segment?" >> >> Donna >> >> >> On Aug 20, 2015, at 1:02 AM, j...@nbrc.ac.in wrote: >> >>> Hello Donna, >>> I've made the necessary changes and uploaded the file. >>> >>> john. >>> >>> >>> >>> 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. >
Re: [caret-users] doubt regarding fiducial mapping
> Hi Donna, There were no steps that involved any de-obliquing, flipped, or > shifted, AC-centered "LPI" orientation. i loaded the image, anatomical and in volume attributes I checked the orientation, put the crossline at AC after shifting the image manually through co ordinate values, and selected the option to keep AC position as crossline position in main window. after this i gave coordinates of posterior comm, and middle fissure and checked voxel size etc... then i saved it as AC centered image. Hi John, > > Those tweaks were very helpful. I looked at the volumes with the surface > overlaid, and here's what I found: > > http://brainmap.wustl.edu/pub/donna/IN/JOHN/align.html > login pub > password download > > I don't trust Caret to handle oblique volumes properly. Quoting the link > above, "Can you go back through the history of this volume's processing -- > specifically what happened to generate anatomical_ac_centered.hdr from > anatomical_image.hdr? Were there steps the de-obliqued, flipped, or > shifted the anatomical to get it AC-centered and probably in "LPI" > orientation, as Caret required to segment?" > > Donna > > > On Aug 20, 2015, at 1:02 AM, j...@nbrc.ac.in wrote: > >> Hello Donna, >> I've made the necessary changes and uploaded the file. >> >> john. >> >> >> >> 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 >
Re: [caret-users] doubt regarding fiducial mapping
Hi John, Those tweaks were very helpful. I looked at the volumes with the surface overlaid, and here's what I found: http://brainmap.wustl.edu/pub/donna/IN/JOHN/align.html login pub password download I don't trust Caret to handle oblique volumes properly. Quoting the link above, "Can you go back through the history of this volume's processing -- specifically what happened to generate anatomical_ac_centered.hdr from anatomical_image.hdr? Were there steps the de-obliqued, flipped, or shifted the anatomical to get it AC-centered and probably in "LPI" orientation, as Caret required to segment?" Donna On Aug 20, 2015, at 1:02 AM, j...@nbrc.ac.in wrote: > Hello Donna, > I've made the necessary changes and uploaded the file. > > john. > > > > 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
Re: [caret-users] doubt regarding fiducial mapping
Hello Donna, I've made the necessary changes and uploaded the file. john. 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 su
Re: [caret-users] doubt regarding fiducial mapping
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
> 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 >>>
Re: [caret-users] doubt regarding fiducial mapping
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 over the fiducial brain surface created out of high res image of individual macaques. 1. we used CARET 5.65 for creating the fiducial surfaces(following the caret5 tutorial guide for segmentation).we used individual already coregistered high res images for this purpose. 2. then we tried overlaying the fMRI data(spmT file from analysis using spm8) on the fiducial surface (following the procedures from http://prefrontal.org/blog/2009/04/using-caret-for-fmri-visualization/ and the tutorial guides). we ended up having a) fiducial surfaces with fmri data mapped onto it. But the voxel coordinates did not match properly with the results in spm8. I should tell you one thing that we found: when we overlay whole brain fmri results, it matches more or less in x&y axes but not in z axis. and when we overlay results from explicitly masked analysis(roi), it seems to be shifted caudally by 2-3mm in R-C axis. same things when checked in spm8, shows up to b
Re: [caret-users] doubt regarding fiducial mapping
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 over the > fiducial brain surface created out of high res image of individual > macaques. > 1. we used CARET 5.65 for creating the fiducial surfaces(following the > caret5 tutorial guide for segmentation).we used individual already > coregistered high res images for this purpose. > 2. then we tried overlaying the fMRI data(spmT file from analysis using > spm8) on the fiducial surface (following the procedures from > http://prefrontal.org/blog/2009/04/using-caret-for-fmri-visualization/ > and the tutorial guides). > > we ended up having > a) fiducial surfaces with fmri data mapped onto it. But the voxel > coordinates did not match properly with the results in spm8. > I should tell you one thing that we found: when we overlay whole brain > fmri results, it matches more or less in x&y axes but not in z axis. and > when we overlay results from explicitly masked analysis(roi), it seems to > be shifted caudally by 2-3mm in R-C axis. same things when checked in > spm8, shows up to be well coregistered! > > b)Another issue is we are not able to threshold the caret brain overlays > in concordance with the thresholds that we use in spm. > The metric thresholding range (user defined) doesn't seems to represent > what we really need. > eg:we tried overlaying FDR corrected voel corrln values, thresh 0.4 on the > brain in caet and tried a range of metric thresholds(user scale 0-1, put > display mode-pos,thresh type -user, tried changing user pos thresh values > to 0.4 and voxels doesn't show up! > > Thank you donna, > > > > > > > > > > > > > > > > > > > > > > What software was used to reconstruct the surface? >> >> With freesurfer, there is an offset between the orig.mgz and the surface. >> And depending on many factors, you might have to flip/rotate the surface >> to be in the same orientation as the volume (or bring the volume to the >> surface). >> >> See this thread: >> >> http://www.mail-archive.com/caret-users%40brainvis.wustl.edu/msg02081.html >> >> Also see the "Check Alignment between Normalized Volume and Surface" >> section here: >> >> http://brainvis.wustl.edu/help/pals_volume_normalization/spm5_normalization_pals.html >> >> Examining the surface contour overlaid on the volum in volume view All is >> often very enlightening. >> >> >> On Aug 11, 2015, at 4:42 AM, j...@nbrc.ac.in wrote: >> >>> yes, ours is an individual s surface reconstruction, and so we checked >>> the >>> registration in spm8( using anatomical image used for reconstruction >>> and >>> the functional image volumes used for mapping), where the volumes are >>> coregistered properly, but shows anomaly in caret. >>> >>> thank you >>> >>> >>> >>> This almost always is because the functional volume is not stereotactically registered to the anatomical volume used to generate the fiducial surface. Is this an atlas surface (e.g., one of the PALS mean midthickness surfaces), or is it an individual's surface reconstruction? If atlas, this could happen if you were trying to map SPM functional data to the AFNI mid thickness surface, for example, because there are noticeable differences between those stereotaxic spaces. If individual, make sure the functional volume is in register with the anatomical volume used to generate the surface. On Aug 10, 2015, at 1:40 AM, j...@nbrc.ac.in wrote: > Hi, > when i map the functional data onto caret fiducial surface, it > appears > that the mapping is shifted in rostrocaudal axis, caudally, by about 2 > -3 mm. anyone has idea what could be possibly wrong here? > thanks, > john > ___ > 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 mailing list >>> caret-users@brainvis.wustl.edu >>> http://brainvis.wustl.edu/mailman/listinfo/caret-users >> >> >> ___ >> caret-users mailing list >> caret-users@brainvis.wustl.edu >> h
Re: [caret-users] doubt regarding fiducial mapping
> Ya, sorry for the incomplete query. Our interest is to view and threshold fMRI/voxel correlation data over the fiducial brain surface created out of high res image of individual macaques. 1. we used CARET 5.65 for creating the fiducial surfaces(following the caret5 tutorial guide for segmentation).we used individual already coregistered high res images for this purpose. 2. then we tried overlaying the fMRI data(spmT file from analysis using spm8) on the fiducial surface (following the procedures from http://prefrontal.org/blog/2009/04/using-caret-for-fmri-visualization/ and the tutorial guides). we ended up having a) fiducial surfaces with fmri data mapped onto it. But the voxel coordinates did not match properly with the results in spm8. I should tell you one thing that we found: when we overlay whole brain fmri results, it matches more or less in x&y axes but not in z axis. and when we overlay results from explicitly masked analysis(roi), it seems to be shifted caudally by 2-3mm in R-C axis. same things when checked in spm8, shows up to be well coregistered! b)Another issue is we are not able to threshold the caret brain overlays in concordance with the thresholds that we use in spm. The metric thresholding range (user defined) doesn't seems to represent what we really need. eg:we tried overlaying FDR corrected voel corrln values, thresh 0.4 on the brain in caet and tried a range of metric thresholds(user scale 0-1, put display mode-pos,thresh type -user, tried changing user pos thresh values to 0.4 and voxels doesn't show up! Thank you donna, What software was used to reconstruct the surface? > > With freesurfer, there is an offset between the orig.mgz and the surface. > And depending on many factors, you might have to flip/rotate the surface > to be in the same orientation as the volume (or bring the volume to the > surface). > > See this thread: > > http://www.mail-archive.com/caret-users%40brainvis.wustl.edu/msg02081.html > > Also see the "Check Alignment between Normalized Volume and Surface" > section here: > > http://brainvis.wustl.edu/help/pals_volume_normalization/spm5_normalization_pals.html > > Examining the surface contour overlaid on the volum in volume view All is > often very enlightening. > > > On Aug 11, 2015, at 4:42 AM, j...@nbrc.ac.in wrote: > >>> >> yes, ours is an individual s surface reconstruction, and so we checked >> the >> registration in spm8( using anatomical image used for reconstruction >> and >> the functional image volumes used for mapping), where the volumes are >> coregistered properly, but shows anomaly in caret. >> >> thank you >> >> >> >> This almost always is because the functional volume is not >>> stereotactically registered to the anatomical volume used to generate >>> the >>> fiducial surface. Is this an atlas surface (e.g., one of the PALS mean >>> midthickness surfaces), or is it an individual's surface >>> reconstruction? >>> If atlas, this could happen if you were trying to map SPM functional >>> data >>> to the AFNI mid thickness surface, for example, because there are >>> noticeable differences between those stereotaxic spaces. >>> >>> If individual, make sure the functional volume is in register with the >>> anatomical volume used to generate the surface. >>> >>> >>> On Aug 10, 2015, at 1:40 AM, j...@nbrc.ac.in wrote: >>> Hi, when i map the functional data onto caret fiducial surface, it appears that the mapping is shifted in rostrocaudal axis, caudally, by about 2 -3 mm. anyone has idea what could be possibly wrong here? thanks, john ___ 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 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 mailing list caret-users@brainvis.wustl.edu http://brainvis.wustl.edu/mailman/listinfo/caret-users
Re: [caret-users] doubt regarding fiducial mapping
What software was used to reconstruct the surface? With freesurfer, there is an offset between the orig.mgz and the surface. And depending on many factors, you might have to flip/rotate the surface to be in the same orientation as the volume (or bring the volume to the surface). See this thread: http://www.mail-archive.com/caret-users%40brainvis.wustl.edu/msg02081.html Also see the "Check Alignment between Normalized Volume and Surface" section here: http://brainvis.wustl.edu/help/pals_volume_normalization/spm5_normalization_pals.html Examining the surface contour overlaid on the volum in volume view All is often very enlightening. On Aug 11, 2015, at 4:42 AM, j...@nbrc.ac.in wrote: >> > yes, ours is an individual s surface reconstruction, and so we checked the > registration in spm8( using anatomical image used for reconstruction and > the functional image volumes used for mapping), where the volumes are > coregistered properly, but shows anomaly in caret. > > thank you > > > > This almost always is because the functional volume is not >> stereotactically registered to the anatomical volume used to generate the >> fiducial surface. Is this an atlas surface (e.g., one of the PALS mean >> midthickness surfaces), or is it an individual's surface reconstruction? >> If atlas, this could happen if you were trying to map SPM functional data >> to the AFNI mid thickness surface, for example, because there are >> noticeable differences between those stereotaxic spaces. >> >> If individual, make sure the functional volume is in register with the >> anatomical volume used to generate the surface. >> >> >> On Aug 10, 2015, at 1:40 AM, j...@nbrc.ac.in wrote: >> >>> Hi, >>> when i map the functional data onto caret fiducial surface, it appears >>> that the mapping is shifted in rostrocaudal axis, caudally, by about 2 >>> -3 mm. anyone has idea what could be possibly wrong here? >>> thanks, >>> john >>> ___ >>> 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 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
Re: [caret-users] doubt regarding fiducial mapping
> yes, ours is an individual s surface reconstruction, and so we checked the registration in spm8( using anatomical image used for reconstruction and the functional image volumes used for mapping), where the volumes are coregistered properly, but shows anomaly in caret. thank you This almost always is because the functional volume is not > stereotactically registered to the anatomical volume used to generate the > fiducial surface. Is this an atlas surface (e.g., one of the PALS mean > midthickness surfaces), or is it an individual's surface reconstruction? > If atlas, this could happen if you were trying to map SPM functional data > to the AFNI mid thickness surface, for example, because there are > noticeable differences between those stereotaxic spaces. > > If individual, make sure the functional volume is in register with the > anatomical volume used to generate the surface. > > > On Aug 10, 2015, at 1:40 AM, j...@nbrc.ac.in wrote: > >> Hi, >> when i map the functional data onto caret fiducial surface, it appears >> that the mapping is shifted in rostrocaudal axis, caudally, by about 2 >> -3 mm. anyone has idea what could be possibly wrong here? >> thanks, >> john >> ___ >> 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 mailing list caret-users@brainvis.wustl.edu http://brainvis.wustl.edu/mailman/listinfo/caret-users
Re: [caret-users] doubt regarding fiducial mapping
This almost always is because the functional volume is not stereotactically registered to the anatomical volume used to generate the fiducial surface. Is this an atlas surface (e.g., one of the PALS mean midthickness surfaces), or is it an individual's surface reconstruction? If atlas, this could happen if you were trying to map SPM functional data to the AFNI midthickness surface, for example, because there are noticeable differences between those stereotaxic spaces. If individual, make sure the functional volume is in register with the anatomical volume used to generate the surface. On Aug 10, 2015, at 1:40 AM, j...@nbrc.ac.in wrote: > Hi, > when i map the functional data onto caret fiducial surface, it appears > that the mapping is shifted in rostrocaudal axis, caudally, by about 2 > -3 mm. anyone has idea what could be possibly wrong here? > thanks, > john > ___ > 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] doubt regarding fiducial mapping
Hi, when i map the functional data onto caret fiducial surface, it appears that the mapping is shifted in rostrocaudal axis, caudally, by about 2 -3 mm. anyone has idea what could be possibly wrong here? thanks, john ___ caret-users mailing list caret-users@brainvis.wustl.edu http://brainvis.wustl.edu/mailman/listinfo/caret-users
