|
Review: Add config.sanityCheck
Jeremy Selan <jeremy...@...>
This will prevent the issues Blake encountered from happening again.
http://groups.google.com/group/ocio-dev/browse_thread/thread/c073e0f4fde995f7 This also addresses an outstanding issue: https://github.com/imageworks/OpenColorIO/issues#issue/17 * Configs get a 'sanityCheck' call, which will validate the configuration and throw an exception if any errors are detected. An example of an error condition would be a role reference to a colorspace that does not exist. Repeated calls to sanityCheck are cached (and fast). * Nuke plugins call sanityCheck() before the getProcessor() call. * getColorSpace call is now not sensitive to case differences. Aka, linear == LINEAR. * The default role is only returned as the colorspace of 'last resort' if strict_parsing is explicitly disabled. This will prevent colorspace errors to silently roll by, unless requested. Commits: 2ae25fc437 993773f9ad 3607e94d29 -- Jeremy
|
|
|
|
Re: Testing Nuke Plugins
Jeremy Selan <jeremy...@...>
An updated nuke-default profile has been posted that should resolve
all your issues: http://sites.google.com/site/opencolorio/downloads Sorry for the trouble! (I'll be submitting a patch later today to avoid the issue in the future.) -- Jeremy
|
|
|
|
Re: Testing Nuke Plugins
Jeremy Selan <jeremy...@...>
Blake,
toggle quoted messageShow quoted text
Thanks for the testing! * Glad to hear OCIOFileTransform is working. My goal is to support (at a minimum) all of Nuke's lut formats in the near future. * We're lucky that the nuke cineon transform happens to match Log2Lin. The nuke-default OCIO profile is desogned to match all the lut transforms used in the read-write nodes. (see src/testbed/nuke_to_ocio.py for how we generated the nuke-default OCIO profile). Nuke's log2lin node does an analytical transform based on its configurable parameters, so it's only a fortunate circumstance they match by default. * OCIODisplay has it's default display transform set to 'None' by default in the nuke-default profile. If you switch this to srgb you'll see the node is working. (This is also why switching input colorspace has no effect. If you select 'no processing', no matter what the input is no work will be done). * OCIOLogConvert doesn't work because the config.ocio file has a typo in it. You can hand edit it to fix the issue. At the top of the config is the compositing_log space, which is set to "cineon". But down below the colorspace is listed as "Cineon". (Note the case difference). If you fix the role's capitalization everything will work. What's happening is that the 'cineon' (lower case) role is not found, so it's relying on the default role, "data". By design, any conversion to or from a 'data' space is a no-op, so no processing occurs. This 'silent error' is a critical mistake; I'll get in the appropriate library fixes ASAP making sure this doesn't bite any other people. I'll also update the Nuke profile today to fix the errors as well. Thanks! -- Jeremy
On Mon, Dec 20, 2010 at 2:04 PM, bsloan <bsl...@...> wrote:
Gah. Correction:
|
|
|
|
Re: Testing Nuke Plugins
bsloan <bsl...@...>
Gah. Correction:
toggle quoted messageShow quoted text
The OCIODisplay node seems to ignore the 'input colorspace' knob. Display transform and exposure work as expected. As for the LogConvert node, switching the operation from loglin to linlog seems not to change anything. Thanks again, -blake
On Dec 20, 1:42 pm, bsloan <bsl...@...> wrote:
Hi all,
|
|
|
|
Testing Nuke Plugins
bsloan <bsl...@...>
Hi all,
I've tested the OCIO 0.7.3 Nuke suite in Nuke 6.1v3 and have noticed some possible bugs (or user errors ). First of all, I downloaded the configs for 0.7 and pointed my OCIO env var to the nuke-default/configs.ocio. Then I start Nuke and create an instance of each of the four plugins: Display File_Transform LogConvert ColorSpace OCIOFile_Transform worked well with the .csp I fed it (Bravo) OCIOColorspace did the right thing with my cineon image (identical result to Nuke's vanilla LogLin (Yippee!)) The other two, OCIODisplay and OCIOLogConvert seem to have no effect (regardless of the values I set in the controls). Could I be doing something wrong? BTW, thanks Jeremy et al for all the hard work. -blake
|
|
|
|
Re: Adding multiple bit depths to one <!ColorSpace>
Malcolm Humphreys <malcolmh...@...>
Hi did you guys have any more thoughts on this? Jeremy do you see this fitting in somehow with contexts? .malcolm
On 14 Dec, 2010,at 01:35 PM, Malcolm Humphreys <malcol...@...> wrote:
|
|
|
|
0.7.3 Released
Jeremy Selan <jeremy...@...>
Version 0.7.3 (Dec 16 2010):
* Added example applications: ociodisplay, ocioconvert * Makefile: Add boost header dependency * Makefile: Nuke plugins are now version specific * Fixed bug in GLSL MatrixOp -- Jeremy
|
|
|
|
Re: Review: Added example image viewer
Malcolm Humphreys <malcolmh...@...>
LGTM
On 15 Dec, 2010,at 06:46 AM, Jeremy Selan <jere...@...> wrote:
|
|
|
|
Re: Review: updated readme and usage example
Malcolm Humphreys <malcolmh...@...>
LGTM
On 15 Dec, 2010,at 06:42 AM, Jeremy Selan <jere...@...> wrote:
|
|
|
|
Re: Review: Bugfix for GLSL GPU
Malcolm Humphreys <malcolmh...@...>
LGTM
On 15 Dec, 2010,at 05:40 AM, Jeremy Selan <jere...@...> wrote:
|
|
|
|
Review: Added example image viewer
Jeremy Selan <jeremy...@...>
I've added a working GLSL image viewer example.
It relies on OpenImageIO to load an arbitrary image, and then will display it using OpenColorIO. It's pretty awesome to see how little code in practice is needed to implement a full-fledged monitor interface! (Including fstop exposure controls, channel swizzling, etc). For those interested in adding OCIO natively to existing viewers, this is a great place to start. Commits: 18ac496924e06 899b272d710ea Caveot : this doesn't yet work with the CMake makefile, I hope to get that added soon. -- Jeremy
|
|
|
|
Review: updated readme and usage example
Jeremy Selan <jeremy...@...>
Commits:
1c2d95e82e Not much to this one... -- Jeremy
|
|
|
|
Review: Bugfix for GLSL GPU
Jeremy Selan <jeremy...@...>
Commits:
54b464d255 Fixed the bug where the application of MatrixOps on the GPU (for GLSL only) had the wrong multiplication order. -- Jeremy
|
|
|
|
Re: Adding multiple bit depths to one <!ColorSpace>
Malcolm Humphreys <malcolmh...@...>
Yeah I can see 'family' would be really useful for grouping colorspaces based on purpose which could be as abstract as the profile builder would like. In the examples I couldn't see a case where family wasn't being used for bit-depth, but I agree it should stay. I agree if a bitdepth change significantly changes the transform required, this would suggest a different !<ColorSpace>. For differences in bitdepth, I guess the usual case will be buffer A at a certain depth and buffer B at a certain depth, give me the transform from color space A -> B. I was thinking something along the lines of: ConstProcessorRcPtr processor = config->getProcessor( OCIO::ROLE_COMPOSITING_LOG, OCIO::ROLE_SCENE_LINEAR, OCIO::BIT_DEPTH_UINT10, OCIO::BIT_DEPTH_F16); This would give you back the correct 10ui log -> f16 linear, without needing to mess around with colorspace names. This would likely end up looking a bit different with the 'context' ideas Jeremy and I chatted about.
Could you see a colorspace existing in two families? maybe we could have ',' separated tags which would allow for some powerful grouping of colorspace, I'm guessing families are mostly used for UI purposes, ie give me list of all 'video' color spaces. These would be similar to 'tag clouds' www people use to have items in multiple categories / groups. eg. - !<ColorSpace> name: vdhd family: video, hd ... - !<ColorSpace> name: vdntsc family: video, ntsc ... Maybe that's just a little bit two much over-engineering, for simple grouping. .malcolm
|
|
|
|
Re: Adding multiple bit depths to one <!ColorSpace>
Joseph Slomka <jsl...@...>
Malcolm,
toggle quoted messageShow quoted text
I like it. However I'd like to keep the option for a family designation. For simple colorspaces I see this as great way to simplify things. The family designation is still useful for instances like in IIF:ACES where the 10 and 16 bit ADX transformations are significantly different. Under the hood the colorspace could define the family implicitly from the name. The SPI examples use the family designation in a very simple way. I could see a reason to place all video space transforms under a single family, for example. This could results in a family with 2 colorspaces that are named differently with the same bit depth. -Joseph
-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys Sent: Monday, December 13, 2010 4:27 AM To: ocio...@... Subject: [ocio-dev] Adding multiple bit depths to one <!ColorSpace> After playing around with ocio profiles a bit more, I think it would be and idea to have multiple bitdepths defined in one <!ColorSpace> definition. Below is the vd and nc family colorspaces from the spi-vfx profile. This kind of replaces the family concept, as it seems in all the spi examples that families and names are the way to group color spaces of similar purpose but of different bit-depths. I'm thinking it feels a bit nicer for a host app to request a named colorspace at a default depth, or request it at a specific depth. I can see that we could get a list of color spaces and do this in a host app but this seems like it should be done by ocio. ie. the displays would look more like this: displays: - !<Display> {device: sRGB, name: Film, colorspace: srgb, bitdepth: 8ui} - !<Display> {device: sRGB, name: Log, colorspace: lg, bitdepth: 10ui} - !<Display> {device: DCIP3, name: Film, colorspace: p3dci, bitdepth: 16ui} Is there a case for two colorspaces in the same family to have the same bitdepth? I would think that would be confusing. eg. this would make the spi-vfx profile have 11 colorspaces rather than 26, this also helped me spot some possible typos. --snip-- - !<ColorSpace> name: ln isdata: false gpuallocation: lg2 gpumin: -15 gpumax: 6 bitdepth: 32f bitdepths: 32f: !<ColorSpaceDetail> 16f: !<ColorSpaceDetail> 16ui: !<ColorSpaceDetail> gpumax: 0 # typo in the vfx profile? - !<ColorSpace> name: lg isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 10ui bitdepths: 16ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: lg16.spi1d, interpolation: nearest} 10ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest} 8ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest} 32f: !<ColorSpaceDetail> gpumin: -0.25 gpumax: 1.5 to_reference: !<FileTransform> {src: lgf.spi1d, interpolation: linear} - !<ColorSpace> name: gn isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 16ui bitdepths: 16ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest} 10ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest} 8ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest} 32f: !<ColorSpaceDetail> gpumin: -0.25 gpumax: 1.5 to_reference: !<FileTransform> {src: gnf.spi1d, interpolation: linear} - !<ColorSpace> name: vd isdata: false # can override these in each bitdepth if needed gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 8ui bitdepths: 16ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse} - !<FileTransform> {src: vd16.spi1d, interpolation: nearest} 8ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse} - !<FileTransform> {src: vd16.spi1d, interpolation: nearest} 10ui: to_reference: !<GroupTransform> children: - !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse} - !<FileTransform> {src: vd16.spi1d, interpolation: nearest} 32f: to_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: vd, src-depth: 16, dst: ln, dst-depth: 32f} - !<ColorSpace> name: hd isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 10ui bitdepths: 10ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: hdOffset.spimtx, interpolation: nearest, direction: inverse} - !<ColorSpaceTransform> {src: vd, src-depth: 32f, dst: ln, dst-depth: 32f} - !<ColorSpace> name: dt isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 8ui bitdepths: 8ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: diffuseTextureMultiplier.spimtx, interpolation: nearest} - !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln, dst-depth: 32f} 16ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: diffuseTextureMultiplier.spimtx, interpolation: nearest} - !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln, dst-depth: 32f} - !<ColorSpace> name: cp isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 32f bitdepths: 32f: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: cpf.spi1d, interpolation: linear} - !<ColorSpace> name: nc isdata: true gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepths: 8ui: <!ColorSpaceDetail> 10ui: <!ColorSpaceDetail> 16ui: <!ColorSpaceDetail> isdata: false # vfx profile typo? 32f: <!ColorSpaceDetail> - !<ColorSpace> name: srgb isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 8ui bitdepths: 8ui: !<ColorSpaceDetail> from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg, dst-depth: 32f} - !<FileTransform> {src: spi_ocio_srgb_test.spi3d, interpolation: linear} - !<ColorSpace> name: p3dci isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 16ui bitdepths: 16ui: !<ColorSpaceDetail> from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg, dst-depth: 10ui} - !<FileTransform> {src: colorworks_filmlg_to_p3.3dl, interpolation: linear} - !<ColorSpace> name: xyz isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 16ui bitdepths: 16ui: !<ColorSpaceDetail> from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: lnf, dst: p3dci8} - !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1]} - !<FileTransform> {src: p3_to_xyz16.spimtx, interpolation: unknown} - !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1], direction: inverse} --snip-- .malcolm
|
|
|
|
Re: Review: added TestForDDImageVersion.cxx to support multiple versions of nuke
Jeremy Selan <jeremy...@...>
Looks good to me, thanks!
-- Jeremy On Mon, Dec 13, 2010 at 1:21 AM, Malcolm Humphreys <malcolmh...@...> wrote: On 13/12/10 20:05, Malcolm Humphreys wrote:now fixed with (git commit --amend)
|
|
|
|
Re: Review: Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt
Jeremy Selan <jeremy...@...>
Looks good to me.
On Sun, Dec 12, 2010 at 5:43 PM, Malcolm Humphreys <malcolmh...@...> wrote: Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt, this is temp till we
|
|
|
|
Adding multiple bit depths to one <!ColorSpace>
Malcolm Humphreys <malcolmh...@...>
After playing around with ocio profiles a bit more, I think it would be and idea to have multiple bitdepths defined in one <!ColorSpace> definition.
Below is the vd and nc family colorspaces from the spi-vfx profile. This kind of replaces the family concept, as it seems in all the spi examples that families and names are the way to group color spaces of similar purpose but of different bit-depths. I'm thinking it feels a bit nicer for a host app to request a named colorspace at a default depth, or request it at a specific depth. I can see that we could get a list of color spaces and do this in a host app but this seems like it should be done by ocio. ie. the displays would look more like this: displays: - !<Display> {device: sRGB, name: Film, colorspace: srgb, bitdepth: 8ui} - !<Display> {device: sRGB, name: Log, colorspace: lg, bitdepth: 10ui} - !<Display> {device: DCIP3, name: Film, colorspace: p3dci, bitdepth: 16ui} Is there a case for two colorspaces in the same family to have the same bitdepth? I would think that would be confusing. eg. this would make the spi-vfx profile have 11 colorspaces rather than 26, this also helped me spot some possible typos. --snip-- - !<ColorSpace> name: ln isdata: false gpuallocation: lg2 gpumin: -15 gpumax: 6 bitdepth: 32f bitdepths: 32f: !<ColorSpaceDetail> 16f: !<ColorSpaceDetail> 16ui: !<ColorSpaceDetail> gpumax: 0 # typo in the vfx profile? - !<ColorSpace> name: lg isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 10ui bitdepths: 16ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: lg16.spi1d, interpolation: nearest} 10ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest} 8ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest} 32f: !<ColorSpaceDetail> gpumin: -0.25 gpumax: 1.5 to_reference: !<FileTransform> {src: lgf.spi1d, interpolation: linear} - !<ColorSpace> name: gn isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 16ui bitdepths: 16ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest} 10ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest} 8ui: !<ColorSpaceDetail> to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest} 32f: !<ColorSpaceDetail> gpumin: -0.25 gpumax: 1.5 to_reference: !<FileTransform> {src: gnf.spi1d, interpolation: linear} - !<ColorSpace> name: vd isdata: false # can override these in each bitdepth if needed gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 8ui bitdepths: 16ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse} - !<FileTransform> {src: vd16.spi1d, interpolation: nearest} 8ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse} - !<FileTransform> {src: vd16.spi1d, interpolation: nearest} 10ui: to_reference: !<GroupTransform> children: - !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse} - !<FileTransform> {src: vd16.spi1d, interpolation: nearest} 32f: to_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: vd, src-depth: 16, dst: ln, dst-depth: 32f} - !<ColorSpace> name: hd isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 10ui bitdepths: 10ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: hdOffset.spimtx, interpolation: nearest, direction: inverse} - !<ColorSpaceTransform> {src: vd, src-depth: 32f, dst: ln, dst-depth: 32f} - !<ColorSpace> name: dt isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 8ui bitdepths: 8ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: diffuseTextureMultiplier.spimtx, interpolation: nearest} - !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln, dst-depth: 32f} 16ui: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: diffuseTextureMultiplier.spimtx, interpolation: nearest} - !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln, dst-depth: 32f} - !<ColorSpace> name: cp isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 32f bitdepths: 32f: !<ColorSpaceDetail> to_reference: !<GroupTransform> children: - !<FileTransform> {src: cpf.spi1d, interpolation: linear} - !<ColorSpace> name: nc isdata: true gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepths: 8ui: <!ColorSpaceDetail> 10ui: <!ColorSpaceDetail> 16ui: <!ColorSpaceDetail> isdata: false # vfx profile typo? 32f: <!ColorSpaceDetail> - !<ColorSpace> name: srgb isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 8ui bitdepths: 8ui: !<ColorSpaceDetail> from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg, dst-depth: 32f} - !<FileTransform> {src: spi_ocio_srgb_test.spi3d, interpolation: linear} - !<ColorSpace> name: p3dci isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 16ui bitdepths: 16ui: !<ColorSpaceDetail> from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg, dst-depth: 10ui} - !<FileTransform> {src: colorworks_filmlg_to_p3.3dl, interpolation: linear} - !<ColorSpace> name: xyz isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 bitdepth: 16ui bitdepths: 16ui: !<ColorSpaceDetail> from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: lnf, dst: p3dci8} - !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1]} - !<FileTransform> {src: p3_to_xyz16.spimtx, interpolation: unknown} - !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1], direction: inverse} --snip-- .malcolm
|
|
|
|
Re: Review: added TestForDDImageVersion.cxx to support multiple versions of nuke
Malcolm Humphreys <malcolmh...@...>
On 13/12/10 20:05, Malcolm Humphreys wrote:
(excuse the typos in the actual commit msg)now fixed with (git commit --amend) https://github.com/malcolmhumphreys/OpenColorIO/commit/c95536a609a6b72a612a505a9702abb4d4ac5b3f
|
|
|
|
Review: added TestForDDImageVersion.cxx to support multiple versions of nuke
Malcolm Humphreys <malcolmh...@...>
(excuse the typos in the actual commit msg)
Added TestForDDImageVersion.cxx to FindNuke.cmake so that we can workout which version of nuke we are building against. This now gets appended to the '$CMAKE_INSTALL_PREFIX/lib/nuke${Nuke_DDImageVersion}'. This makes it easier to build and run against multiple versions of nuke. Added init.py and menu.py so that the ocio nuke plugins can be setup with the NUKE_PATH searchpath, to make it easier to test and integrate into our toolchains. Updated the INSTALL file to reflect these changes. https://github.com/malcolmhumphreys/OpenColorIO/commit/8d45b1dd71b845cc3b685263f365f25358ad8c68 .malcolm
|
|
|