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 :
ACEScg.jpg
And from the blender Color management side this is how
People who tried to work in ACES in blender does it :
ACES_srgb.jpg

And for people saying ACES doesn't improve realism in render :
https://acescolorspace.com/
ACES_Realism.jpg
It really deserve the effort to implement it !

EDIT ===>>

This are Vray and Redshift implementation of ACES

Redshift
Redshift_ACES.jpg

Vray
Vray_ACES.jpg

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 :
Aces_pdf.jpg

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.