blackbody and daylight functions


chrisbrejon@...
 

I'll just put your answer here because it made "click" in my head when I read it :

If you’re using a blackbody for a light colour it should be because you’re trying to simulate an incandescent of that temperature. 
Blackbody colours have precisely nothing to do with the colour of the sky. As others have mentioned the fact that literature refers to colours as “sky blue” is an attempt at classification.

Thanks again everyone, you rock !

Chris


Anders Langlands
 

Ah only just realised I didn’t reply-all! Thiago and Larry have said the same thing as I did anyway :)

On Tue, 12 Jan 2021 at 09:06, <chrisbrejon@...> wrote:
Thanks a lot everyone! I understand much better the topic now. ;-)
Anders Langlands has also been kind enough to reply and help me.

I often say that studying colour is a fight against my own beliefs and what I have learned these past 15 years.
Your answers make definitely sense and I apologize for not having understood your explanations earlier.

Have a good day all ! That's really much appreciated !!!

Chris


Larry Gritz
 

Color science is an area where I truly feel that the more I learn about it, the more I realize I didn't really understand and have been making embarrassing oversimplifications all along. Also the more I learn, the more I appreciate having a capable dedicated color scientist on staff because my own knowledge just barely scratches the surface.


On Jan 11, 2021, at 12:06 PM, chrisbrejon@... wrote:

Thanks a lot everyone! I understand much better the topic now. ;-)
Anders Langlands has also been kind enough to reply and help me.

I often say that studying colour is a fight against my own beliefs and what I have learned these past 15 years.
Your answers make definitely sense and I apologize for not having understood your explanations earlier.

Have a good day all ! That's really much appreciated !!!

Chris

--
Larry Gritz





chrisbrejon@...
 

Thanks a lot everyone! I understand much better the topic now. ;-)
Anders Langlands has also been kind enough to reply and help me.

I often say that studying colour is a fight against my own beliefs and what I have learned these past 15 years.
Your answers make definitely sense and I apologize for not having understood your explanations earlier.

Have a good day all ! That's really much appreciated !!!

Chris


Larry Gritz
 

Ah, I see, sorry for assuming you were poking around at the wrong thing.

The blackbody function is good for figuring out the color of something that is purely an emissive warm body, no more and no less. An incandescent filament, a glowing hot piece of metal, molten lava, etc. There's no particular reason to think this function would give you a good approximation to daylight sky, which is not a blackbody phenomenon.

If there is another function that gives the range of plausible overall daylight colors given a 1D input (which we can call "temperature", but doesn't relate quite as directly as a blackbody spectrum would), and this is useful in shaders for generating light colors, then by all means, we can add a new function to the spec. I think the implementation could probably be a lot simpler than what we've done for blackbody -- you may be able to implement it very simply in OSL itself with a couple of spline() calls with a fairly short array of values and get an adequate approximation to the desired function.

-- lg


On Jan 11, 2021, at 11:16 AM, chrisbrejon@... wrote:

Totally ! ;-)

Our studio is following the same path most studios are : we have an Hosek sky implementation since 2015 (if I recall correctly).
And we are indeed looking at Sebastien Hilaire's work for our next generation Skylight.

Sorry for repeating myself but my question was really about the temperature function for, let's say, an area light.
An artist may think : let's use a kelvin temperature of 20 000 to get a blue sky color on a rim. And because most render engines
rely on black body tables, the blue color will actually look quite purple (to me). Hence my question...

Of course, we would not want a "flat" color on a EnvLight but on an area or spot light to simulate a rim or a top light. A bit like this :
<dummyfile.0.part>

I guess my point is : in many renderer's documentation, you may read that black body temperatures above 15 000 would give you a sky blue color...
When actually it is not really a goof fit imo.

Sorry for the confusion, I don't mean to bother you guys. ;-)
Once again, your answers are much appreciated !

Chris

--
Larry Gritz





Thiago Ize
 

