Complex-Valued Signal Processing

Hello everybody:

Is there any reference (books, surveys) on complex-valued signal
processing on 2D domain?

Specifically, I want to find something introductory related to complex-
valued convolution.

I'm digging through google.  Most of the reference I found are either
dealing with classical signal processing, or rather fragmented to
read.

Can somebody help?

Thanks.

W

On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
> Hello everybody:
>
> Is there any reference (books, surveys) on complex-valued signal
> processing on 2D domain?
>
> Specifically, I want to find something introductory related to complex-
> valued convolution.
>
> I'm digging through google. &#4294967295;Most of the reference I found are either
> dealing with classical signal processing, or rather fragmented to
> read.
>
> Can somebody help?
>
> Thanks.
>
> W

Try this

http://www.bessernet.com/articles/DSP/RickQuadSignals.pdf

Clay

On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
> Hello everybody:
>
> Is there any reference (books, surveys) on complex-valued signal
> processing on 2D domain?
>
> Specifically, I want to find something introductory related to complex-
> valued convolution.
>
> I'm digging through google. &#4294967295;Most of the reference I found are either
> dealing with classical signal processing, or rather fragmented to
> read.
>
> Can somebody help?
>
> Thanks.
>
> W

Complex-valued convolution isn't much different from real-valued
convolution. It just means that either your input vector, coefficient
vector, or both can be complex. The output of the convolution is still
defined as the inner product between the coefficient vector and the
appropriate segment of the input vector. Is there something specific
that you were looking for?

Jason

Thanks to Clay and Jason:

What I want is a panoramic view on the applications and theory of
complex signal processing.

I did some research work using the theory based on complex analysis
and analytical functions and I want to find out parallel ideas and
applications in other fields, and maybe possible extensions.

I'm not in the field of signal processing, so I don't even familiar
with the jargon to search in the google.com.

But at least I know it's called 'complex signal processing' now.

Thanks again.

On Aug 21, 9:35&#4294967295;am, Jason <cincy...@gmail.com> wrote:
> On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>
>
>
> > Hello everybody:
>
> > Is there any reference (books, surveys) on complex-valued signal
> > processing on 2D domain?
>
> > Specifically, I want to find something introductory related to complex-
> > valued convolution.
>
> > I'm digging through google. &#4294967295;Most of the reference I found are either
> > dealing with classical signal processing, or rather fragmented to
> > read.
>
> > Can somebody help?
>
> > Thanks.
>
> > W
>
> Complex-valued convolution isn't much different from real-valued
> convolution. It just means that either your input vector, coefficient
> vector, or both can be complex. The output of the convolution is still
> defined as the inner product between the coefficient vector and the
> appropriate segment of the input vector. Is there something specific
> that you were looking for?
>
> Jason

On Aug 21, 9:35&#4294967295;am, Jason <cincy...@gmail.com> wrote:
> On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>
>
> > Specifically, I want to find something introductory related to
> > complex-valued convolution.
>
>
> Complex-valued convolution isn't much different from real-valued
> convolution. It just means that either your input vector, coefficient
> vector, or both can be complex. The output of the convolution is still
> defined as the inner product between the coefficient vector and the
> appropriate segment of the input vector.

one thing to watch out for, i believe, that when performing the inner
product of two complex elements, i believe that involves conjugating
the element on the right.  i can't remember why this has to be the
case, but Clay might remember.

r b-j

On Aug 21, 1:10&#4294967295;pm, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Aug 21, 9:35&#4294967295;am, Jason <cincy...@gmail.com> wrote:
>
> > On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>
> > > Specifically, I want to find something introductory related to
> > > complex-valued convolution.
>
> > Complex-valued convolution isn't much different from real-valued
> > convolution. It just means that either your input vector, coefficient
> > vector, or both can be complex. The output of the convolution is still
> > defined as the inner product between the coefficient vector and the
> > appropriate segment of the input vector.
>
> one thing to watch out for, i believe, that when performing the inner
> product of two complex elements, i believe that involves conjugating
> the element on the right. &#4294967295;i can't remember why this has to be the
> case, but Clay might remember.
>
> r b-j

