|
|
|
|
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 13 Jan 2010 08:17:51
Message: <4b4dc7ff@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Christian Froeschlin
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 13 Jan 2010 17:29:53
Message: <4b4e4961@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 14 Jan 2010 03:28:10
Message: <4b4ed59a$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 14 Jan 2010 07:28:08
Message: <4b4f0dd8$1@news.povray.org>
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 14 Jan 2010 08:01:02
Message: <4b4f158e$1@news.povray.org>
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
From: Jim Holsenback
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 14 Jan 2010 12:10:01
Message: <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?
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
Date: 15 Jan 2010 03:14:33
Message: <4b5023e9$1@news.povray.org>
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
From: Ive
Subject: Re: Difference in height_fields between beta 35 and previous betas or 3.6
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
|
|
| |
| |
|
|
|
|
| |