2012/2/1 Stéfan van der Walt <stefan <at> sun.ac.za>

Hi Stuart

On Tue, Jan 31, 2012 at 5:20 AM, Stuart Mumford <stuart <at> mumford.me.uk> wrote:
> I am interested in contributing to the scikit-signal project, I have been
> working on a wavelet package recently which I believe would be useful.
> https://github.com/Cadair/scikit-signal

We'd also be interested in having wavelet code in scikits-image
(http://skimage.org), since we need it for denoising (I was planning
on just incorporating pywavelets).  An advantage is that you'd get a
"free" vehicle for distribution and packaging, but  since we focus on
image processing, there may be reasons why you'd rather have it in a
stand-alone package.

Don't really understand the stand-alone bit, since that is a scikit-signal fork. 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.

Ralf
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev

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.

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