3
$\begingroup$

A recent publication, The fast Continuous Wavelet Transform (fCWT), enables real-time, wide-band, and high-quality, wavelet-based time–frequency analysis on non-stationary noisy signals.

I'm a beginner with wavelet and I'm working on real-time wavelet implementation. Is this fCWT a novelty in wavelet concept or just an optimization on the digital CWT computation?

$\endgroup$

1 Answer 1

2
$\begingroup$

I've modestly reviewed the paper.

I'm skeptical of its speedups and implementation accuracy. It includes time of sampling the wavelets in benchmarks, which is valid, but arguably the main use case is if wavelets are pre-computed and reused. Paper also make several dubious statements that suggest the authors don't really know what they're doing (especially regarding "resolution"), or would even know if they were wrong.

To test its correctness, one should pass in a unit impulse and compare the complex-valued output against known correct implementations:

x = np.zeros(N)
x[N//2] = 1
out0 = cwt0(x)
out1 = cwt1(x)

I believe MATLAB is correct, but in Python I only know of one that's correct and has complex-valued outputs: ssqueezepy, which I authored. SciPy and PyWavelets are not correct.

Moreover, authors conveniently excluded ssqueezepy from their comparisons: they claim x34 speedup against PyWavelets, while ssqueezepy shows x10; this makes them only x3.4 faster than ssqueezepy (but to be fair, they aren't the same configurations).

I'm working on a CWT that should be, worst case, x2 faster than it currently is, and several times faster best case - but one doesn't necessarily need to wait; discussed here.

Is this fCWT a novelty in wavelet concept

There's only one CWT. The only thing that can change is the wavelets or padding used, which isn't the subject of the paper, but the paper misleadingly suggests otherwise with "higher resolution" claims.

$\endgroup$
3
  • $\begingroup$ This clears up my confusion. Indeed misleading claims. About the link of your current work on speeding up CWT, it suggests modifying the hop_size. It's not clear to me how this speeds up CWT. You mentioned inversion and global phase-shift, I'm not getting the discussion. $\endgroup$ Jun 18, 2022 at 9:19
  • 1
    $\begingroup$ @EddyPiedad It's same as for STFT: more hop_size = less compute. With STFT, it's fewer FFTs, with CWT, it's smaller FFTs. I suggest first learning basics of STFT, then CWT, and only then trying to make a fast version of either. My inversion comments concern loss of information due to hop_size, and what's "acceptable". $\endgroup$ Jun 18, 2022 at 21:13
  • $\begingroup$ Indeed. I'll check your posts and references on STFT & CWT. Any recommendation will help. $\endgroup$ Jun 19, 2022 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.