In simple terms a magnitude squared is conj(Z) * Z.

But a look at Hermitian Operators will likely help illuminate the
usefulness of doing the conjugation.

Hermition Ops have real eigenvalues and orthogonal eigenfunctions
which often prove useful.

Clay

On 21 Aug, 19:10, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Aug 21, 9:35&#4294967295;am, Jason <cincy...@gmail.com> wrote:
>
> > On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>
> > > Specifically, I want to find something introductory related to
> > > complex-valued convolution.
>
> > Complex-valued convolution isn't much different from real-valued
> > convolution. It just means that either your input vector, coefficient
> > vector, or both can be complex. The output of the convolution is still
> > defined as the inner product between the coefficient vector and the
> > appropriate segment of the input vector.
>
> one thing to watch out for, i believe, that when performing the inner
> product of two complex elements, i believe that involves conjugating
> the element on the right. &#4294967295;i can't remember why this has to be the
> case, but Clay might remember.

Generally speaking: Yes. The inner product between complex-valued
vectors x and y is computed as

c = <x,y> = sum x[n]*conj(y[n])

where the sum is taken over the elements in the vectors.

However, what convolution is concerned, none of the vectors
involved should be conjugated.

The quick'n dirty argument is that in DFT domain the
cnvolution is written as

DFT{ x (*) y }[k] = DFT{ x }[k] DFT{ y }[k].

Since no conjugates or index reversals appear in the DFT
domain, no conjugates or index reversal should appear in
the data domain. More formally, the same formulas appear
(with no conjugates) appear for complex-valued data if
one derives the convolution sum formula from scratch,
from the LTI properties of the system.

Rune

On Thu, 20 Aug 2009 14:51:52 -0700 (PDT), Clay <clay@claysturner.com>
wrote:

>On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>> Hello everybody:
>>
>> Is there any reference (books, surveys) on complex-valued signal
>> processing on 2D domain?
>>
>> Specifically, I want to find something introductory related to complex-
>> valued convolution.
>>
>> I'm digging through google. &#4294967295;Most of the reference I found are either
>> dealing with classical signal processing, or rather fragmented to
>> read.
>>
>> Can somebody help?
>>
>> Thanks.
>>
>> W
>
>Try this
>
>http://www.bessernet.com/articles/DSP/RickQuadSignals.pdf
>
>Clay

Hi Clay,
  an updated version (the most current version) of that 
material is at:

http://www.dspguru.com/info/tutor/quadsig.htm

See Ya',
[-Rick-]

On Aug 21, 1:40&#4294967295;pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 21 Aug, 19:10, robert bristow-johnson <r...@audioimagination.com>
> wrote:
>
>
>
> > On Aug 21, 9:35&#4294967295;am, Jason <cincy...@gmail.com> wrote:
>
> > > On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>
> > > > Specifically, I want to find something introductory related to
> > > > complex-valued convolution.
>
> > > Complex-valued convolution isn't much different from real-valued
> > > convolution. It just means that either your input vector, coefficient
> > > vector, or both can be complex. The output of the convolution is still
> > > defined as the inner product between the coefficient vector and the
> > > appropriate segment of the input vector.
>
> > one thing to watch out for, i believe, that when performing the inner
> > product of two complex elements, i believe that involves conjugating
> > the element on the right. &#4294967295;i can't remember why this has to be the
> > case, but Clay might remember.
>
> Generally speaking: Yes. The inner product between complex-valued
> vectors x and y is computed as
>
> c = <x,y> = sum x[n]*conj(y[n])
>
> where the sum is taken over the elements in the vectors.

okay, so there is no index reversal in doing an inner product of
vectors.


