Re: interpolation for a color image?

Harris <xgeorgiou@xxxxxxxxxxxxx> writes:

My answer is this: bilinear is not a good interpolation method but it is
fast. Since it works in 2D, it
requires 12 multiplications and 4 divisions per (new) pixel estimate. If
you have any doubt, see:
http://en.wikipedia.org/wiki/Bilinear_interpolation. Your "paraphrase"
of what I initially proposed is too
slow, because you don't really need all these conversions, only an
intensity estimate (RGB -> mono)
and the original image:

(1). I(x,y) = a*R(x,y)+b*G(x,y)+c*B(x,y)
(2). apply bilinear interpolation on I(x,y)
(3). convert back to RGB

Step 2 is the same as above, e.g. 12 multiplications and 4 divisions for
bilinear per (new) pixel value.
Step 3 can be implemented using the original channel value and the value
range: if I'(x,y) is the
interpolated value, then new Red is: R'(x,y) = I'(x,y)/I(x,y) * R(x,y).

The problem I see with this is that you're effectively calculating the
higher-resolution image by recombining a luminance/intensity image
that was obtained by linear interpolation and colour information that
was upsampled by nearest-neighbour. The latter is a terrible upsampling
method that doesn't actually interpolate anything.

In the case where the original has two adjacent pixels of similar
colour but different intensity, the larger output image will smoothly
interpolate that intensity across the original one-pixel distance.
But if the two pixels have the same intensity but different colour,
there will be an abrupt colour change half-way along a line between the
two original pixel locations. So the colour component of the image will
have some nasty artifacts in it.

Now, you can argue that under certain viewing conditions, your eye's
colour resolution is bad enough that you can't see the colour artifacts,
so they don't matter. True. But you will get an image that looks
significantly worse up-close than interpolating in all 3 components
(whether that's in RGB or YCbCr).

My proposal requires 1x (3.mul
+ bilinear + 1.mul+1.div) = 16.mul+5.div per pixel, which can be
implemented easily with integer
arithmetic in steps 1 and 3 (no explicit ratios used).

Another problem is that division is generally *much* slower than other
operations, even multiplication, so it's worth avoiding whenever
possible. Standard convolution-based resizing uses lots of multiplies
and adds but no division at all. Throw in a few divisions, and you may
take longer to get a result even with a fraction of the number of
operations total.

In addition, much hardware these days can do a multiply-accumulate
operation as fast as a multiply alone, and sometimes it can do 4
multiply-add operations on suitably-arranged vector data as fast as a
single multiply on scalar data. What is fast and what is slow depends
on how well the computation fits the available hardware.

Dave
.

Relevant Pages

  • Re: interpolation for a color image?
    ... bilinear is not a good interpolation method but it is fast. ... requires 12 multiplications and 4 divisions per pixel estimate. ... multiplications and 1 addition per greyscale pixel. ... You will end up dividing by zero when I= 0. ...
    (sci.image.processing)
  • Re: Polynomial Function ...
    ... Polynomial semplification: ... through the successive multiplications; see below) ... His suggestion of interpolation is good, though I tend to add a quadratic term ... Only you can determine if the loss of resolution due to e.g. truncating ...
    (comp.arch.fpga)