"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

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

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

I'm not talking about the mapping applied to the image. I'm just saying 
that people aren't going to think in the internal POV-Ray image 
coordinate system when writing a function that may or may not be used in 
an image, and they shouldn't have to.


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

Actually, that is just an arbitrary choice. Most image formats work that 
way, but you can't make the assumption all do. There are several other 
formats besides TIFF that use different systems (I think SGI RGB is 
one), and some popular API's (OpenGL for example) use the lower left 
corner as the origin.

POV should compensate for the fact that a function's origin is at < 0, 
0, 0>, and not < 0, 1, 0>, as most image file formats have it. The 
internal coordinate system of the image should be hidden from the user. 
All they should have to care about is where the "top left" and "bottom 
right" map to in the scene coordinate system. Exposing it in this way is 
inconsistent, counter-intuitive and very user-unfriendly.

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

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

> All other image types may work correctly, but the function image type is
> reversed.

No, it isn't reversed, it only appears to be because of different coordinate
systems.  When generating the image the origin and coordiante system of an
image is used.  This means that the upper left is (0,0) and the lower right of
the image generated is function value (1,1).  This is consistent with the way
all image coordinates work.  Now, you are trying to place the image with its
origin (and coordinate system) over a function as a pattern which uses a
different origin (and coordinate system).

This isn't different from moving the box somewhere else and expecting the
image still to match the other function's 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

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

> I'm not talking about the mapping applied to the image. I'm just saying
> that people aren't going to think in the internal POV-Ray image
> coordinate system when writing a function that may or may not be used in
> an image, and they shouldn't have to.

This has nothing to do with "to think in the internal POV-Ray image coordinate
system" - see below.

> POV should compensate for the fact that a function's origin is at < 0,
> 0, 0>, and not < 0, 1, 0>, as most image file formats have it. The
> internal coordinate system of the image should be hidden from the user.

But there is no "internal coordinate system"!  The coordinate system used in
images is extremely important as otherwise images could have a random
orientation.  One simply cannot use images without defining their origin and
coordinate system.  As soon as you edit the image you are going to expose the
origin as well as the coordinate system to the user.  Without doing so editing
images would not be possible.

In conclusion the origin as well as the coordinate system are well defined in
POV-Ray and function images use this well defined coordinate system.  Sure,
this cannot fit all needs, but changing this simple and obvious origin and
coordinate system to some completely randomly choosing different origin and
coordinate system just to make it work in this one special buggy scene file is
simply unreasonable.

If you find it reasonable, fine, but I don't and given my clear and simple
reasoning I am not going to change my mind.  So we will continue to disagree
on this and any further discussion will lead nowhere.

    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:
> No, it isn't reversed, it only appears to be because
> of different coordinate systems.

Right, then one coordinate system is reversed vertically compared to the
other. Why do you say it isn't reversed when obviously everyone can see that
it is indeed reversed, no matter what you choose to call it?

> When generating the image the origin and coordiante
> system of an image is used.  This means that the
> upper left is (0,0) and the lower right of the image
> generated is function value (1,1).

Yet, strangely, when using an image map the upper left corner is at (0,1)
and the lower right corner is at (1,0). This is because POV-Ray takes care
of the correction for the user.

Why can't POV-Ray correct the alignment for the user when using the function
image type, so that the user won't see any hint of reversed coordinates?

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:
> But there is no "internal coordinate system"!
> The coordinate system used in images is extremely
> important as otherwise images could have a random
> orientation.

Agreed, coordinates are important. However, when working with images, users
expect up to be up and down to be down. They don't think that (0,0) must
always be (0,0) and (1,1) must always be (1,1) regardless of the coordinate
system used.

> One simply cannot use images without defining their
> origin and coordinate system.

Agreed.

> As soon as you edit the image you are going to
> expose the origin as well as the coordinate system
> to the user.

Depends on your definition of "exposing". Though many graphics programs show
the coordinates while editing, it's perfectly possible to draw an image
without thinking about the coordinates.

> Without doing so editing images would not be possible.

See above.

> In conclusion the origin as well as the coordinate system
> are well defined in POV-Ray and function images use this
> well defined coordinate system.

Images use one coordinate system while POV-Ray space use another coordinate
system. POV-Ray compensates for this, so that up remains up and down remains
down. But functions do not use a different coordinate system, and thus no
compensation should be done. In functions, when considering the square from
(0,0) to (1,1), it is the lower left corner that is the origin. Thus no
compensation should be done. Applying the compensation anyway only reverses
the image so that it's upside down.

> Sure, this cannot fit all needs, but changing this simple
> and obvious origin and coordinate system to some completely
> randomly choosing different origin and coordinate system
> just to make it work in this one special buggy scene file is
> simply unreasonable.

We're not discussing a random chosen origin and coordinate system. We're
discussing making sure that the alignment is correct regardless of the
origin and coordinate system used. I.e. making sure that upper right remains
upper right, lower left remains lower left etc. This is completely
consistent and reasonable and even intuitive too.

> If you find it reasonable, fine, but I don't and given
> my clear and simple reasoning I am not going to change
> my mind.

I find my reasoning clear and reasonable too and would like to continue to
discuss this matter.

> So we will continue to disagree
> on this and any further discussion will lead nowhere.

You haven't argued why POV-Ray should compensate in this case where
compensation is incorrect. All you have said is something like "compensation
is done for all image types and therefore it is correct". That isn't an
argument.

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