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

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

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

It isn't reversed. It is in exactly in the same coordinate system as in all
other images!

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

It is correct just like for all other image map types.  As I pointed out, try
to substitute the function image by a plain image map.  You will notice that
the origin of the image is of course still at (0,0) in image coordinates,
which equals (0,1,0) in POV-Ray coordinates.  The function is also at exactly
this place, (0,0) in image coordinates and (0,1,0) in POV-Ray coordinates.

So you generate an image using a function inside the image coordinate system,
which goes from (0,0) to (1,1) where (0,0) is defined as the upper left and
(1,1) as the lower right.  The (0,0) is then mapped to (0,1,0) and the (1,1)
is mapped to (1,0,0) like for all other image formats.


    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 isn't reversed. It is in exactly in the same
> coordinate system as in all other images!

Please see my other reply to you in this thread where I have better
explained my point.

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

It will be interesting to see how many more of these Rune vs. Thorsten
fights will we see before the final release... ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" wrote:
>   It will be interesting to see how many more of these
> Rune vs. Thorsten fights will we see before the final
> release... ;)

I consider a discussion to be an attempt at obtaining mutual understanding.
I don't care if Thorsten convinces me or I convince him, I just don't like
when one part quit the discussion before mutual understanding has been
reached...

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

Rune <run### [at] mobilixnetdk> wrote:
> I consider a discussion to be an attempt at obtaining mutual understanding.
> I don't care if Thorsten convinces me or I convince him, I just don't like
> when one part quit the discussion before mutual understanding has been
> reached...

  Sometimes just stopping is the only solution if the other one just refuses
or is incapable of understanding.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message