Generalizing and unifying frequency filters

[matze]

Rationale

Up to now, the filter task is mainly used for filtered backprojection, i.e. a one-dimensional, ramp-like filter in the Fourier domain. However, filtering has general purposes besides that and might be generalized in several directions:

1. We cannot model non-ramp-like filters such as low- and high-pass filters.
2. We are currently restricted to 1D filtering, however, two-dimensional passband filters are obviously pretty useful on images as well.
3. Windowing is conflated with the filter type.

Suggestions

• Introduce a type property specifying what kind of filter we have, i.e. ramp, lowpass, highpass, to ease transition this will be shared with the old filter property and ramp will still be the default.
• Introduce a window property with which the filter is multiplied, i.e. hamm, butterworth, faris-byer.
• Introduce a dims property to choose between one- and two-dimensional filters. Again to ease transition, one-dimensional should be the default.
• Maybe, remove the blur task and replace that with a gaussian as a filter type. On the other hand blur is implemented as a Gaussian kernel convolution and might be useful for certain applications.

@tfarago: what do you think?

[tfarago]

I completely agree, the generalization would be very useful. The question is how flexible the resulting filter should be. Is it meant for simple operations like the ramp or lowpass with the user not caring about the precise implementation? E.g. lowpass is a gaussian with some additional parameters. How are then the filter-specific parameters passed? By filter type we can also automatically determine if it's 1D or 2D.

I can also imagine a more general solution with the property e.g. filter-data, which would be a user-settable ND array of filter values. It would be extremely convenient e.g. for the phase retrieval or stripe filtering, because the tasks would drop all the boilerplate, just set the filter-data on the generalized filter.

Windowing could be also dropped to be a separate task, because it has nothing to do with the filtering, it's just an additional step. I can imagine adding some nice vignetting effects to my photos where I don't need any filter, just a window in real space.

Regarding the Gaussian blur, I would drop it and implement is as a frequency filter as well. I don't know for which sigmas the processing speed is better by real convolution but for sure the fft version gets much faster pretty quickly.

[matze]

Windowing could be also dropped to be a separate task, because it has nothing to do with the filtering.

I am talking about windowing of the filter itself, i.e. Butterworth is multiplied by the ramp filter to reduce high frequencies or with a brickwall lowpass to produce the actual lowpass Butterworth.

[tfarago]

Actually, the "window" is nothing else than another "filter". I can imagine something like

ufo-launch read path=foo ! fft dimensions=1 ! ramp ! butterworth ! ...

This would be very general and convenient for trying out new filters. One would create the final "filter" by combining many ufo tasks. Then, we can create a specialized filter like the current filter for reconstruction, where we would combine more options into one task in order to speed up computation, e.g. ramp+butterworth in one step. I guess the question is, should the filter task be doing some pre-defined filtering, like lowpass, etc., or should it rather be a meta-filter for easy construction of other filtering tasks? I think I prefer the latter, because we can end up with a blown-up task with tons of properties if we stuff different types and "windows" into one task. And if we have the general filter in place, it will be very easy to implement different types just by setting the e.g. the filter-data property.

[matze]

should it rather be a meta-filter for easy construction of other filtering tasks?

That. In my opinion it should be a "perfect" filter which is then (maybe with subsequent tasks) windowed. Perfect would be ideal ramp, low-, high- and bandpass filters. However, I would avoid splitting those up and also avoid splitting individual windowing filters up because they tend to share a lot of code and properties anyway.

[tfarago]

Alright, why don't you propose something in terms of a PR and then we continue the discussion there.

[matze]

That was my plan ;-)