Dear Georgos, Francesco, and all, I think both problems are now resolved.
Georgos pointed out an error in the use of a gradiometer montage, which helped. Finally, using the structure of the empty-room noise covariance when normalising signal power seems to remove any of the unusual structure in the resting-state power profiles. i.e. Computing source power maps with trace(weights * datacov * weights') ./ trace(weights * noisecov * weights') Many thanks for the help. Giles On 16 February 2015 at 18:56, Giles Colclough <giles.colclo...@gmail.com> wrote: > Dear Georgos, Francesco, and all, > > > thanks for taking the time to respond, and for your clear replies. Problem > (1) is solved, however I am still puzzled by (2). > > > (1) I was estimating my noise variance by importing the data blindly into > SPM. There was a scaling or unit transform being applied to the data which > I had not accounted for. Thanks for clearing this up. > > (2) The aspect of the source variance profile which is confusing is not > purely a function of depth bias: there is a bright plane which is unusually > strong over a wide range of depths. > > Firstly, a clarification: > We frequently work with pseudo-z stats for source power (see Vrba and > Robinson 2001, link below). This normalises source power estimates by the > power of the projected sensor noise. Computing source power with normalised > weight vectors is equivalent to performing this normalisation post-hoc. > I've slightly altered my scripts to clarify this, if it helps. > > Secondly, thanks for the scripts you sent over. They conveyed your points > clearly. When we apply corrections for depth bias, we tend to exclusively > use the 2-norm; although I understand that changing the norm will change > the sensitivity to the depth bias, as your 3rd script illustrated nicely. > > However, I don't think that tailoring the normalisation for depth bias > resolves the issue. The unusual source profile we observe is present in > both the source variance computed using normalised lead fields, and in the > pseudo z-stats, and remains visible under a range of choices of norm for > the lead fields (e.g. (lf(:).^2)^0.5, (lf(:).^2)^1). Indeed, the bright > plane/stripe is clearly not solely a function of depth. > > It's perhaps easier to see this effect at a higher resolution: try running > the script on a 4mm grid, under a range of depth normalisations. > > > Thanks for your help, > Giles > > > Vrba and Robinson 2001 > http://www.sciencedirect.com/science/article/pii/S1046202301912381 > > > > > On 16 February 2015 at 13:33, Georgios Michalareas < > giorgos.michalar...@esi-frankfurt.de> wrote: > >> Dear Giles, >> >> I ve looked a bit into your questions and your code. I have used the same >> data file you used. I am sending you 3 matlab scripts , more or less based >> on your code, in which I ve put some analysis which I hope can help with >> your questions. I have put most of my comments and suggestions as Comments >> in the M-files, preceded by my name i.e. %GIORGOS: . Please go through >> them(they are not very long and I tried to keep them a bit tidy ) and let >> me know if you have any questions. >> >> 1. The variance of the empty room noise scans and the resting state scan >> , at the sensor level, are very comparable. >> See "code4Giles1.m" >> In your code you mention as "source variance" to the diagonal of the >> covariance matrix in source space. The value order and range of this >> parameter largely depends on the Spatial Filter used to project the sensor >> covariance matrix. In your code for example you normalized the Beamformer >> Spatial Filters but their norm and then projected the data. If you dont do >> this normalisation the diagonal of the covariance matrix takes a completely >> different range of values. And if you normalise the Leadfield by each norm >> , as is frequently done in beamformer solutions, (rather than the Spatial >> Filters after they have been computed) then the range of values is alos >> different. And in this case the exponent of the normalizing norm , also >> affects the range of values. >> See "code4Giles2.m" >> >> 3. If no leadfield normalization is performed the beamformers have an >> inherent bias towards the center. This is because in order to produce the >> given sensor measurements from a dipole in the center of the brain , one >> needs much more power than from a dipole on the surface closer to the >> sensors. The higher the regularisation (as expressed by the exponent of >> the normalising norm) the more the bias shifts from the center towards the >> surface. When the exponent of the normalizing norm is 0.5 (or the square >> root of the sum of squares), the bias is neither in the center nor on the >> surface but spread in-between. If you would like your solution to be more >> biased towards the surface then an exponent of 1 is more appropriate. >> Please see "code4Giles3.m" >> >> >> Please have a look at the files and let me know for any questions or >> comments you have. >> Best >> Giorgos >> >> >> P.S. >> ------------------- >> Better to use the latest Fieldtrip version >> >> >> >> >> On 12/02/2015 12:48, Giles Colclough wrote: >> >> Hi, >> >> I have two queries I'm looking for help with. >> >> >> 1. Why is there a scaling difference between the magnitude of the data >> recorded in the noise scans, and the output of the rmegpreproc pipeline? >> >> I find about 30 orders of magnitude difference between the variance of >> the empty room scan and the variance of the data outputted by rmegpreproc. >> >> Have the data been uniformly scaled? If so, by how much? This would be >> useful information, for example, when source localising using the empty >> room data as an estimate of the noise. >> >> >> 2. When source localizing with a beamformer, I find an unusual variance >> profile in the resting state data. >> >> Normally when we look at resting data, the source variance is >> concentrated in a 'halo' around the outside of the cortex. In the HCP data, >> this halo is present, but there is also a bright stripe bisecting the brain >> around the central sulcus. We find this suprising, but have been unable to >> determine what's causing it. >> >> The effect is very repeatable between participants. >> >> I attach a screenshot of the effect, and two scripts to replicate the >> analysis. >> >> Any help or insights would be greatly appreciated. >> >> >> >> >> Many thanks, >> Giles >> >> >> _______________________________________________ >> HCP-Users mailing list >> HCP-Users@humanconnectome.org >> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >> >> >> >> >> ------------------------------ >> <http://www.avast.com/> >> >> This email is free from viruses and malware because avast! Antivirus >> <http://www.avast.com/> protection is active. >> >> > _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
