[SciPy-Dev] scikit-signal or Similar

Travis Oliphant travis at continuum.io
Wed Feb 1 10:10:29 EST 2012


On Feb 1, 2012, at 3:53 AM, Stuart Mumford wrote:

> Hello all,
>  
> That's great. Have you been following the discussion that's happened about this package earlier on this list? Here's a summary I made - http://brocabrain.blogspot.in/2012/01/scikit-signal-python-for-signal.html
> 
> I have read the discussion and your blog post. I think that development in scikit-signal is a good thing as long as we keep open the possibility of merging bits (all) of it into other places later. It really depends on where the project goes, as you said in your blog post, I don't really understand the intricacies of namespaces either so I am just happy to work on some code.
> 
> But I think the above shows that this really belongs in scipy. I think we should either improve scipy.signal.wavelets or look at merging pywavelets into scipy. This particular wheel gets reinvented way too often.
> 
> I agree that scipy.signal.wavelets needs improving, the reason myself and my friend started developing this wavelet code, was the only piece of Continuous Wavelet Transform code we could find was the piece we based what is now in the GitHub on. Even that had major omissions to what we needed and therefore we have spent time making the code fit our needs.
> 
> As for pyWavelets that seems to be a good standalone project and appears to be good at Discrete Wavelet Transforms, which I have not looked into. Again there is no need to reinvent the wheel so I don't think implementing a DWT into SciPy is necessary, however with the amount of applications for CWT I feel it would be better off in SciPy when it is ready.

The DWT is exactly the kind of tool SciPy needs.   The goal would not be to re-invent DWT with SciPy, but simply integrate pywavelets into SciPy if that is at all possible.    Having so many packages is good for developers, but not very good for consumers as people have to collect a lot of different packages together to get what they want.   Some of this pressure is being alleviated by "distributions" of Python, and I expect that trend will continue.   But, it is still useful for SciPy to grow "fundamental" libraries like a DWT.   

Thanks for your contributions an comments. 

Best regards,

-Travis



> 
> We'd also be interested in having wavelet code in scikits-image (http://skimage.org), since we need it for denoising 
>  
> I am interested in this application for wavelets, and how to expand the current 1D CWT into 2D. Do you know the advantages / disadvantages for CWT / DWT for your applications?
> 
> Wow, I took a look at the wavelet.py code. I, for one would learn like to learn from you. I want to learn to start coding like that.
> 
> I am flattered! I have never been taught OOP I just sort of blunder through so I hope what I produce is decent code!
> 
> I don't think pyHHT will be a part of scikit-signal for some time, both are projects in their infancy.
> 
> pyHHT certainly needs a lot of work and scikit-signal needs some code, but I think eventually this could be the aim.
> 
> Right now I'm working on time-frequency analysis (for the scikit-signal).
> 
> Cool, what?
> 
> Although HHT too is ultimately a tool for time-frequency analysis, we need to create enough motivation for using the HHT over other conventional methods.
> 
> From my (very limited) knowledge of what is good for what in signal processing, HHT to me is pretty impressive in what it can do. But as for using something like that it's all about what data you have and what you want to learn from it. I am studying the Sun for my PhD and the primary reason I wish to use HHT (well EMD) is to calculate the periods of oscillation in my very short data sets. [And I will go to extreme lengths to avoid using IDL]
> 
> But of course, as an independent project, you are welcome to contribute. I've put a crude version up at https://github.com/jaidevd/pyhht
> 
> I have already cloned it and started tinkering, but I need to do some more theoretical research first as I don't fully understand it.
> 
> Stuart
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20120201/dda0d9ec/attachment.html>


More information about the SciPy-Dev mailing list