clipka <ano### [at] anonymousorg> wrote:
> Am 30.04.2010 21:34, schrieb Edouard:
>
> > I've got code to correct for this in my DF3 Proximity macros - the same problem
> > affects voxels with interpolation. I can change my macros if you change POV, but
> > is there a way to query a specific sub-version of POV? Can I query if I'm
> > running beta 37 vs beta 38?
>
> No, unfortunately there is no way to query sub-versions. You'll probably
> have to make a cut as soon as you switch to beta 38 (or whichever will
> introduce that change), and pretend that all 3.7 sub-versions have
> always behaved that way.
>
> After all, betas are still work in progress, so the behavior of version
> 3.7 is not fully defined until that version proper is released.

That's a fair call.

> > Also - are you sure its a bug? I managed to convince myself that it's the
> > correct behavior if the pixel's value is defined for the pixels coordinate (e.g.
> > <0,0>,<1,4>  or<1023,1023>) rather than half a pixel across (e.g.<0.5,0.5>,
> > <1.5,4.5>  or<1023.5,1023.5>). Does that make sense?
>
> Well, I guess that's a matter of definition. But I'm instead going by
> visual appearance, and cannot help but notice that the image /visually/
> shifts by half a pixel when turning on interpolation. And /that/ I do
> call a bug. If I want to smoothen an image, I typically don't want it to
> shift.

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?

> BTW, I didn't pay any thought to DF3s yet, so thanks for drawing my
> attention to those; while they use different code, I think it makes
> sense to have the same behavior for images and DF3s alike.

The code looks pretty cut and pasted, only with an extra dimension.

Cheers,
Edouard.

Post a reply to this message

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

Am 01.05.2010 00:16, schrieb clipka:

> 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.

Uh - of course that should read "... that the /center/ of the *pixel* be 
exaxtly at a certain point."

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> In all cases, the black dot is exactly at the center.
>
> As can quite easily be seen, when interpolation is activated the image
> appears slightly shifted to the bottom-right, in the order of magnitude
> of half a pixel.

I was somewhat aware of this; I think fixing it would be a good idea. But I'm
wondering about that bottom-right shift.

I just did an interpolation test on a 'test chart' image I made last year in
Photoshop. (It's 720X540, made up of lots of different single-pixel-width lines,
shapes, letters, etc. With no P.Shop antialising--just nice clean pixels. It's
main purpose was to test out my 'motion blur post-processing' animation code,
which simply averages multiple pre-rendered images by placing
them as image_maps on a box. The chart came in handy, to make sure I was getting
a 1:1, pixel-for-pixel reproduction of the images when copying them. This method
and code *do* reproduce the image_map faithfully, edge-to-edge and
corner-to-corner.)

So I did some tests in v3.6.1, using this image_map chart (with interpolate 2)
and the same 'copying' step as mentioned above. What I see is that the 'blur' is
shifted to the bottom-LEFT. (And also downward; sort of a combination of the two
directions.) I've posted some images of the tests over at p.b.i.--I can't seem
to do it here. (The orange lines correspond to your non-moving 'center dot.')

For test #1, the image_map is re-rendered 1:1 (that is, at 720 X 540) then blown
up in P.Shop by 800%, to more clearly show the shift--which, BTW, appears to be
by a full pixel, probably(?) just a result of the test's image rez. Test #2 was
re-rendered a 8-times the original--5760 x 4320--and NOT blown up in P.Shop.
(Although I *have* included a blown-up close-up of that.) Again, it looks like a
full-pixel shift. BTW, I thought this discrepancy between our results might have
something to do with the 'once' keyword; but it doesn't.

I'm puzzled by the difference in what we're getting. I'm wondering if I've done
something stupid in my methodology, or whether our test set-ups differ in some
fundamental way. Care to describe your test procedure?

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> ...The chart came in handy, to make sure I was getting
> a 1:1, pixel-for-pixel reproduction of the images when copying them. This
> method and code *do* reproduce the image_map faithfully, edge-to-edge and
> corner-to-corner.)

Hmm, I'm wondering if something in my own 'reproduction' code is the fault here.
Since I'm re-rendering typical 4/3 images, the box that they're applied to is
this (with the camera at x=0,y=0 and look_at the same):

