Beta 35 results in a significant difference in aspect of image_map 
height_fields, compared to previous betas or version 3.6. See examples in 
p.b.i.

I first thought the origin would be the way png images are treated, but the 
same happens with tga. the image_maps are 16 bit gray scale images.


top image rendered with megapov; identical to render with beta 34 and older.
bottom image rendered with beta 35.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> I first thought the origin would be the way png images are treated, but the
> same happens with tga. the image_maps are 16 bit gray scale images.

I made a joke about gamma values in p.b.i, but since you are getting your height
values from an image, I might have actually been close.  The valley floor
is flatter, the peaks are sharper, and I would bet money that the new beta is
doing gamma conversion on the height values when reading the image and older
versions didn't.  The image looks a lot like what I did years ago to get a flat
valley floor: square the height values, and typical gamma values are in the 1.8
to 2.2 range.

The quick workaround would be to gamma correct your height field image with a
value of 0.45 or 0.5 before letting the new beta read it in, reversing the new
bug.

Post a reply to this message

Thomas de Groot wrote:

> I first thought the origin would be the way png images are treated, but the 
> same happens with tga. the image_maps are 16 bit gray scale images.

still, you could try adding a "file_gamma" value after the file name
and see how changing it affects your image (in particular the values
1.0 and 2.2?).

Post a reply to this message

Further testing of the discrepancy reveals that it occurs when using a 
function for the height_field. Using an image_map directly into a 
height_field - wether it being a png or a tga - renders correctly and is 
identical in all versions.

Using the following function however - either with png or with tga - results 
in a *wrong* render. Is this due to gamma? I have no idea....

//----start code
#declare F_HF_01 =
function {
  pigment {
    image_map {
      tga "RidgedFractal1.tga" //or the same as png
      map_type 0
      interpolate 2
    }
    warp {repeat x}
    warp {repeat y}
    scale 50
    warp {
      turbulence 0.2
      octaves 1
      lambda 1
      omega 0.2
    }
    scale 1/50
  }
}

height_field {
  function 2000, 2000 {F_HF_01(x,y,z).hf}
  smooth
  translate <-0.5, 0.0, -0.5>
  texture {mytex}
  transform {mytrans}
}
//----endcode

Thomas

Post a reply to this message

"Christian Froeschlin" <chr### [at] chrfrde> schreef in bericht 
news:4b4e4961@news.povray.org...
>
> still, you could try adding a "file_gamma" value after the file name
> and see how changing it affects your image (in particular the values
> 1.0 and 2.2?).

Yes, this makes ALL the difference. Adding file_gamma 1.0  restores the 
*correct* render. Thanks Christian.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Beta 35 results in a significant difference in aspect of image_map
> height_fields, compared to previous betas or version 3.6. See examples in
> p.b.i.
>
> I first thought the origin would be the way png images are treated, but the
> same happens with tga. the image_maps are 16 bit gray scale images.

I'm curious if the same thing happens when using an image_map (for the function)
that doesn't have an embedded gamma. I.e., JPEG or TIFF (or BMP on a Windows
platform.) If such an image *does* work correctly, then at least part of the
problem would be with 'embedded' gamma and how beta 35 handles it.

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.4b4f114bbfa4a9765f302820@news.povray.org...
> I'm curious if the same thing happens when using an image_map (for the 
> function)
> that doesn't have an embedded gamma. I.e., JPEG or TIFF (or BMP on a 
> Windows
> platform.) If such an image *does* work correctly, then at least part of 
> the
> problem would be with 'embedded' gamma and how beta 35 handles it.
>

The answer is yes. With a JPEG image called by the function, the discrepancy 
happens too. Again, this can be corrected by adding file_gamma 1.0

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote in message 
news:4b4f158e$1@news.povray.org...
> The answer is yes. With a JPEG image called by the function, the 
> discrepancy happens too. Again, this can be corrected by adding file_gamma 
> 1.0

looks around ... wonders if someone is capturing this stuff to be added to 
the documentation.
not to subtle ... eh?

Post a reply to this message

"Jim Holsenback" <jho### [at] povrayorg> schreef in bericht 
news:4b4f4fe9@news.povray.org...
> "Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote in message 
> news:4b4f158e$1@news.povray.org...
>> The answer is yes. With a JPEG image called by the function, the 
>> discrepancy happens too. Again, this can be corrected by adding 
>> file_gamma 1.0
>
> looks around ... wonders if someone is capturing this stuff to be added to 
> the documentation.
> not to subtle ... eh?

Oh dear... I am willing to do that of course, concerning height_fields. I 
prefer to leave the gamma stuff to those who know what they are talking 
about.. I shall have first to familiarize myself (again) with wiki 
editing... :-)

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

Thomas

Post a reply to this message

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