Date   

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,
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:

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,

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: Testing Nuke Plugins

bsloan <bsl...@...>
 

Gah. Correction:

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,

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


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:


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.
 
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.

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.
 
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


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:

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


Re: Review: updated readme and usage example

Malcolm Humphreys <malcolmh...@...>
 

LGTM

On 15 Dec, 2010,at 06:42 AM, Jeremy Selan <jere...@...> wrote:

Commits:

1c2d95e82e

Not much to this one...

-- Jeremy


Re: Review: Bugfix for GLSL GPU

Malcolm Humphreys <malcolmh...@...>
 

LGTM

On 15 Dec, 2010,at 05:40 AM, Jeremy Selan <jere...@...> wrote:

Commits:
54b464d255

Fixed the bug where the application of MatrixOps on the GPU (for GLSL
only) had the wrong multiplication order.

-- Jeremy


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...@...>
 


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.
 
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.

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.
 
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,

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:

(excuse the typos in the actual commit msg)
now fixed with (git commit --amend)

https://github.com/malcolmhumphreys/OpenColorIO/commit/c95536a609a6b72a612a505a9702abb4d4ac5b3f


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


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
remove '#include <boost/shared_ptr.hpp>' from OpenColorTypes.h

https://github.com/malcolmhumphreys/OpenColorIO/commit/0077676cd4e44b03df3e0931d594f350fba3fef9

We don't have the boost headers on our linux image so this was failing to
build the nuke plugins.

.malcolm


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


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


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

1901 - 1920 of 2209