 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The attached image (1) shows the effect of interpolation on images; from
left to right:
- "interpolate 0", i.e. no interpolation
- "interpolate 2", i.e. bilinear
- "interpolate 3" (currently not supported)
- "interpolate 4", i.e. normalized distance
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.
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?
My personal vote would be to fix it nonetheless, to end up like shown in
the attached image (2). (And yes, that's bicubic interpolation you see
in the "interpolate 3" field.)
Post a reply to this message
Attachments:
Download '_interpolation_shift.png' (25 KB)
Download '_interpolation_fix.png' (30 KB)
Preview of image '_interpolation_shift.png'
Preview of image '_interpolation_fix.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/30/2010 09:52 AM, clipka wrote:
> My personal vote would be to fix it nonetheless, to end up like shown in
> the attached image (2). (And yes, that's bicubic interpolation you see
> in the "interpolate 3" field.)
I guess that explains your recent Wiki activity! I'd vote yes as well
...if it means picking up the bicubic feature while you're at it :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.04.2010 16:14, schrieb Jim Holsenback:
> On 04/30/2010 09:52 AM, clipka wrote:
>> My personal vote would be to fix it nonetheless, to end up like shown in
>> the attached image (2). (And yes, that's bicubic interpolation you see
>> in the "interpolate 3" field.)
>
> I guess that explains your recent Wiki activity! I'd vote yes as well
> ...if it means picking up the bicubic feature while you're at it :-)
I can add the bicubic feature without changing the old interpolation
methods' behavior, so no conditionals here please ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> The attached image (1) shows the effect of interpolation on images; from
> left to right:
>
> - "interpolate 0", i.e. no interpolation
> - "interpolate 2", i.e. bilinear
> - "interpolate 3" (currently not supported)
> - "interpolate 4", i.e. normalized distance
>
> 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.
>
> 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?
>
> My personal vote would be to fix it nonetheless, to end up like shown in
> the attached image (2). (And yes, that's bicubic interpolation you see
> in the "interpolate 3" field.)
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?
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?
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> 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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
