After some comparison runs, Vadim Levin convinced me that the "improvement" I made to the inverse FFT in the recfunk*, rfmig* codes was a bad innovation. The original RF-estimation codes applied a cos^2 factor to the frequency-domain RFs H_R(f) and H_T(f) with weighting unity at the f=0 point, decreasing to zero at f_max while following a cos-squared dependence. I changed all codes to have a sharper bandpass (I was unhappy that the half-amplitude point occurred at f_max/2!) with unit factor from f=0 to f=0.5*f_max, then a cos-squared rolloff within (0.5*f_max , f_max). This sharper bandpass led to small negative sidelobes at the flanks of sharp Ps pulses. Although one can live with this, the temptation to interpret a wiggle could be strong, so it is safer to use the original weighting of H(f) before inverse FFT to obtain the time-domain RF. The sidelobes do not disappear completely, but are far smaller.
recfunk_pick.f
recfunk_estack.f
rfmigrate_estack.f
rfmigrate.f
recfunk_svd.f
recfunk_mwm.f
recfunk_mwmj.f
recfunk_mwms.f
rfmig_boot.f
rfmig_mboot.f
rfmig_cboot.f
rfmig_mcboot.f
2 comments:
Ok - so I was using this as my bandpass filter:
filter(1:nf/2)=1
forall(i=nf/2+1:nf) filter(i)=(cos(PI*(i-nf/2)/nf))**2
(nf==f_max)
which if I calculated it right has 1/2 amplitude at 5/8 f_max. I think with the simple cos^2 taper from the beginning your 1/2 amplitude pt is fmax/4, actually, not fmax/2. If it were /2, you wouldnt see that big of a difference between the two since you're not really getting that much more freq content.
Since I wasn't present, can you go over better your argument for moving back? It seems like there should be a more intelligent/ consistent way to do this... as it is, it's just art.
Well, ok I made a mathematical error, and now I agree the difference is between 0.5f_max and 0.75fmax for the two tapers. But still, some more discussion would be appreciated.
Post a Comment