Blackbody works only for incandescent lights. Make it 20000K and it should look like what you posted (blue with hints of red). It'll still have red in it because all that changed from the hotter light is that correspondingly more blue was added, but red was never removed. This is why you can't get a pure blue. What you can do is drown out the red by having huge amounts of blue. Even hotter temps will emit lots of UV, but since we don't see that we'll just see it as more blue. Also, that's a crazy hot surface and probably not realistic...

In the real world filters would be applied to incandescent lights to filter out the red so we see it as more blue. Or LEDs or other non-incandescent lights are used which can generate specific frequencies of light.

Take a look at the graph in https://astronomy.swin.edu.au/cosmos/b/blackbody+radiation which shows how at 700nm the blue star is still outputting more red than the red star.

To summarize, blackbody for lights is for incandescent lights without filters. Anything else and the renderer should allow users to input colors in some other fashion, such as RGB.


On Mon, Jan 11, 2021 at 12:16 PM <chrisbrejon@...> wrote:
Totally ! ;-)

Our studio is following the same path most studios are : we have an Hosek sky implementation since 2015 (if I recall correctly).
And we are indeed looking at Sebastien Hilaire's work for our next generation Skylight.

Sorry for repeating myself but my question was really about the temperature function for, let's say, an area light.
An artist may think : let's use a kelvin temperature of 20 000 to get a blue sky color on a rim. And because most render engines
rely on black body tables, the blue color will actually look quite purple (to me). Hence my question...

Of course, we would not want a "flat" color on a EnvLight but on an area or spot light to simulate a rim or a top light. A bit like this :


I guess my point is : in many renderer's documentation, you may read that black body temperatures above 15 000 would give you a sky blue color...
When actually it is not really a goof fit imo.

Sorry for the confusion, I don't mean to bother you guys. ;-)
Once again, your answers are much appreciated !

Chris


chrisbrejon@...
 

Totally ! ;-)

Our studio is following the same path most studios are : we have an Hosek sky implementation since 2015 (if I recall correctly).
And we are indeed looking at Sebastien Hilaire's work for our next generation Skylight.

Sorry for repeating myself but my question was really about the temperature function for, let's say, an area light.
An artist may think : let's use a kelvin temperature of 20 000 to get a blue sky color on a rim. And because most render engines
rely on black body tables, the blue color will actually look quite purple (to me). Hence my question...

Of course, we would not want a "flat" color on a EnvLight but on an area or spot light to simulate a rim or a top light. A bit like this :


I guess my point is : in many renderer's documentation, you may read that black body temperatures above 15 000 would give you a sky blue color...
When actually it is not really a goof fit imo.

Sorry for the confusion, I don't mean to bother you guys. ;-)
Once again, your answers are much appreciated !

Chris


Larry Gritz
 

The "sky color by temperature" function is just a model that sort of relates color temperature to a plausible overall color of the sky integrated over all directions. In a rendering context, I'm not sure how or why you would use this. You certainly wouldn't want the sky to be this color, because it would be the same in all directions. What you really want is the correct directional radiance function.

Hosek/Wilkie "An Analytic Model for Full Spectral Sky-Dome Radiance" from SIGGRAPH 2012 is usually the go-to on this topic. That paper, and some other work from the same researchers, can be found here: https://cgg.mff.cuni.cz/projects/SkylightModelling/  I think most studios have an in-house shader that implements this paper or some fairly close variant. I believe there are open source implementations in various shading language already out there to be found with a little googling.

The state of the art is likely this year's EGSR 2020 paper from Sebastien Hillaire, "A Scalable and Production Ready Sky and Atmosphere Rendering Technique," which describes what's implemented in Unreal Engine. Here's the paper: https://diglib.eg.org/bitstream/handle/10.1111/cgf14050/v39i4pp013-022.pdf and here's the code (MIT licensed): https://github.com/sebh/UnrealEngineSkyAtmosphere

-- lg



On Jan 11, 2021, at 5:40 AM, chrisbrejon@... wrote:

And just for the record, it looks like there is a CIE standard for sky values :

