|
Re: Typical configuration files used
Hello,
I'd honestly say it depends on the time you have and your grasp of what problems you're trying to solve.
In truth the larger hill of difficulty is from generating you're own luts and/or decomposing colorspaces into the relevant ocio transforms, since there isn't as much helpful tooling around this.
If you do go down the path of creating your own config from stratch (not merely culling the list of an existing one) I'd suggest using the API to generate your config. In my opinion there is no reason to be manually editing the YAML by hand.
On Thu, 22 Nov 2018, 5:23 pm Simon Therriault < mos...@... wrote: Hi,
During my integration of the OCIO library, I have mainly used the configuration files that can be obtained from the OCIO website, mainly nuke and Aces. I was wondering what is the typical use case by users of the library. Do people start from the Aces configuration and strip it down for what they need, do they start from scratch, do they keep the Aces configuration as is?
I'd be interested to have your input on this!
Thanks
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Typical configuration files used
Simon Therriault <mos...@...>
Hi,
During my integration of the OCIO library, I have mainly used the configuration files that can be obtained from the OCIO website, mainly nuke and Aces. I was wondering what is the typical use case by users of the library. Do people start from the Aces configuration and strip it down for what they need, do they start from scratch, do they keep the Aces configuration as is?
I'd be interested to have your input on this!
Thanks
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Troy Sobotka <troy.s...@...>
It took me a bit of time mucking to get the allocation variables set properly.
If you set your allocation variables type to lg2, the math for the lower and
upper variable is the same as it is in an AllocationTransform, which is
log2(VALUE), which if you have stops as a reference is
log2(2^STOP_ADJUSTMENT * MIDDLE_GREY). For example, for
ten stops down with a middle grey peg at 0.18 it should be log2(2^-10 * 0.18).
For uniforms, it is value as-is, and they get normalized to and from including
negatives I believe, as per the example given in the documentation.
With respect,
TJS
toggle quoted messageShow quoted text
On Fri, Nov 9, 2018 at 11:09 AM Simon Therriault <mos...@gmail.com> wrote:
Thanks for your answer Troy.
I started to play with the latest version with the revamped GPU path. I'll have to wait for the official release to integrate it though.
For now, I'll continue to see if I can get something out of the AllocationVars. From what I understand, the nuke default config is not necessarily the best to play with the GPU path. All the 1dLUT in play describes the to_reference transform. When I use them for inverse, the config as is clips the negative.
On Friday, November 9, 2018 at 1:42:14 PM UTC-5, Troy James Sobotka wrote:
There's two issues at work, both of which are important.
The first is the deeper GPU issue that the ever wise Mr. Hodoul has fixed with
the completely reworked GPU code path. That is a massive issue, and one that
is deeper than the simple allocation variables. This ends up in
potential posterization
in OCIOv1 given that the GPU transforms are collapsed into a single transform.
The allocation variables are important if you have a GPU path as well,
given that
the GPU path is a constricted set of values. As far as I have come to expect and
understand things, the allocation variables are required if _either side of the
transform has a scene referred range_. If your from_reference or to_reference
requires a transform into the scene referred domain, your allocation vars need
to be set according to the minimum and maximum values required, as per
type. If these aren't set correctly, the range you require may be
clipped off when
going to the GPU.
With respect,
TJS
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Simon Therriault <mos...@...>
Thanks for your answer Troy.
I started to play with the latest version with the revamped GPU path. I'll have to wait for the official release to integrate it though.
For now, I'll continue to see if I can get something out of the AllocationVars. From what I understand, the nuke default config is not necessarily the best to play with the GPU path. All the 1dLUT in play describes the to_reference transform. When I use them for inverse, the config as is clips the negative.
On Friday, November 9, 2018 at 1:42:14 PM UTC-5, Troy James Sobotka wrote: There's two issues at work, both of which are important.
The first is the deeper GPU issue that the ever wise Mr. Hodoul has fixed with
the completely reworked GPU code path. That is a massive issue, and one that
is deeper than the simple allocation variables. This ends up in
potential posterization
in OCIOv1 given that the GPU transforms are collapsed into a single transform.
The allocation variables are important if you have a GPU path as well,
given that
the GPU path is a constricted set of values. As far as I have come to expect and
understand things, the allocation variables are required if _either side of the
transform has a scene referred range_. If your from_reference or to_reference
requires a transform into the scene referred domain, your allocation vars need
to be set according to the minimum and maximum values required, as per
type. If these aren't set correctly, the range you require may be
clipped off when
going to the GPU.
With respect,
TJS
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Troy Sobotka <troy.s...@...>
There's two issues at work, both of which are important.
The first is the deeper GPU issue that the ever wise Mr. Hodoul has fixed with
the completely reworked GPU code path. That is a massive issue, and one that
is deeper than the simple allocation variables. This ends up in
potential posterization
in OCIOv1 given that the GPU transforms are collapsed into a single transform.
The allocation variables are important if you have a GPU path as well,
given that
the GPU path is a constricted set of values. As far as I have come to expect and
understand things, the allocation variables are required if _either side of the
transform has a scene referred range_. If your from_reference or to_reference
requires a transform into the scene referred domain, your allocation vars need
to be set according to the minimum and maximum values required, as per
type. If these aren't set correctly, the range you require may be
clipped off when
going to the GPU.
With respect,
TJS
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Simon Therriault <mos...@...>
I traced it in the getGpuLut3D and what I see is that when it applies the LogToLin, this will clamp all negative values of the Lut1d. The resulting operation is 2^-15 -> 0.0000305.
When the Lut1d is inversed (linear to SRGB uses the inverse lut1d), it finds the index in the LUT where that data is located. For me, this resulted in 0.1. So, all previous values (negative ones) aren't taken into account. Since the log to lin won't give negative values, I always have postiive data.
I'll play with the configuration file. Maybe I need to tweak something, like they did on the fix you sent me about blender.
Thanks
On Wednesday, November 7, 2018 at 12:41:07 PM UTC-5, Aaron Carlisle wrote: I didn't investigate whether this is the exact same issue but this might be related to the issue you are experiencing.
On Tue, Nov 6, 2018 at 1:11 PM Patrick Hodoul < patr...@...> wrote: Having a realistic timeline for OCIO v2 is quite challenging for now.
Patrick. On Friday, November 2, 2018 at 1:27:10 PM UTC-4, Simon Therriault wrote: Thanks for the confirmation Patrick!
Also, in latest release, 1.1, I can see the same kind of behaviour. Let's say for the Nuke-default configuration, if I go from linear to SRGB, the resulting 3d LUT doesn't have any negative values. So, if I input Marci's image, all the blacks, which are negative, will be "clamped" to a pixel value higher than 0. I don't expect bug fixes for it but just looking for a confirmation that it is expected in this version.
Also, do you have any timeline for the official 2.0 release?
Thanks again for your help! On Friday, November 2, 2018 at 12:28:46 PM UTC-4, Patrick Hodoul wrote:
Here is the github issue: #622On Friday, November 2, 2018 at 12:21:51 PM UTC-4, Patrick Hodoul wrote: Hi
Simon,
Thanks for taking the
time to use/test the master branch, and sorry for the delay to answer.
I did some
investigations, and you found a 'glitch' :-) in
the master branch (i.e. OCIO v2).
Following your use
case and using the latest commit from the master branch, the inv LUT 1D is clamping to [0, 1]. Even if we are currently revisiting all the Ops to comply with
the CLF requirements, I will still log an issue in github to keep track of the
use case (as the corresponding unit test is clearly missing).
Regards,
Patrick. On Monday, October 29, 2018 at 8:19:53 PM UTC-4, Simon Therriault wrote: Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Aaron Carlisle <carlisle...@...>
I didn't investigate whether this is the exact same issue but this might be related to the issue you are experiencing.
On Tue, Nov 6, 2018 at 1:11 PM Patrick Hodoul < patric...@...> wrote: Having a realistic timeline for OCIO v2 is quite challenging for now.
Patrick. On Friday, November 2, 2018 at 1:27:10 PM UTC-4, Simon Therriault wrote: Thanks for the confirmation Patrick!
Also, in latest release, 1.1, I can see the same kind of behaviour. Let's say for the Nuke-default configuration, if I go from linear to SRGB, the resulting 3d LUT doesn't have any negative values. So, if I input Marci's image, all the blacks, which are negative, will be "clamped" to a pixel value higher than 0. I don't expect bug fixes for it but just looking for a confirmation that it is expected in this version.
Also, do you have any timeline for the official 2.0 release?
Thanks again for your help! On Friday, November 2, 2018 at 12:28:46 PM UTC-4, Patrick Hodoul wrote:
Here is the github issue: #622On Friday, November 2, 2018 at 12:21:51 PM UTC-4, Patrick Hodoul wrote: Hi
Simon,
Thanks for taking the
time to use/test the master branch, and sorry for the delay to answer.
I did some
investigations, and you found a 'glitch' :-) in
the master branch (i.e. OCIO v2).
Following your use
case and using the latest commit from the master branch, the inv LUT 1D is clamping to [0, 1]. Even if we are currently revisiting all the Ops to comply with
the CLF requirements, I will still log an issue in github to keep track of the
use case (as the corresponding unit test is clearly missing).
Regards,
Patrick. On Monday, October 29, 2018 at 8:19:53 PM UTC-4, Simon Therriault wrote: Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Patrick Hodoul <patric...@...>
Having a realistic timeline for OCIO v2 is quite challenging for now.
Patrick.
On Friday, November 2, 2018 at 1:27:10 PM UTC-4, Simon Therriault wrote: Thanks for the confirmation Patrick!
Also, in latest release, 1.1, I can see the same kind of behaviour. Let's say for the Nuke-default configuration, if I go from linear to SRGB, the resulting 3d LUT doesn't have any negative values. So, if I input Marci's image, all the blacks, which are negative, will be "clamped" to a pixel value higher than 0. I don't expect bug fixes for it but just looking for a confirmation that it is expected in this version.
Also, do you have any timeline for the official 2.0 release?
Thanks again for your help! On Friday, November 2, 2018 at 12:28:46 PM UTC-4, Patrick Hodoul wrote:
Here is the github issue: #622On Friday, November 2, 2018 at 12:21:51 PM UTC-4, Patrick Hodoul wrote: Hi
Simon,
Thanks for taking the
time to use/test the master branch, and sorry for the delay to answer.
I did some
investigations, and you found a 'glitch' :-) in
the master branch (i.e. OCIO v2).
Following your use
case and using the latest commit from the master branch, the inv LUT 1D is clamping to [0, 1]. Even if we are currently revisiting all the Ops to comply with
the CLF requirements, I will still log an issue in github to keep track of the
use case (as the corresponding unit test is clearly missing).
Regards,
Patrick. On Monday, October 29, 2018 at 8:19:53 PM UTC-4, Simon Therriault wrote: Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Simon Therriault <mos...@...>
Thanks for the confirmation Patrick!
Also, in latest release, 1.1, I can see the same kind of behaviour. Let's say for the Nuke-default configuration, if I go from linear to SRGB, the resulting 3d LUT doesn't have any negative values. So, if I input Marci's image, all the blacks, which are negative, will be "clamped" to a pixel value higher than 0. I don't expect bug fixes for it but just looking for a confirmation that it is expected in this version.
Also, do you have any timeline for the official 2.0 release?
Thanks again for your help!
On Friday, November 2, 2018 at 12:28:46 PM UTC-4, Patrick Hodoul wrote:
Here is the github issue: #622On Friday, November 2, 2018 at 12:21:51 PM UTC-4, Patrick Hodoul wrote: Hi
Simon,
Thanks for taking the
time to use/test the master branch, and sorry for the delay to answer.
I did some
investigations, and you found a 'glitch' :-) in
the master branch (i.e. OCIO v2).
Following your use
case and using the latest commit from the master branch, the inv LUT 1D is clamping to [0, 1]. Even if we are currently revisiting all the Ops to comply with
the CLF requirements, I will still log an issue in github to keep track of the
use case (as the corresponding unit test is clearly missing).
Regards,
Patrick. On Monday, October 29, 2018 at 8:19:53 PM UTC-4, Simon Therriault wrote: Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Patrick Hodoul <patric...@...>
Here is the github issue: #622
On Friday, November 2, 2018 at 12:21:51 PM UTC-4, Patrick Hodoul wrote: Hi
Simon,
Thanks for taking the
time to use/test the master branch, and sorry for the delay to answer.
I did some
investigations, and you found a 'glitch' :-) in
the master branch (i.e. OCIO v2).
Following your use
case and using the latest commit from the master branch, the inv LUT 1D is clamping to [0, 1]. Even if we are currently revisiting all the Ops to comply with
the CLF requirements, I will still log an issue in github to keep track of the
use case (as the corresponding unit test is clearly missing).
Regards,
Patrick. On Monday, October 29, 2018 at 8:19:53 PM UTC-4, Simon Therriault wrote: Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
|
|
|
Re: AllocationVars with GPU path and 1d LUT
Patrick Hodoul <patric...@...>
Hi
Simon,
Thanks for taking the
time to use/test the master branch, and sorry for the delay to answer.
I did some
investigations, and you found a 'glitch' :-) in
the master branch (i.e. OCIO v2).
Following your use
case and using the latest commit from the master branch, the inv LUT 1D is clamping to [0, 1]. Even if we are currently revisiting all the Ops to comply with
the CLF requirements, I will still log an issue in github to keep track of the
use case (as the corresponding unit test is clearly missing).
Regards,
Patrick.
On Monday, October 29, 2018 at 8:19:53 PM UTC-4, Simon Therriault wrote: Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
|
|
|
AllocationVars with GPU path and 1d LUT
Hi,
I've been playing around an integration of OCIO using the GPU path (latest code version build 50) and things are going relatively smoothly. There's one problem that I still have though and it's when I compare conversion result to a conversion made in Nuke.
I'm using the Nuke-Default configuration and playing with Linear to SRGB conversion.
colorspaces: - !<ColorSpace> name: linear family: "" equalitygroup: "" bitdepth: 32f description: | Scene-linear, high dynamic range. Used for rendering and compositing. isdata: false allocation: lg2 allocationvars: [-15, 6]
- !<ColorSpace> name: sRGB family: "" equalitygroup: "" bitdepth: 32f description: | Standard RGB Display Space isdata: false allocation: uniform allocationvars: [-0.125, 1.125] to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
My source image is Marci_512_linear.exr that comes from the reference images. I have applied a Linear to SRGB transform in Nuke and saved an EXR 32 bits uncompressed out of it.
On my side, I have applied the same transform but using the GPU path.
In the hair region, where pixels are well over 1.0, I don't have the same result. My output has clipped to 1.0 and the one from Nuke clipped to 1.25. Samething happens for pixels below 0.0. My result has clipped to 0.0 but in Nuke's output, I can see sub 0.0 values. It looks like the allocation vars aren't taken into account or something.
My shader output looks like this and the language used is HLSL_DX11 :
Texture2D ociolut1d_0; SamplerState ociolut1d_0Sampler;
float2 ociolut1d_0_computePos(float f) { float dep = min(f, 1.0) * 65535.; float2 retVal; retVal.y = float(int(dep / 4095.)); retVal.x = dep - retVal.y * 4095.; retVal.x = (retVal.x + 0.5) / 4096.; retVal.y = (retVal.y + 0.5) / 17.; return retVal; }
float4 OCIOConvert(in float4 inPixel) { float4 outColor = inPixel; outColor.r = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.r)).r; outColor.g = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.g)).g; outColor.b = ociolut1d_0.Sample(ociolut1d_0Sampler, ociolut1d_0_computePos(outColor.b)).b;
return outColor; }
If anyone ever had that issue, I'll be happy to hear it out :)
Thanks!
|
|
|
Re: OCIO Library for Python
Madan Mohan <madanm...@...>
Thank you Deke Kincaid but i have seen this i am not able to import PyOpenColorIO as OCIO in Pycharm or any other things. If i can import those libraries i can easily do the OCIO configurations. I just need to import the library in pycharm and write a script.
On Thu, Oct 4, 2018 at 7:53 PM Deke Kincaid < dekek...@...> wrote: Here are the docs & examples:
Were you looking for something more specific as your query is a bit vague? Hi; I just want to know how to use OCIO library or Module in a python script externally i am just new to python i know this is a basic one. Can anyone help me out from this issue..
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: OCIO Library for Python
Deke Kincaid <dekek...@...>
Here are the docs & examples:
Were you looking for something more specific as your query is a bit vague?
Hi; I just want to know how to use OCIO library or Module in a python script externally i am just new to python i know this is a basic one. Can anyone help me out from this issue..
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Madan Mohan <madanm...@...>
Hi; I just want to know how to use OCIO library or Module in a python script externally i am just new to python i know this is a basic one. Can anyone help me out from this issue..
|
|
|
Re: Considering OCIO --> ASWF
David Wortley <davewo...@...>
Having CI for Windows Builds would be amazing to have!
On Wed, Sep 26, 2018 at 9:49 AM Francois Lord < flord...@...> wrote: I'm all for it. OCIO has become an essential part of the VFX world and
making sure its development will continue in a healthy fashion is
important, in my opinion.
I'm very happy to hear this.
Francois
On 2018-09-21 03:22 PM, Larry Gritz wrote:
> Hey, everybody. We're thinking about applying to turn OpenColorIO governance over to the Academy Software Foundation (ASWF), and they are very enthusiastically seeking our application. Before we get that underway, I want to make sure there's a chance here to air any reservations or objections so that we can move forward with a high degree of community consensus, and to answer any questions you may have about the process.
>
> ASWF got a lot of publicity at SIGGRAPH, so I'm going to presume you all know its significance and relevance to us and the basic value proposition. But do speak up if you want more explanation, and I'm happy to expand on it.
>
> I think there are several reasons why turning over governance to ASWF is good for this project:
>
> (1) It emphasizes that OCIO really is a work of and for the VFX community as a whole and shouldn't be thought of as an "Imageworks project", especially in light of the new infusion of contributions from Autodesk and elsewhere. Having it be underneath the foundation's umbrella should be a help to adoption and contributions, versus continuing to be thought of as belonging to one studio.
>
> (2) There are a variety of licensing, legal, and other issues that will be nice to turn over to a neutral party that likely can manage it better, and can do so with close coordination and uniformity with other projects in the ecosystem.
>
> (3) It lets us use the shared infrastructure and engineering support from LF for continuous integration, artifact archival (i.e. compiled release binaries people can directly download and install!), and release management tasks, that are being coordinated and dedicated to ASWF projects. (That's where a lot of the money from the corporate members is going.)
>
> (4) The corporate members not only fork over the $$, they also have to pledge a certain amount of engineering effort to open source. The first couple years (when there is a paucity of ASWF projects), it can go to any project that seems important in the ecosystem, but eventually it will be tightened and fulfilling the engineering obligations of the members will be expected to be dedicated as much as possible to ASWF projects. So by being an official ASWF project, OCIO is more likely to be the recipient of that engineering effort.
>
> (5) OCIO has, to be honest, had some periods when it lacked a strong and consistent leadership, design direction, and implementation contributions. It's pretty healthy right now, but being part of this organization I think is also insurance for the future, to help us with organization, resources, and coordination if and when needed or in times of crisis.
>
> If we go ahead with this, on a day-to-day basis, not much would change. The open source license we use (BSD) would remain the same. The copyrights would continue to be held by the individual authors or their companies. There might be a new CLA (or equivalent), perhaps a common one for all ASWF projects, and maintained by them rather than by Imageworks. Maybe the official canonical repo would eventually move from imageworks to the AcademySoftwareFoundation account on GitHub? But the same developers would work in the same way, the same people would have commit privileges, our process for developing and setting the design and engineering direction would remain as before, all by the same people. There's no micromanagement from above; the healthy projects run their own communities, unless they need help. There might be a more formal notion of a technical steering committee for the project, with the organization helping to facilitate the stakeholders staying in contact. An accepted project gets to elect a representative to the overall ASWF Technical Advisory Committee. I think that covers all the bases of what we'd see on the ground.
>
> I want to emphasize that we haven't made the formal application yet, the ASWF has not yet accepted the project (though since they have solicited our application, our odds are good), and also Sony Imageworks (the current owner/sponsor) has not yet formally committed to the change in governance. But before proceeding further on any of those fronts, I want to make sure this is aligned with the goals and sentiments of the OCIO stakeholders.
>
> Questions or discussion? Pros/cons as you see it?
>
> --
> Larry Gritz
> l...@... / l...@...
>
>
>
>
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: Build error on CentOS 7.5
Sachin Shrestha <noizf...@...>
Thanks Larry, I realised that too after posting this and managed to build it with 1.8. The ociotools got compiled properly too.
Thanks, Sachin
On Wed, 26 Sep 2018 at 23:09, Larry Gritz < l...@...> wrote: Yeah, I'm sorry, in OIIO master branch (the *next* release, in development), there has been an API change that OCIO has not yet caught up with. That's my fault, it's on my list to fix right away.
In the mean time, OCIO requires OIIO 1.8 (the current official stable release) or earlier, if you are building ocioconverr and the other command-line utilities. (OCIO's core library doesn't have any OIIO dependency at all.)
-- lg
Hi,
I'm using a CentOS 7.5 (3.10.0-693.2.2.el7.x86_64) docker instance to build ocio with devtoolset-6 and my build fails with the following error:
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp: In function 'int main(int, const char**)':
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:122:66: error: cannot convert 'OpenImageIO_v1_9::ImageInput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageInput>}' to 'OpenImageIO_v1_9::ImageInput*' in initialization
OIIO::ImageInput* f = OIIO::ImageInput::create(inputimage);
^
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:311:69: error: cannot convert 'OpenImageIO_v1_9::ImageOutput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageOutput>}' to 'OpenImageIO_v1_9::ImageOutput*' in initialization
OIIO::ImageOutput* f = OIIO::ImageOutput::create(outputimage);
I also get these warnings initially during the build but not sure if they eventually cause the build to error out?
/oss/imageworks/OpenColorIO/build/ext/yaml-cpp/src/ptr_stack.h:35:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
std::auto_ptr<T> t(m_data.back());
I'm following the build instructions on this page. I have already built oiio and its installed in the default system location and ocio is picking that up correctly during the build process. But I came across this post re the cyclic dependency issue between ocio and oiio and I'm wondering if I need to follow the instructions on that thread in Linux as well since I intend to build all the ocio apps?
Thanks, Sachin
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: Build error on CentOS 7.5
Yeah, I'm sorry, in OIIO master branch (the *next* release, in development), there has been an API change that OCIO has not yet caught up with. That's my fault, it's on my list to fix right away.
In the mean time, OCIO requires OIIO 1.8 (the current official stable release) or earlier, if you are building ocioconverr and the other command-line utilities. (OCIO's core library doesn't have any OIIO dependency at all.)
-- lg
Hi,
I'm using a CentOS 7.5 (3.10.0-693.2.2.el7.x86_64) docker instance to build ocio with devtoolset-6 and my build fails with the following error:
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp: In function 'int main(int, const char**)':
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:122:66: error: cannot convert 'OpenImageIO_v1_9::ImageInput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageInput>}' to 'OpenImageIO_v1_9::ImageInput*' in initialization
OIIO::ImageInput* f = OIIO::ImageInput::create(inputimage);
^
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:311:69: error: cannot convert 'OpenImageIO_v1_9::ImageOutput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageOutput>}' to 'OpenImageIO_v1_9::ImageOutput*' in initialization
OIIO::ImageOutput* f = OIIO::ImageOutput::create(outputimage);
I also get these warnings initially during the build but not sure if they eventually cause the build to error out?
/oss/imageworks/OpenColorIO/build/ext/yaml-cpp/src/ptr_stack.h:35:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
std::auto_ptr<T> t(m_data.back());
I'm following the build instructions on this page. I have already built oiio and its installed in the default system location and ocio is picking that up correctly during the build process. But I came across this post re the cyclic dependency issue between ocio and oiio and I'm wondering if I need to follow the instructions on that thread in Linux as well since I intend to build all the ocio apps?
Thanks, Sachin
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Build error on CentOS 7.5
Hi,
I'm using a CentOS 7.5 (3.10.0-693.2.2.el7.x86_64) docker instance to build ocio with devtoolset-6 and my build fails with the following error:
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp: In function 'int main(int, const char**)':
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:122:66: error: cannot convert 'OpenImageIO_v1_9::ImageInput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageInput>}' to 'OpenImageIO_v1_9::ImageInput*' in initialization
OIIO::ImageInput* f = OIIO::ImageInput::create(inputimage);
^
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:311:69: error: cannot convert 'OpenImageIO_v1_9::ImageOutput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageOutput>}' to 'OpenImageIO_v1_9::ImageOutput*' in initialization
OIIO::ImageOutput* f = OIIO::ImageOutput::create(outputimage);
I also get these warnings initially during the build but not sure if they eventually cause the build to error out?
/oss/imageworks/OpenColorIO/build/ext/yaml-cpp/src/ptr_stack.h:35:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
std::auto_ptr<T> t(m_data.back());
I'm following the build instructions on this page. I have already built oiio and its installed in the default system location and ocio is picking that up correctly during the build process. But I came across this post re the cyclic dependency issue between ocio and oiio and I'm wondering if I need to follow the instructions on that thread in Linux as well since I intend to build all the ocio apps?
Thanks, Sachin
|
|
|
Re: Considering OCIO --> ASWF
Sebastian Sylwan <syl...@...>
Thumbs firmly up from me as well.
FWIW, OCIO was one of the case studies that the VES Tech committee brought to the ASWF discussion as deep dive examples, so the ASWF structure was in a way biased to address what was identified as useful to these projects (as many of you already know).
S
On Sun, Sep 23, 2018 at 11:58 AM, Steve Agland <sag...@...> wrote:
> Thumbs up from me. Another reason I see is that in my mind the Academy's ACES config is now the de facto "reference implementation" for OCIO and it makes sense to have them living closer together.
>
Whilst I agree with the reasoning, I think it is better to be clear
that there is no hard commitment for the ACES work to be moved under
ASWF, there was discussion about this at the ACES next BoF but I got
the feeling that people thought the ASWF was emphasizing the Software
side of things for the moment and ACES covers larger concerns, and
thus was a 'not yet'.
That said the last ASWF TAC meeting did bring up discussion over none
software artefacts.
Also to add to Larry's point about who is/would be driving things, you
can find out yourself by simply participating in the public calls (I
just listen in).
Kevin
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