box{
pigment{image_map...}}
translate <-.5,-.5,0>
scale <4/3,1 1>
}

The 4/3 scaling is the only oddity I can think of.

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:

> Hmm, I'm wondering if something in my own 'reproduction' code is the fault here.
> Since I'm re-rendering typical 4/3 images, the box that they're applied to is
> this (with the camera at x=0,y=0 and look_at the same):
>
> box{
> pigment{image_map...}}
> translate <-.5,-.5,0>
> scale <4/3,1 1>
> }
>
> The 4/3 scaling is the only oddity I can think of.
>

Nope; I just did a far-simpler test (square box, square image_map, no
'motion-blur' code at all) and I still see the bottom-LEFT shift.  So I'm still
puzzled. Perhaps there's been some kind of change between v3.6.1 and one of the
betas?

Ken

Post a reply to this message

Am 01.05.2010 08:59, schrieb Kenneth:

> I was somewhat aware of this; I think fixing it would be a good idea. But I'm
> wondering about that bottom-right shift.
...
> So I did some tests in v3.6.1, using this image_map chart (with interpolate 2)
> and the same 'copying' step as mentioned above. What I see is that the 'blur' is
> shifted to the bottom-LEFT. (And also downward; sort of a combination of the two
> directions.) I've posted some images of the tests over at p.b.i.--I can't seem
> to do it here. (The orange lines correspond to your non-moving 'center dot.')

Duh - now that you mention it, I realize that my test setup mirrors the 
test image horizontally. So yes, you're right: It is a shift to the 
bottom-LEFT with respect to the original picture.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Duh - now that you mention it, I realize that my test setup mirrors the
> test image horizontally. So yes, you're right: It is a shift to the
> bottom-LEFT with respect to the original picture.

Ah, the ol' mirror-trick, eh? So I guess something *did* change since
3.6.1--'clipka's mirror.' ;-P

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> ...Test #2 was re-rendered a 8-times the original--5760 x 4320--and NOT blown
> up in P.Shop. (Although I *have* included a blown-up close-up of that.) Again,
> it looks like a full-pixel shift.

Sorry, I was mistaken about that; it *is* a 1/2-pixel-shift, in the context of
what is meant here. (I got confused about what '1 pixel vs. 1/2 pixel' meant.)

For Clipka:
Something else that occurs me to me about my posted image tests (something
obvious, and you probably realized this already) is that the 1/2 shift during
interpolation is a shift *based on the original pixels of the image_map* (NOT a
1/2 shift in the pixels of the *re-rendered* image of the image_map.) To help
explain that more clearly: My 720 X 540 test chart with its single-pixel-lines,
when re-rendered at 8X its size, creates 8-pixel-wide lines; that's perfectly
understandable. But when interpolated, it creates an 8-pixel shift to the left
and down (i.e., not 1/2 or 1 pixel as I would have expected.)  With the
interpolate 'blur' filling an area of 16 pixels--twice the width of the 8-pixel
line. I wonder if this behavior makes sense?  Don't know; I would have expected
far less blur and far less 'movement' in such a case.

What this seems to mean is that the shift that we currently see (and the
'amount' of interpolation) is based on the magnification factor when
re-rendering the image_map's pixels. For example, say the image_map is on a box
that's deep into z, so that it re-renders at a fraction of its real size. (Which
is usually the case.) In such a case, the re-rendered shift would be far less
than 1/2 pixel, to my mind. Which I *guess* is a good thing(?)

I don't quite know what to make of this; but I thought I'd mention it. It may
have a bearing on how you figure out your corrections.

Ken

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> As can quite easily be seen, when interpolation is activated the image
> appears slightly shifted to the bottom-right, in the order of magnitude
> of half a pixel.
>
> Normally I'd just fix that offset, but it has probably been there since
> eons - and changing it might actually break a few scenes that have
> deliberately worked around this issue (I have at least once designed
> such a scene).
>
> How do you feel about it?

Since it would probably eliminate the diagonal drifting of images for things
like ripple tank and CA sims, I'm all for it.

Post a reply to this message