POV-Ray : Newsgroups : povray.beta-test : Difference in height_fields between beta 35 and previous betas or 3.6 : Re: Difference in height_fields between beta 35 and previous betas or 3.6 Server Time
4 Jul 2024 13:27:02 EDT (-0400)
  Re: Difference in height_fields between beta 35 and previous betas or 3.6  
From: Ive
Date: 15 Jan 2010 04:28:16
Message: <4b503530@news.povray.org>
Thomas de Groot wrote:
> Concerning the topic, I am (still) surprised and confused about the whole 
> issue. I confess that I don't understand at all why or how this gamma stuff 
> influences on height_field maps, whatever the image format, and why there is 
> no issue with image_maps used directly in a height_field and not called by a 
> function. I think that explanation would also be needed in the docs....
> 

As Christoph seems to be not around ATM I'll try to explain. As stated 
within the release notes for BETA 35 the image file input gamma handling 
has changed.
As a side note this makes also my recommendation to convert JPEG files 
that are used as image maps to 16bps PNG files with an external program 
obsolete as JPEG (and all other image file formats) can now be used as 
they are and will render correctly without any loss of information.

The handling of image files that are *directly* used within a 
height_field statement has *not* changed at all as POV-Ray correctly 
assumes that gamma correction for height-field data does not make sense 
at all and the "color" values stored in such a file are meant literally.
But as POV-Ray does not know that you might want to use an image file 
that is loaded as a *pigment* at some point within a function to create 
a hight-field you'll get the unexpected result you did observe.

By adding the new keyword file_gamma with a value of 1.0 like:
pigment {image_map {jpeg "mymap.jpg"  file_gamma 1.0  interpolate 2} }
you basically tell POV-Ray that *no* gamma correction should be applied 
to this image (as the POV-Ray internal color working space is linear we 
have file_gamma = 1.0 to working_gamma 1.0 which means no change and the 
image when used within a function for height-field generation will now
behave in the same way as used within a height_field statement.

Another important consequence: the same is true for images that are 
meant as transparency or specularity maps within a pigment_pattern 
statement. You'll also have to add file_gamma 1.0 to get the correct 
results.

For short: always add file_gamma 1.0 when the image_map is not intended 
to be used just as a pigment for a texture.

-Ive


@Thomas: thanks for the piece of bread, much appreciated ;)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.