> > >> Interesting! I think also looking at what is already existing in > the commons library your contribution is clearly on the image processing > side. Is that right? It's badly needed. I also would love to have it. > Crucial point here is that this is in signal processing terminology > a-causal so you essentially have all the data before you start processing > it (= Fourier Transform, convolution). >
Yes, I work with 3+D complex valued images so I am always extending code to handle these cases. This is how I started contributing here. > Looking at what is missing in the apache commons just now is: > - IIR filters + design (my IIRJ) > - 2D (image) filtering/convolution (your JVCL) > - FIR filters (causal with delay line) + design (linear phase filters) > I agree this would be a great set of tools. Regarding image processing, a source that needs to be considered, to avoid being redundant, is ImgLib2. ImgLib2 a great library (inherently ND and generically typed) but I find the learning curve on ImgLib to be pretty steep and the approach quite specialized. So the question for a possible commons contribution is, is there room for a more "everyday" filtering library fitting the commons mission, which benefits from being more readily intuitive than ImgLib2? I think probably so. Certainly nothing out of line with the more base components of commons-math. As an example in my case, I am interested in extending my image processing filters to ND but I am not sure this makes sense for commons -- probably methods overloaded for 2D and 3D would suffice, and if I want to get fancier I should develop within ImgLib. I'm not too crazy about proper FIR filters in JAVA because even in C++ they > are just too slow and one would need to write them as JNI calls to C to > make them run fast enough (for example a 50Hz notch for ECG at 1kHz > requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how excited > people here are about C/JNI calls. However the FIR filter _design_ = > creating an impulse response is useful for a-causal offline computation > using the convolution operation (but the 1D convolution is already > implemented isn't it?). The commons math guidelines, which I assume for now extend to spin-off projects, are here http://commons.apache.org/proper/commons-math/ . One stipulation is no external dependencies beyond commons-math and the Java SDK. This is one reason I have not tried to integrate my convolution library which has JOCL and JTransforms dependencies. Though I should emphasize that I am a noob myself, I would suspect that high-performance aspects of signal processing requiring native calls probably don't suit commons terribly well and should perhaps be some sort of extension library. That's certainly something I would be happy to work on too. For example, maybe a base commons-filter library could be worked out, which could be readily extensible with JNI, GPU, etc. Eric