This web app generates sky luminance and radiance distributions using the updated Perez All-Weather Sky model, as defined in ISO 15469:2004(E) and CIE S 011/E:2003. You can dynamically adjust each of the Perez sky coefficients individually, choose any of the 16 CIE Standard General Skies, set your own direct and diffuse illuminance/irradiance values, or use annual hourly weather data for dynamic simulations or cumulative sky distributions. It also provides a range of different sky subdivision techniques and resolutions, including Tregenza’s 145 patch sky and Reinhart’s extensions.

The Commission Internationale de l’Éclairage (CIE) has defined a set of 15 standard sky types for modelling the radiance/luminance distribution under a wide range of weather conditions from overcast to cloudless, and with or without direct sunlight. The 16th varient corresponds to a much simpler mathematical model for overcast skies defined and used by CIE prior to this standard.

The various sky types are generated using different values for each of the 5 sky coefficients shown in the panel above.

Quite cool !  ;-)

--
Larry Gritz





chrisbrejon@...
 

And just for the record, it looks like there is a CIE standard for sky values :

This web app generates sky luminance and radiance distributions using the updated Perez All-Weather Sky model, as defined in ISO 15469:2004(E) and CIE S 011/E:2003. You can dynamically adjust each of the Perez sky coefficients individually, choose any of the 16 CIE Standard General Skies, set your own direct and diffuse illuminance/irradiance values, or use annual hourly weather data for dynamic simulations or cumulative sky distributions. It also provides a range of different sky subdivision techniques and resolutions, including Tregenza’s 145 patch sky and Reinhart’s extensions.

The Commission Internationale de l’Éclairage (CIE) has defined a set of 15 standard sky types for modelling the radiance/luminance distribution under a wide range of weather conditions from overcast to cloudless, and with or without direct sunlight. The 16th varient corresponds to a much simpler mathematical model for overcast skies defined and used by CIE prior to this standard.

The various sky types are generated using different values for each of the 5 sky coefficients shown in the panel above.

Quite cool !  ;-)


chrisbrejon@...
 

Thanks Brecht for the answer.
We did pay a lot of attention to colorspace conversions and we did compare to several render engines.
We do have a match with renderman, guerilla and arnold. I don't think it is an implementation issue, but rather using a dataset that is not the right fit.

When I say red/purple, obvisouly I mean a blue color with too much red component. And this is where it gets tricky, right ? It can be very subjective to compare these colors.

From all the tests I have made, I never get a blue sky color (to my eyes) when I use 15000 to 27000 kelvin blackbody temperature.
And I believe it just comes from the fact that blackbody temperatures are the wrong dataset for that.

Chris


Brecht Van Lommel
 

From what I understand, high blackbody temperatures giving similar colors to a blue sky is coincidental.

Still, I think that with correct color space conversions and a neutral view transform the result should look blue rather than red/purple. And I do get blue with OSL blackbody() in Blender/Cycles. So I suspect a color space conversion issue.


On Mon, Jan 11, 2021 at 1:28 PM <chrisbrejon@...> wrote:
Hi everyone,
thanks a lot for your answers ! They are definitely helpful.

I was not speaking specifically about skylight here even if topics are definitely connected. ;-)
I have been looking at some papers myself for the past few months and there are indeed different approaches/datasets :

wiki_sky_comparison_02
Sebastien Hilaire has done a great presentation, comparing different approaches (with LUTs, without...).
So we could say that skylights are indeed a complex topic which include many factors/parameters.

In my original question, I was actually more talking about light's temperatures, like an area light.
If we look at Arnold, Guerilla or Renderman,you may find in the lights some temperature options.
If we look at the Renderman documentation :


We can read that at 15000 to 27000 kelvin temperature would be a clear blue poleward sky. Except that it looks very red/purple...
I wish there would be a mention : blackbody values are not recommended for temperatures above 5500 for example. But if there is
no general agreement/consensus on a daylight data set, that would indeed make things hard to implement. ;-)

I don't know if any of this makes sense,
Chris


chrisbrejon@...
 

Hi everyone,
thanks a lot for your answers ! They are definitely helpful.

