comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Convolution, IDL & Numerical Recipes
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Convolution, IDL & Numerical Recipes [message #32771 is a reply to message #32759] Tue, 12 November 2002 06:10 Go to previous messageGo to previous message
muzic is currently offline  muzic
Messages: 5
Registered: December 1994
Junior Member
The definition of discrete convolution is
c[n] = sum_over_i ( a[i] * b[n-i] )
where c equals a convolved with b.

Correlation differs in that sign inside the [] of b
d[n] = sum_over_i ( a[i] * b[n+i] )
where d equals correlation of a with b

In both cases, sum_over_i can mean sum as i goes
from negative infinity to positive infinity. Since
computers have finite speed and memory, this does
not make implementation practical ... unless, of
course, a and b have only a finite number of non-zero
values so that multiplication and summing need
only be done on non-zeros.

In a IDL, C, MATLAB or whatever implementation,
the index of the first element of an array is typically
zero or one but not negative. This means how the results are stored
in an array representing c[] or d[] may require an offset since
someone might like to calculate c[-4]. If we want to
put c[-4] in the first element of an IDL array, then
one would have to apply an offset of four. E.g. let cc be a shifted
(or offset) version of c, so that cc[0] = c[-4] and in
general cc[n] = c[n+4].

Regarding, "center" and a sharpening filter kernel, ...
it is the same principle but the issue is the offset of a or b.
Let a be the siganl to filter and b be the coefficients of a
filter kernel. Then, center should(!) is an offset for
the indexing on b. If you follow the details of the
math, changing the center should(!) simply shift the
result. If IDL implementtion does not behave in this
way, (or at least in a manner consistent with its
documentation) I'd say it is a bug.


Ray Muzic
Associate Professor, Radiology and Biomedical Engineering
Case Western Reserve University






David Fanning <david@dfanning.com> wrote in message news:<MPG.182c80089cb24eff9899fb@news.frii.com>...
> R.G. Stockwell (sorry@noemail.now) writes:
>
>>> Which would I use if I'm trying to make a pretty image? :-)
>>
>> I suggest running all possible permutations of the keywords, and
>> selecting the one that matches the textbook examples :)
>
> Right. That's what I'm doing now, but those SOBs
> are tricky! I get the same result, but only after
> a tiny histogram stretch that they fail to mention
> to make the final image have the same gray-scale
> range as the original. Fortunately, I've written
> a book too, so the ol' enhance-the-image-so-it-looks-
> better-in-the-book trick is not new to me. :-)
>
> Cheers,
>
> David
>
> P.S. Let's just say that my original plan to write
> a nice, short image processing recipe book for IDL
> users looks like a harder project than I imagined.
> But then, again, I could have started with HISTOGRAM
> instead of CONVOL. :-)
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: registering images, shift(/nowrap)
Next Topic: Re: PRINT on same line

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 08:57:33 PDT 2025

Total time taken to generate the page: 0.00199 seconds