zarathoustra

Yes, a ListBox with an add and remove button, plus the angle control. But i'm not going to do it. So, it's ok...

Not that kind of list. But i think, i won't do multiple angles, so... I can just switch to IndirectUI

Yea, i know, but if i did the multiple angle thing, i'd need a list control too...

OK Yes, that's right.But, I considered multiple options for the future as to whether i should let the user work with multiple angles at a time or not. In the multiple angle case, i have to know if i can mix std winforms controls with your IndirectUI because i haven't seen such controls. In the other case, it sounds much better to use your IndirectUI, indeed. Edit: lol @ my tab order, it's terrible indeed!!!

Yes, here: viewtopic.php?f=27&t=32550

I also made some demo pictures with this version of the filter.

Changes: 1) Fixed RGB support. Gabor.zip

Nice use of k-means.

It's the content that matters, there are excellent 3 pages papers. Also, if you know someone in univerisity, he can probably get it for you. There are 2 things here (both noted in the paper i mentioned): 1) rotating back and forth to take advantage of the separability of the filter at a given angle. They say it's computationally expensive and don't discuss it anymore. 2) downsampling. This point is discussed more seriously, it's one of the 2 points they advice for fast extraction in the spatial domain. I haven't got into this one, but the big picture is: Who needs a wavelength < 2 ?

No. Well, yes, but only for horizontal, vertical, and 45 degree filters. [1] It's already done. class GaborFilterKernel is the real math, and it computes the value for whatever input. class GaborFilterKernelWithEnvelope uses an envelope and stores the vales in a matrix at contruction. (The values are computed with GaborFilterKernel). Yes, it's under "feel free to rip it" license. I can give the piece of code if you want. Also [1] has other techniques for improving perfs: 1) in the spatial domain: downscaling the input and the kernel by a factor, they explain how to compute the factor such that you don't loose much. (Nyquist related tuffs). 2) using FFT (running in O(n log n)) to apply the transform in the frequency domain. ----- [1] Fast extraction of multi resolution Gabor-features, Ilonen, 2007

In my case yes, because, my filter isn't so fast, and it's much more work to do rgb 24bits than doing 1bit per pixel. So i have to ask the user about the input... Maybe "annoying" isn't the right word. And if you mean 99% of your user use only 24bits per pixel, i agree with you. I ment that from a technical point of view, for that particular filter. Edit: if i want things correct, i have to do it for all 3 channels, ie. 3 more times to preview and render. (I planned a different quality for preview and render for that purpose, the quality affects the kernel size, so the smaller the more approximated result, but quality >= 1 seems enough for preview.) Also now, it uses smaller kernels, but still, it can reach 600x600 kernels, and they can make sense for high resolution pictures...

I made a new version of the filter. I think you'll notice it's much faster. It was O(n^2) with n = pixel number (w*h). Now it's O(n*m) with m= number of values in the kernel, ie. (wavelength * (quality+1))^2 It's not feature complete, and things like RGB support is not implemented (it'll leave the img as is). PS: It's annoying PDN has only RGBA. Gabor.zip

I worked on it this weekend and somewhat improved speed. Now how do you use IndirectUI ? I have to rewrite my class to use inherit from PropertyBasedEffect instead of inheriting from Effect? Edit: I forgot to ask, when you use IndirectUI are you limited to the controls in PDN or can you mix winforms controls with it? Because, in a near future, i'll need some piece of UI for a list of angles, instead of just one.

Actually i think this is important, because that kind of thing opens the doors to a whole kind of new things that are a midway between filters and tools from papers from the 90s and 00s (like semi-automatic editings, etc...) and to heavier algos akin to signal processing, in general.

Yes. Nice.

I've seen that post already. More like a standard hack in pdn to me. It'll do the trick, but that'd be nice for rick to support the use case in a later version.

That's what i called a hack...

As i understand, you'd still get subsequent calls to render() for nothing.

Yea, i got that, but the scenario is as follows: *) i pass the whole picture to a function. *) i get back a whole pictures (well, actually 2 because it gives a 2D array of the size of the picture for the magnitude, and another one for the frequency). and if i write only those 2 lines, then i have to use pyrochild's hack, ie. a lock and a flag to get the result in the first place and put it in a member var, then multithreadly copy 2 lines per 2 lines. right?

If i remember well Rick asked that nothing be rendered in OnSetRenderInfo(). For the other one, ok, it's just too bad there's no flag in pdn to tell it to do it itself, rather then use this hack. That would be cleaner.

PDN points bits of picture to process using ROI in order to multithread the execution of filters. Typically used like that: for (int i = startIndex; i < startIndex + length; ++i) { Rectangle rect = rois[i]; But sometimes it's a serious limitation. For instance, i want to apply a Fast Fourrier Transform on the picture, and for that i have to pass the whole picture to the fft lib. I can't apply the transform to only 2 lines of picture at a time. So, how can i disable this to get only one ROI containing the whole picture and avoid pdn multithreading my thread? I tried this, with EffectFlags.SingleThreaded, it seems to disable multithreading. But, i'm still getting lots of calls with 1 ROI of 2 lines per call. How can i fix that? Can i just ignore the ROI when it's singlethreaded ? public EffectPlugin() : base(EffectPlugin.StaticName, EffectPlugin.StaticIcon, EffectPlugin.StaticSubMenuName, EffectFlags.Configurable | EffectFlags.SingleThreaded) {

Is it possible to create tool plugins ? The other day i was reading an inpainting paper (Combining Frequency and Spatial Domain Information for Fast Interactive Image Noise Removal, Hirani & Totsuka) and i was wondering how the UI could be done in pdn. The technique (which impressive by its simplicity/result quality ratio) require the user to make 3 selections before running an algo on them. One approach would be to make a filter dialog that displays the whole picture and ask the user to make 3 selection (a solution used by photoshop last time i checked few years ago). A second one, would be to make a tool for multiple selction, and allow to diferrantiate them and then run a filter on them (from the effects menu). A third one, would be to make a tool plugin that offers subtools in the tool's bar to make the selection and apply the algo on it. What do you think would be the best ui ? And what solution does pdn currently offers ? (i think it's the photoshop solution that i don't like, but who knows...) Edit: maybe this thread would rather belong to the plugin dev forum. sorry :?

It looks like your filter superpose emphasised edge on top of the source picture to me (looking at the davinci picture) although using a totally different technique (hidden fractal texture extraction, unknown to me). You could do that with the gabor filter, but my implementation is way to slow. if you want to render curves so well, you'd need 8 angles (at least), see how long it takes for one and think about it. Not saying that you won't see how long it will take on large pictures... Right now my code does the math in quadratic time with doubles (you can say *ouch*), there must be some fast discrete gabor transforms somewhere (hopefully doing this in n log n with ints), but i don't know.

Well, to be honest, i first placed them in "Stylize", because this is were edge detect was and i thought it was the same kind of thing. But at last minute before release build i changed it to "Zara FX" for my personnal ease of use, in a completely egoistic manner, i admit. I have to say i moderatly cared, because as you might have understood, i did this for me, and it's mostly insteresting for me (at least as is, see the terrible performance, poor ui, only one angle, etc...). So I have not published it in the other pluggin forum because i have put no care in what would be good for an end user, but i have published it here because the algo might interest other developers. If there are people really interested in using it the end user way, i could fix it with rick's comment and yours. But i'd be surprised it interest anyone for doing artistic things. (Note that i have no plan to fix the performance issue, making it unusable for picture above 150x150)

Because i wasn't aware of the existant of that (consequence of: the doc is the forum? )