I was not speaking specifically about skylight here even if topics are definitely connected. ;-)
I have been looking at some papers myself for the past few months and there are indeed different approaches/datasets :

wiki_sky_comparison_02
Sebastien Hilaire has done a great presentation, comparing different approaches (with LUTs, without...).
So we could say that skylights are indeed a complex topic which include many factors/parameters.

In my original question, I was actually more talking about light's temperatures, like an area light.
If we look at Arnold, Guerilla or Renderman,you may find in the lights some temperature options.
If we look at the Renderman documentation :


We can read that at 15000 to 27000 kelvin temperature would be a clear blue poleward sky. Except that it looks very red/purple...
I wish there would be a mention : blackbody values are not recommended for temperatures above 5500 for example. But if there is
no general agreement/consensus on a daylight data set, that would indeed make things hard to implement. ;-)

I don't know if any of this makes sense,
Chris


Brecht Van Lommel
 

I think there is something that needs to be improved in OSL regarding blackbody() and color spaces. However I'm not sure how you'd use blackbody() (or D65) to compute a blue sky color, so it may be unrelated to this specific question.

The renderer needs to set a rendering color space, to define the XYZ to RGB transform for blackbody(). However only fixed set of color space are supported. There is no ACEScg for example, so if a renderer uses that the colors would be off.

A solution could be to support setting an arbitrary 3x3 XYZ to RGB matrix instead. At least that matrix is what I already have available in my renderer, and I wouldn't mind implementing this.


On Sat, Jan 9, 2021 at 1:32 PM <chrisbrejon@...> wrote:
Hi everyone,

first time posting here. First of all, best wishes for 2021. ;-)
I am a lighting lead at illumination mac guff and our developers are currently implementing OSL
in our proprietary render engine, which is awesome. ;-)

I had a question about the blackbody function if that's okay with you. I have recently been explained that
for higher temperatures we might want daylight and not black body values.Think of it as being the delta between
a pure black body and the fact that in reality we have the sun + atmosphere filtering the light.
so for Displays we tend to match the daylight locus and most colour spaces are daylight whitepoints.

I found this information (shared by Kevin Wheatley) quite fascinating because we have been investigating
blackbody values for the past months and we did notice that something felt "off" for high values (like blue sky).
If you're interesting, here is an article on the topic and the definition by the CIE.

So my question would be if there is any interest to implement a daylight function into OSL ?
A bit like what you did with the blackbody_rgb function and the BB_TABLE.

As you can tell, I am no developer so I apologize for any noob question or misconception I'd have. ;-)
Regards,
Chris


Mitch Prater
 

Aha - here's the one I was thinking of: https://www2.cs.duke.edu/courses/cps124/spring08/assign/07_papers/p91-preetham.pdf
There's also a similar night sky paper: http://graphics.stanford.edu/~henrik/papers/nightsky/nightsky.pdf

A quick search also turned up this: https://www.researchgate.net/publication/265111517_REAL-TIME_DAYLIGHT_SKY_COLOR_MODELING


Larry Gritz
 

We are always interested in PRs that propose and implement new standard OSL functions that are broadly helpful to shader writers. Shy of making an "official" standard library function, we can also simply include sample shader code with the OSL distribution (this may be better for something that's useful, but that perhaps we can't agree that there is one true way to do it).

