On 3/15/23 09:00, Kenneth wrote:
> It seems to me that it should use the image's gray values instead (like a .gray
> equivalent). That would make more sense... and would be consistent with, for
> example, a bump_map (which uses the gray values for its normals by default).
> 
> The other inconsistency is the height_field-- which again uses only the red
> channel from a color image_map. That should use gray as well, IMHO.

The unfortunate answer here is it sometimes does use gray - when the 
channel depth is >8. There are other factors in play too which make the 
height_field from an image game complicated.

Using already true grey format images are simpler / safer - especially 
those written and read at 'gamma 1.0'.

> I wonder why these features are restricted to the red channel? Perhaps, when
> they were first introduced, the idea was that only gray-scale image_maps would
> be used in them(?)

Maybe.

I do not know how the focus on the red channel started with respect to 
reading color images. I have guesses too, like early versions of POV-Ray 
perhaps not having much for inbuilt color to grey conversions, but, I 
don't know. I agree that gray makes more sense, but probably better 
would be to throw an exception when the alpha channel the user wants is 
not present.

It often makes sense in todya's POV-Ray to use .red access for already 
gray images as you then avoid some calculation. You could use .green or 
.blue, but .red is fewer characters... Aside: Internally any time you 
run through the pigment code wrap you have color vectors / channels.

Bill P.

Post a reply to this message