The function image type is mirrored vertically.
It does take values in the 0 to 1 range both horizontally and vertically as
it should, but the y values go from 1 to 0 instead of from 0 to 1.

The code below shows the bug. Can anybody confirm?

camera {location -3*z}
#default {finish {ambient 1}}
#declare F = function {pattern {spherical}}
plane {
   -z, 0
   pigment {function {F(x,y,z)}}
}
box {
   <0,0,-0.001>,<1,1,1>
   pigment {
      image_map {function 100, 100 {F(x,y,z)}}
   }
}

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Confirmed.

Beta 15.msvc, Windows 2000, AMD Athlon-C 1.33GHz, 768MB RAM.

Post a reply to this message

In article <3cae24da@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> The code below shows the bug. Can anybody confirm?

It is not a bug in POV-Ray but in your scene.  The origin of the image is at
the upper left of the box while the origin of the function is the center of
the image.  Applying an image map instead of the function image will clarify
the origin.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> It is not a bug in POV-Ray but in your scene.
> The origin of the image is at the upper left
> of the box while the origin of the function
> is the center of the image. Applying an image
> map instead of the function image will clarify
> the origin.

Funny, because when rendering the code below I see an upside-down image.
Another bug in my scene?

camera {location -3*z}
#default {finish {ambient 1}}
#declare I = function {pigment {image_map {png "test.png"}}}
#declare F = function {I(x,y,z).gray}
plane {
   -z, 0
   pigment {function {F(x,y,z)}}
}
box {
   <0,0,-0.001>,<1,1,1>
   pigment {
      image_map {function 100, 100 {F(x,y,z)}}
   }
}

Post a reply to this message

In article <3caeba7d$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> It is not a bug in POV-Ray but in your scene.  The origin of the image is at
> the upper left of the box while the origin of the function is the center of
> the image.  Applying an image map instead of the function image will clarify
> the origin.

Wouldn't it be much less confusing for the users if the function used 
scene-space coordinates instead of image-space? Then a function image 
could be used as a direct drop-in replacement for a function.
Does this affect anything else? If I remember correctly, images from 
file formats with a different coordinate system (< 0, 0> at the lower 
left, for instance) are modified to be oriented properly, couldn't the 
same be done for function images?

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" wrote:
> Wouldn't it be much less confusing for the users
> if the function used scene-space coordinates instead
> of image-space?

Of course it would. The current behavior is completely illogical. It puts
everything upside down.

> Does this affect anything else?

There's no need for any exceptions or special cases. Currently everything is
upside down. It should be fixed so that everything is correctly aligned. The
y values passed to the function in the 0 to 1 range should not be reversed
as they currently are.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3caec8fe$1@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Funny, because when rendering the code below I see an upside-down image.
> Another bug in my scene?

Yes, because I said you should use an image map instead of the function image
to see that it works correctly:

box {
   <0,0,-0.001>,<1,1,1>
   pigment {
      image_map {image_map {png "test.png"}}
   }
}

When doing this you will notice that the origin of the image is at exactly the
same place where the function is.  This is the way image maps always worked,
so it won't be changed because it would break far too many scenes.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

> Wouldn't it be much less confusing for the users if the function used
> scene-space coordinates instead of image-space?

But then it wouldn't be an image map any more:  The image simply can't know
where and how it is applied.  What you are suggesting sounds like uv-mapping
of some kind.

> file formats with a different coordinate system (< 0, 0> at the lower
> left, for instance) are modified to be oriented properly, couldn't the
> same be done for function images?

The current origin is *correct*.  Of any image the origin is at the upper left
corner and POV-Ray (tries) to make this true for all image formats (afaik only
TIFF allows other origins anyway).  If you check replace the function image by
a plain image map (or simply look at the source code) you will find that the
same is true for the function image.  The origin is that the upper left of the
image map that is being created.

Sure, the origin can be chosen arbitrarily, but for all computer images the
accepted standard (probably because that is where the beam usually starts on
CRTs) is to have the origin at the upper left rather than the lower left
commonly used in mathematics.

POV-Ray intentionally takes a middle way and "compensates" (see comment in
function 'map' in 'image.cpp') for this and places the image origin for an
image mapped "once" at <0,1,0>.  So as all other image types use the upper
left as origin together with this "compensation" it would be really illogical
to use the lower left for function images and thus not to compensate for it
just to allow Rune's special case exception.


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Rune" wrote:
> There's no need for any exceptions or special cases.

Sorry Chris, from Thorsten's replies I can understand that I misunderstood
something. If internally the function image type is reversed due to the way
all image maps work, then a special case should be made for the function
image type so that it isn't reversed, and so that it works in a consistent
way for the user.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

"Thorsten Froehlich" wrote:
> Yes, because I said you should use an image map
> instead of the function image to see that it works
> correctly:

All other image types may work correctly, but the function image type is
reversed. I'm not saying that all image types are wrong, just the function
image type. It may be that internally the function image type works
consistently with the other image types, but for the user it works very
inconsistently with the other image types, and this should be corrected. The
current behavior is highly unintuitive and very annoying to work with.

> This is the way image maps always worked, so it won't
> be changed because it would break far too many scenes.

So you're saying that a thing like reversing just one image type (the
function image type), which sounds like a piece of cake to do, actually is a
difficult task to change??? I had no idea!

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message