Page 4 of 6
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Tue Oct 19, 2021 6:55 pm
by Dade
Sharlybg wrote: ↑Tue Oct 19, 2021 4:57 pm
What is the primary color space internally use by the linear fp32
It is (linear) FP32.
Sharlybg wrote: ↑Tue Oct 19, 2021 4:57 pm
Or now we support : ACEScg (ACES AP1 primaries) ?
Yes, anything supported by OpenColorIO v2.0 can be used as input and output.
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Wed Oct 20, 2021 10:27 am
by Sharlybg
So for the implementation in Blender what is reaquired ?
I know from the texture side we need additional parameter
to work in Acescg :
And from the blender Color management side this is how
People who tried to work in ACES in blender does it :
And for people saying ACES doesn't improve realism in render :
https://acescolorspace.com/
It really deserve the effort to implement it !
EDIT ===>>
This are Vray and Redshift implementation of ACES
Redshift
Vray
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Wed Oct 20, 2021 11:03 am
by Sharlybg
And in 4 min how it is done in Octane :
https://youtu.be/4t3qHtwyWcs
Interesting thought from the ACES pdf :
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Wed Oct 20, 2021 3:19 pm
by Sharlybg
This page make simple to understand and also give example of implementation in
MAYA / Houdini / Fusion etc
https://www.toadstorm.com/blog/?p=694
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Sat Oct 23, 2021 2:55 pm
by Sharlybg
It is (linear) FP32.
Yes but in wich color gamut srgb linear or Acescg linear wich is wider ?
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Sat Oct 23, 2021 4:32 pm
by Dade
Sharlybg wrote: ↑Sat Oct 23, 2021 2:55 pm
It is (linear) FP32.
Yes but in wich color gamut srgb linear or Acescg linear wich is wider ?
There is only one type of linear FP32: it is meaning depends how you transform the input colors and output colors (so LuxCore internal color representation can be sRGB or ACEScg).
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Sat Oct 23, 2021 7:48 pm
by Sharlybg
Thanks Dade for this clear answer.
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Sat Oct 23, 2021 9:05 pm
by B.Y.O.B.
Dade wrote: ↑Sat Oct 23, 2021 4:32 pm
There is only one type of linear FP32: it is meaning depends how you transform the input colors and output colors (so LuxCore internal color representation can be sRGB or ACEScg).
But what about functions in LuxCore that for example compute the luminosity of a color? Don't they all assume linear sRGB?
Like here:
https://github.com/LuxCoreRender/LuxCor ... lor.h#L285
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Sun Oct 24, 2021 3:33 am
by SiddhantRane
Dade wrote: ↑Sat Oct 23, 2021 4:32 pm
There is only one type of linear FP32: it is meaning depends how you transform the input colors and output colors (so LuxCore internal color representation can be sRGB or ACEScg).
Here's what I'm confused about: When you say 'Linear FP32', you're only talking about the gamma and bit depth of Nop which I'm assuming is the rendering (working) color space of LuxCore, like sRGB Linear FP32 in Blender Cycles.
What I don't understand is this: because you say Nop can be represented as ACEScg or sRGB, then what color primaries does Nop use? Is it using ACES AP0/AP1 primaries or have you developed a new wide golor gamut for LuxCore?
Also by "represented", do you mean Nop can be transformed to ACEScg using OCIO RRT/ODT; or can LuxCore have the ability to render in the full ACEScg gamut via Nop?
Re: Color spaces support (aka OpenColorIO v2.0)
Posted: Sun Oct 24, 2021 10:01 am
by Dade
B.Y.O.B. wrote: ↑Sat Oct 23, 2021 9:05 pm
Dade wrote: ↑Sat Oct 23, 2021 4:32 pm
There is only one type of linear FP32: it is meaning depends how you transform the input colors and output colors (so LuxCore internal color representation can be sRGB or ACEScg).
But what about functions in LuxCore that for example compute the luminosity of a color? Don't they all assume linear sRGB?
Like here:
https://github.com/LuxCoreRender/LuxCor ... lor.h#L285
Not really, color luminance is used only for some stuff like sampling more the most "important" light sources or Metropolis spending more samples on most "important" pixels, etc. It has no effect at all on the end result of the rendering. You can replace:
Code: Select all
float Y() const {
return 0.212671f * c[0] + 0.715160f * c[1] + 0.072169f * c[2];
}
with:
Code: Select all
float Y() const {
return return (c[0] + c[1] + c[2]) * (1.f / 3.f); // aka Filter()
}
and get the same rendering at the end. The noise distribution may be slightly different but the end result is exactly the same.