POV-Ray : Newsgroups : povray.beta-test : Shift of interpolated images : Re: Shift of interpolated images Server Time
2 Jul 2024 10:56:07 EDT (-0400)
  Re: Shift of interpolated images  
From: clipka
Date: 30 Apr 2010 18:16:17
Message: <4bdb56b1$1@news.povray.org>
Am 30.04.2010 23:08, schrieb Edouard:

> I think, technically, the uninterpolated image is in error, but that also breaks
> people's expectations.
>
> Also, think of mapping a square image onto a square poly with one corner at
> <0,0>  - do you want the value at<0,0>  to be that of the corner most pixel?

I think it becomes clearer when you're considering two special cases 
that need to be handled somehow:

(1) Using images as tiles.

When tiling a plane with a repeating image pattern (i.e. an image 
without the "once" keyword), you obviously want the image to repeat in a 
"sane" interval; if the image size in POV's coordinate space is 
nominally 1x1 units, you want the resulting pattern to repeat exactly 
every 1.0 units. You also want each pixel of the image to take up the 
same space.

Assuming the original image to be square for simplicity (but of course 
the argument can be extended to non-square images as well), with a size 
of N*N pixels, this means that in POV's coordinate space, each pixel 
should have an edge length of exactly (1/N) units - no more and no less 
- in POV's coordinate space.

(2) Mapping onto a unit cube.

If you map an image pattern onto a unit cube (say, 
"box{<0,0,0>,<1,1,1>}", obviously you will typically want /all/ 
"corners" of the image to "coincide" with the cube's corners, without 
requiring you to perform any scaling. Now what exactly would "image 
corners" and "to coincide" mean in this context?

A first thought might be to think of the "image corners" as /the pixels/ 
in the image's corners, and of "to coincide" as meaning that the 
/center/ of the image be exactly at a certain point.

Note however that if you place the center of pixel (0;0) at the cube 
corner <0,0,0>, the center of the corner pixel diagonally across - which 
is pixel (N-1;N-1) - will wind up /not/ at <1,1,0>, but rather at 
<(N-1)*(1/N),(N-1)*(1/N),0>, as we required in (1) that a pixel should 
have an edge length of (1/N).

That is, given the constraints in (1) and the definition of "image 
corners" and "to coincide" just outlined, we /cannot/ have all "corners" 
of the image "coincide" with the cube's corners.

There is actually only /one/ single way to do this without violating the 
constraints given in (1):

We must define "image corners" as the /outer corners of the outer 
pixels/ - that is, the top-left corner of pixel (0;0), the top-right 
corner of pixel (N-1;0), the bottom-left corner of pixel (0;N-1), and 
the bottom-right corner of pixel (N-1;N-1). If these very "corner pixel 
corners" end up at the cube corners, we have fulfilled both the 
contraints in (1) /and/ (2).

Actually, if we think of pixels not as points but rather as tiles, I 
think this definition of "image corners" is perfectly natural.


And this is exactly what non-interpolated images give us.

So yes, I think the no-interpolation-way of positioning the image is 
absolutely right, and interpolated modes should follow suit.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.