> However, what convolution is concerned, none of the vectors
> involved should be conjugated.
>
> The quick'n dirty argument is that in DFT domain the
> cnvolution is written as
>
> DFT{ x (*) y }[k] = DFT{ x }[k] DFT{ y }[k].
>
> Since no conjugates or index reversals appear in the DFT
> domain, no conjugates or index reversal should appear in
> the data domain. More formally, the same formulas appear
> (with no conjugates) appear for complex-valued data if
> one derives the convolution sum formula from scratch,
> from the LTI properties of the system.

i'm scratching my head a little bit.

isn't it because we *do* reverse the indices of one of the vectors in
convolution that we don't need to conjugate it?

so is convolution this:


    y[n] = (x (*) h)[n] = <x[i], h[n-i]>    ?

 or is it


    y[n] = (x (*) h)[n] = <x[i], conj(h[n-i])>    ?


h[n-i] is the vector you get with 0 <= i < N and n "fixed" by the left-
hand side.  and we're not gonna have this silly "Does the DFT really
periodically extend your data" question so we know what h[n-i] does
when n-i ain't in the same range without fussing.

what if the impulse response, h[n], of an LTI is complex, and it might
even have a complex input, x[n] ?  which of those y[n] is the right
output?

r b-j

On 23 Aug, 05:30, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Aug 21, 1:40&#4294967295;pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
>
>
>
>
> > On 21 Aug, 19:10, robert bristow-johnson <r...@audioimagination.com>
> > wrote:
>
> > > On Aug 21, 9:35&#4294967295;am, Jason <cincy...@gmail.com> wrote:
>
> > > > On Aug 20, 5:28&#4294967295;pm, smart <smartn...@gmail.com> wrote:
>
> > > > > Specifically, I want to find something introductory related to
> > > > > complex-valued convolution.
>
> > > > Complex-valued convolution isn't much different from real-valued
> > > > convolution. It just means that either your input vector, coefficient
> > > > vector, or both can be complex. The output of the convolution is still
> > > > defined as the inner product between the coefficient vector and the
> > > > appropriate segment of the input vector.
>
> > > one thing to watch out for, i believe, that when performing the inner
> > > product of two complex elements, i believe that involves conjugating
> > > the element on the right. &#4294967295;i can't remember why this has to be the
> > > case, but Clay might remember.
>
> > Generally speaking: Yes. The inner product between complex-valued
> > vectors x and y is computed as
>
> > c = <x,y> = sum x[n]*conj(y[n])
>
> > where the sum is taken over the elements in the vectors.
>
> okay, so there is no index reversal in doing an inner product of
> vectors.
>
> > However, what convolution is concerned, none of the vectors
> > involved should be conjugated.
>
> > The quick'n dirty argument is that in DFT domain the
> > cnvolution is written as
>
> > DFT{ x (*) y }[k] = DFT{ x }[k] DFT{ y }[k].
>
> > Since no conjugates or index reversals appear in the DFT
> > domain, no conjugates or index reversal should appear in
> > the data domain. More formally, the same formulas appear
> > (with no conjugates) appear for complex-valued data if
> > one derives the convolution sum formula from scratch,
> > from the LTI properties of the system.
>
> i'm scratching my head a little bit.
>
> isn't it because we *do* reverse the indices of one of the vectors in
> convolution that we don't need to conjugate it?

As I said, the argument based on the DFTs was quick'n dirty,
maybe too dirty.

I am not aware of any argument why one would need to change
the cojugate of a complex-valued vector in an *inner* *product*,
if we flip its direction. So I can't see why one would flip
the conjugate of h[n] in time domain of an LTI system just
because we reversed it in time domain.

Of course, when FTs are involved, if you flip the conjugate
in one domain you will have to reverse the index in the other.
You might well use that as a defining diffference between
the cross correlation between x and y, and the convolution of
x and y: In spectrum domain DFT{y} is conjugated in one case
and not in the other.

If you instead start with the LTI properties of the system
and derive the convolution sum formula from scratch, you will
find that the result for the complex-valued case looks exactly
like the result for the real-valued case.

In particular, the scaling property

x (*) ah  = a( x (*) h )

where (*) is convolution, is the same for both real-valued
and complex-valued scaling factors a.

Rune