Re: Selective Gaussian -> Early test app posted
- From: Lord Crc <lordcrc@xxxxxxxxxxx>
- Date: Tue, 19 Jul 2005 01:13:25 +0200
On Mon, 18 Jul 2005 21:23:42 +0200, "Mattias Andersson"
<mattias@xxxxxxxxxxxxx> wrote:
>Lord Crc wrote:
>> On Thu, 14 Jul 2005 02:36:08 +0200, "Mattias Andersson"
>> <mattias@xxxxxxxxxxxxx> wrote:
>>
>> I belive the Selective Gaussian is not separable, because you do not
>> use all pixels when computing it (hence the name of the algorithm :).
>> Since you've lost this, you might aswell allow arbitrary kernels.
[snip]
>What one could do instead, which I implemented in my optimized algorithm, is
>to cache the convolved values (the horizontal sums) for each reference color
>at a certain coordinate. This does not correspond to the same kind of
>optimization as in ordinary gaussian blur, where you would get complexity in
>the order Theta(pixels * r). Actually, if you have a completely solid image
>(with only a single color), then you would get this complexity too. However,
>as a worst case scenario one would still get O(pixels * r^2).
So how exactly does this caching work? From what you say, you compute
the horizontal sums for a given coordinate, ie hs[x,y,j] = kernel[i] *
a[x-i,y-j] * p[x-i,y-j], for i,j = -r to r ? If so, how do you use
this later?. And how exactly do you handle the weight scaling? This is
what I'm having trouble with, I can't see a way to separate it while
including the right pixels with the right weights, or the equivalent.
I've tried to implement what you say, but I do not get correct
results.
>> Which you can easily find out when you fill in the kernel. Simply keep
>> on going until the weights are less than 1 / NumLevels. However you
>> might want to be slightly less correct for the sake of speed (as it
>> would have a drastic impact on the kernel size).
>
>Well, not really true. Even if the weight is less than 1 / NumLevels, it
>will still have an impact on the result. I should have said "without any
>considerable impact" in my post, because although a single pixel might not
>make a difference, there will certainly be a difference if a larger number
>of pixels are convolved with a weight less than 1 / NumLevels. I think the
>best approach is really to plot the curve and decide on threshold value that
>seems reasonable. Alternatively one could test different threshold values
>and look at how the output image is affected.
But you'd need over 128 pixels with level 255 for it to change the
result _1_ level, and that's the worst case. I'd say the error
introduced by capping it at 1/255 is well within acceptable levels.
- Asbjørn
.
- Follow-Ups:
- Re: Selective Gaussian -> Early test app posted
- From: Mattias Andersson
- Re: Selective Gaussian -> Early test app posted
- References:
- Selective Gaussian -> Early test app posted
- From: Eric Grange
- Re: Selective Gaussian -> Early test app posted
- From: Mattias Andersson
- Re: Selective Gaussian -> Early test app posted
- From: Lord Crc
- Re: Selective Gaussian -> Early test app posted
- From: Mattias Andersson
- Selective Gaussian -> Early test app posted
- Prev by Date: Re: Fastcode MM - Nexus Validation
- Next by Date: MM4 and AllocMemSize
- Previous by thread: Re: Selective Gaussian -> Early test app posted
- Next by thread: Re: Selective Gaussian -> Early test app posted
- Index(es):
Relevant Pages
|