POV-Ray : Newsgroups : povray.binaries.images : Stock colors and assumed_gamma 1 in POV-Ray 3.6 : Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6 Server Time
17 May 2024 23:05:14 EDT (-0400)
  Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6  
From: Ive
Date: 29 Oct 2020 05:20:15
Message: <5f9a894f@news.povray.org>
Am 10/29/2020 um 0:40 schrieb Kenneth:
> 
> "Science advances by taking two steps forward and one step back."
> Or here, maybe it was 1 step forward and two steps back :-P
> 
Well, even in science - at some point - findings turn into knowledge and 
facts. No astronomer or cosmologist has any doubt about Newtons laws of 
gravity and no - general relativity didn't proof them wrong, it still 
includes Newtons laws. By accepting them and using them we are even able 
to send probes to the border of the solar system by accelerating them 
with sling-shots around Jupiter.


> I sometimes think of the newsgroups as a kind of 'community sketch pad, where
> someone starts out by drawing a few basic shapes or blobs (the "idea"), then
> others start adding their own doodles, then erasures, then recapitulations of
> the 'history of art', then more doodles... until, hopefully at the end, there is
> a 'nice final picture' of the original idea. But sometimes its a real mess
> getting there, I agree. (And I'm certainly to blame, here.) But the final result
> can be... awesome! Too bad that we can't clean up the mess, by deleting all the
> extraneous stuff and dead ends. ;-) Ah, but that's the interesting (and messy)
> history of how we got to the end result... to be kept in the archives for all
> time, ha. :-O

Sure. But then someone (was it you? If so, I'm sorry I do not mean it 
personal) turns up with a link to some past discussion that is meanwhile 
(since 3.7) completely obsolete and frankly, complaining about a minor 
detail that could already be solved within 3.6 (poly_wave as I did 
suggest there) appears to me not like an epic battle, more like a boring 
minor battle of retreat.
So this NG is like the rest of the net. One has to learn how to assess 
and classify the threads written here in the past.

> 
> I'm genuinely curious about image_map use in that context, and how it is handled
> by POV-ray internally. You mentioned, I think, that the *linear* contents of the
> image's colors/brightness are used for internal computations(?), regardless of
> what we 'see' in the render. If I'm correct about that, do you know if radiosity
> from an image_map uses the *linear* values to 'shed its light' into the scene?

Since 3.7 (and assumed_gamma 1.0 of course):

Every image that is loaded via image_map is internally converted 
automagical into a linear representation. POV follows the rules of image 
file format specification and does everything right. In case you KNOW 
that the image you intent to load is different you can use the gamma 
modifier for image maps and tell POV-Ray what it should assume.
Like e.g. image_map {jpeg "my_image" gamma 1.8} for a jpeg file that was 
produced 30 years ago on a Mac.

Every image that is loaded via bump_map is assumed to be already a 
linear representation of the bumpiness (as it should be) and will 
internally be represented as is. In case you KNOW that your map is gamma 
encoded (for whatever reason) you should tell POV-Ray like e.g.
bump_map {jpeg "my_bump" gamma 2.2}.

As POV-Ray has no native support for transparency maps, specularity 
maps, roughness maps, metallicity maps (all of them are pretty much 
standard in professional PBR rendering and as such are always considered 
to be in linear color space as a de facto standard) but can use them 
with the help of the pigment_pattern statement one should always add 
gamma 1.0 to the image_map expression when the image is *NOT* meant to 
be an "image" but a map of some kind.

And radiosity? There is a reason that file file formats like OpenEXR and 
Radiance HDR are already per definition encoded in linear color space.
So, to answer your question, of course uses the radiosity calculation 
linear values.


A final remark: not using assumed_gamma 1.0 causes hue-shifts that 
become more dramatic the more complex the lighting situation is AND it 
violates the very basic low of energy conservation. There is no brick 
wall that reflects more light than shines on it.
If one has no problem with this two issues I'm absolutely fine with this 
but please do not complain about unexpected results.
And if somebody uses assumed_gamma 2.2 and produces a brilliant image 
I'm glad for him but this proofs nothing and is no reason to start this 
discussion again.


-Ive


Post a reply to this message

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