In the function ParseImagePattern() there has long been an error with 
the use_index parsing.

CASE (USE_INDEX_TOKEN)
	image->Use = USE_INDEX; // Should be USE_NONE
END_CASE

Yes, the set up is strange, but USE_NONE means don't use the color 
and/or alpha channels - but rather use the palette indexes. The other 
image parsing options look to be correct setting USE_NONE on seeing 
use_index. The parsing is set up with respect to what color channels to 
use - so even defining USE_INDEX is odd. It's probably a remnant from 
old code.

Aside 1 : The index handling is hard coded to 8 bits (0-255) which is 
gif compatible and will work many png or tiff palette images, but png 
supports options with fewer bits and the de-facto standard tiff can use 
a 16 bit palette format.

Stick with 8 bit palettes would be the rule for use_index.

FWIW. I didn't test other than gif palette images.

In addition to some additional parse time checking for use_color, 
use_alpha and use_index - I added an exception if someone attempts to 
use use_index where none exists in the input image.

Aside 2: In a surprise to me, the use_alpha option uses the red channel 
when it cannot find an actual alpha channel for the return values.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> Aside 2: In a surprise to me, the use_alpha option uses the red channel
> when it cannot find an actual alpha channel for the return values.
>

Confirmed in Windows v3.8.0 beta 1-- using a typical .png COLOR image_map for
the image_pattern (non-indexed and with no alpha-channel). BTW, I already had an
image_pattern test scene available from 2018, courtesy of a Thomas De Groot
post... but I never noticed this red-channel-only behavior.

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.

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

Post a reply to this message

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