Hi Mark,

> >No, AffineTransformOp does treat the source as:
> >
> >        +-----+-----+
> >        |     |     |
> >        |  0  |  2  |
> >        |     |     |
> >        +-----+-----+
> >
>
> Ah, you view the above as the function:
>
>         2 -         /----
>                    /
>                   /
>                  /
>                 /
>         0 - ---/
>
>             |  |  |  |  |
>             0     1     2
>
> The flat 'wings' at edges make all the difference.  I suppose this is the
> downside of using bilinear interpolation rather than a well windowed sinc
> kernel of at least a few pixels.

We treat the source as the following. You can see it if you use the
TYPE_NEAREST_NEIGHBOR hint.

        2 -       |------
                  |
                  |
                  |
                  |
        0 - ------|

            |  |  |  |  |
            0     1     2

The function you pointed out is the result of bilinear interpolation
with source extension, where the edge pixels are duplicated outward
if there are not enough neighboring pixels available for bilinear
interpolation. The flat 'wings' only occur at the edges of an image
rather than the edges of objects inside the image.

BTW, there are more interpolation types in JAI, such as INTERP_BICUBIC
and INTERP_BICUBIC2.

>
> >For scaling 5x in X direction with bilinear interpolation,
> >
> >  Input pixels          0    2
> >  Theoretical output    0.00 0.00 0.00 0.40 0.80 1.20 1.60 2.00 2.00 2.00
> >  Current output        0    0    0    0    0    1    1    1    2    2
> >
> >But if you use 200 instead of 2 for the second pixel value, then
> >
> >  Input pixels          0  200
> >  Theoretical output    0.00 0.00 0.00 40.0 80.0 120. 160. 200. 200. 200.
> >  Current output        0    0    0    39   79   119  159  199  200  200
> >
>
> Eeek - this is quite a bad job of rounding!  (Actually, it is even a bad
> job of truncating!  But, in this case, one has to round.) Given that the
> outputs are generally 8-bit component values, being off by 1 is not so hot.
>
> I can't see why your computations can't do a decent round.  If you are
> computing in floating point you should be able to round as you convert to
> integer.  If you are computing in fixed point, then we're talking about a
> mere integer add.
>
>         - Mark
>

As I said, the native function underlying AffineTransformOp was
developed for the highest speed and with somewhat sacrifice on
precision. The code has been updated to generate results in
"round to the nearest integer" mode, which unfortunately causes
a 5% slowdown. Here are the current results for that example:

For scaling 5x in X direction with bilinear interpolation,

  Input pixels          0    2
  Theoretical output    0.00 0.00 0.00 0.40 0.80 1.20 1.60 2.00 2.00 2.00
  Current output        0    0    0    0    1    1    2    2    2    2

  Input pixels          0  200
  Theoretical output    0.00 0.00 0.00 40.0 80.0 120. 160. 200. 200. 200.
  Current output        0    0    0    40   80   120  160  200  200  200

Regards,

-James Cheng

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to