As Mitch alludes to, there are several computational models that have been published for sky color, and they are usually more complex than merely the raw daylight color temperature -- they are a complex function of position on earth, time of day and year, direction, and atmospheric conditions. These have even been implemented in OSL (though I don't know if any are published). I don't know what the debate would be like in choosing one that everybody could agree on, but if there was consensus that a particularly good one should be part of the language, or like I said as an example for us to ship even if not a language feature per se, we would be happy to receive that submission.


On Jan 9, 2021, at 10:22 AM, Mitch Prater <mprater@...> wrote:

[Edited Message Follows]

Excellent question Chris - thanks for raising it!

The short, and I believe "standard" answer to such questions, is that if OSL doesn't currently provide functionality you desire, you can implement it yourself either using OSL shader code, or by adding that functionality to the language so that it can be incorporated into the OSL repository, or just within your own rendering system implementation if you prefer to not make that public.

The long answer is that color science and its application within lighting, shading, and rendering systems is a fascinating topic and obviously one that deserves a great deal of attention. OSL is fundamentally however, a programming language only. Questions of what color is, how it's controlled, represented, processed, displayed, and finally perceived is more within the purview of the CIE, Open Color IO, and the implementers of your rendering system. OSL in its current form represents color as a 3-tuple, so its ability to process color is constrained to quantities that can be represented by that data type (and the underlying assumptions about the orthogonality of those values). But, since shading is fundamentally a process of generating color, it's absolutely valid to raise the question of how much of the definition of color should be a part of the language and how to manage and implement it. As spectral representations of light make their way out of research and into production renderers, this topic deserves more discussion.

But I digress. The ability to specify a "daylight color" as a function of a temperature value certainly sounds useful. It does bring up the question as to what the atmospheric filtering consists of, and whether you'd want the ability to control that instead. The sun's output is actually constant, so its illumination on the ground is completely a function of the atmospheric conditions and the sun's path through it, so using a temperature value might not be the most useful physically-based control. Pixar had implemented just such an atmospheric light source many years ago. I seem to recall it having been presented at Siggraph, but I can't say for sure.

mitch

--
Larry Gritz





Mitch Prater
 
Edited

Excellent question Chris - thanks for raising it!

The short, and I believe "standard" answer to such questions, is that if OSL doesn't currently provide functionality you desire, you can implement it yourself either using OSL shader code, or by adding that functionality to the language so that it can be incorporated into the OSL repository, or just within your own rendering system implementation if you prefer to not make that public.

The long answer is that color science and its application within lighting, shading, and rendering systems is a fascinating topic and obviously one that deserves a great deal of attention. OSL is fundamentally however, a programming language only. Questions of what color is, how it's controlled, represented, processed, displayed, and finally perceived is more within the purview of the CIE, Open Color IO, and the implementers of your rendering system. OSL in its current form represents color as a 3-tuple, so its ability to process color is constrained to quantities that can be represented by that data type (and the underlying assumptions about the orthogonality of those values). But, since shading is fundamentally a process of generating color, it's absolutely valid to raise the question of how much of the definition of color should be a part of the language and how to manage and implement it. As spectral representations of light make their way out of research and into production renderers, this topic deserves more discussion.

But I digress. The ability to specify a "daylight color" as a function of a temperature value certainly sounds useful. It does bring up the question as to what the atmospheric filtering consists of, and whether you'd want the ability to control that instead. The sun's output is actually constant, so its illumination on the ground is completely a function of the atmospheric conditions and the sun's path through it, so using a temperature value might not be the most useful physically-based control. Pixar had implemented just such an atmospheric light source many years ago. I seem to recall it having been presented at Siggraph, but I can't say for sure.

mitch


chrisbrejon@...
 

Hi everyone,

first time posting here. First of all, best wishes for 2021. ;-)
I am a lighting lead at illumination mac guff and our developers are currently implementing OSL
in our proprietary render engine, which is awesome. ;-)

I had a question about the blackbody function if that's okay with you. I have recently been explained that
for higher temperatures we might want daylight and not black body values.Think of it as being the delta between
a pure black body and the fact that in reality we have the sun + atmosphere filtering the light.
so for Displays we tend to match the daylight locus and most colour spaces are daylight whitepoints.

I found this information (shared by Kevin Wheatley) quite fascinating because we have been investigating
blackbody values for the past months and we did notice that something felt "off" for high values (like blue sky).
If you're interesting, here is an article on the topic and the definition by the CIE.

So my question would be if there is any interest to implement a daylight function into OSL ?
A bit like what you did with the blackbody_rgb function and the BB_TABLE.

As you can tell, I am no developer so I apologize for any noob question or misconception I'd have. ;-)
Regards,
Chris