Date   

Building problems on osx 10.11

Ben De Luca <bde...@...>
 

Hi,
I am building on osx 10.11 and receive the following error at
compile time building 1.0.9 from here
https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz

In file included from
/tmp/extract/tmpKUwr7l/OpenColorIO-1.0.9/src/core/AllocationOp.cpp:29:
In file included from
/tmp/extract/tmpKUwr7l/OpenColorIO-1.0.9/src/core/AllocationOp.h:33:
In file included from
/tmp/extract/tmpKUwr7l/OpenColorIO-1.0.9/export/OpenColorIO/OpenColorIO.h:38:
/var/folders/h8/9ghw01cx65ldhgwpk9scbp480000gn/T/tmpBN8ZlT/export/OpenColorABI.h:59:10:
fatal error: 'tr1/memory' file not found
#include <tr1/memory>

Before I look further has any one come across it? I couldn't find
any references on the list. I imagine the home brew folks have hit it
and will look there.


Re: OpenColorIO stewardship

nick....@...
 

Hi,

On Tuesday, March 8, 2016 at 4:33:21 PM UTC-8, Mark Boorer wrote:

The current re-factoring work is regrettably still not finished, as my other day-to-day production tasks at DNeg have become more pressing of late. I have some time for dev work booked out in the coming weeks though, so hopefully I will have something more to show soon. My greater goal is to have everything out, feedback gathered, and tested before the SIGGRAPH 2016 deadline in order to make the changes available in the VFX platform for 2017.

We are in the process of publishing the draft VFX Reference Platform for CY2017 so please can you give an update on when you expect this next release to drop and, if it's in time for vendors to incorporate into their 2017 releases, what version number it's likely to be released under so we can include it.

Thanks,

Nick

 


Re: proper FileTransform usage

Paul Miller <pa...@...>
 

On 3/8/2016 7:01 PM, Mark Boorer wrote:
Hi Paul,

When you say your FileTransform results differ from Nuke's, is this from
using a Vectorfield node, or an OCIO FileTransform node, or perhaps an
OCIO Display node entirely? Also what format of LUT are you using?

(I'd also recommend using INTERP_TETRAHEDRAL where possible)
Actually, what we found was creating an actual OCIO config out of the LUT file transform produced the proper results. Not entirely sure what the actual difference is under the cover.


Re: ocio Aces 1.0 config

Haarm-Pieter Duiker <li...@...>
 

Hello Gene,

The ACES 1.0.1 OCIO config can be found here:

General information about ACES can be found here:

Regards,
HP Duiker



On Thursday, March 17, 2016, G C <gcdi...@...> wrote:
Dear OCIO

I am new to this and i am struggling to get my self around to find config for After Effects and FUSION using the `Ocio plugin need config where can i download the complete set or configurations smilier to the Nuke ocio integration IIF aces module and the rest 

How do i build my own config to for example cover an srgb to Aces cg to make clean transforms from sRGB to ACEs cg 

thank you in advance for helping me out and looking into this 

Best wishes

Gene 

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


ocio Aces 1.0 config

G C <gcdi...@...>
 

Dear OCIO

I am new to this and i am struggling to get my self around to find config for After Effects and FUSION using the `Ocio plugin need config where can i download the complete set or configurations smilier to the Nuke ocio integration IIF aces module and the rest 

How do i build my own config to for example cover an srgb to Aces cg to make clean transforms from sRGB to ACEs cg 

thank you in advance for helping me out and looking into this 

Best wishes

Gene 


Re: OpenColorIO stewardship

Andy Jones <andy....@...>
 

Thanks for the update, guys. Much appreciated, as well as all of the ongoing efforts with both ACES and OCIO!

If it seems like it would make sense in the long term to distribute ACES configs separately from the OCIO examples, I wouldn't have any problem with that.  I can see where it might make it easier to juggle ACES updates and OCIO library updates.  But it does seem like our best bet for getting ACES 1.0 into this year's releases might be to avoid rocking the boat too much and stick with the plan you guys outlined.


Re: proper FileTransform usage

Mark Boorer <mark...@...>
 

Hi Paul,

When you say your FileTransform results differ from Nuke's, is this from using a Vectorfield node, or an OCIO FileTransform node, or perhaps an OCIO Display node entirely? Also what format of LUT are you using?

(I'd also recommend using INTERP_TETRAHEDRAL where possible)

Cheers,
Mark

On Tue, Mar 8, 2016 at 5:52 PM, Paul Miller <pa...@...> wrote:
I need advice on the correct way to use a LUT file transform in an OCIO processor. My results when using a FileTransform look different than in Nuke, with whites appearing more subdued using the test LUT I have. Am I doing this right?

My normal OCIO processor looks like this:

  DisplayTransformRcPtr transform = DisplayTransform::Create();
  transform->setInputColorSpaceName(colorSpaceName);
  transform->setDisplay(displayName);
  transform->setView(lookName);
  transform->setLinearCC(gainTransform);
  transform->setChannelView(swizzle);
  transform->setDisplayCC(exposureTransform);

  processor = config->getProcessor(transform);

However, I also allow bringing in an external LUT file, and I use it like this in lieu of the DisplayTransform:

  FileTransformRcPtr fileTransform = FileTransform::Create();
  fileTransform->setSrc(path);
  fileTransform->setInterpolation(OCIO::INTERP_LINEAR);

  GroupTransformRcPtr group = GroupTransform::Create();
  group->push_back(gainTransform);
  group->push_back(fileTransform);
  group->push_back(exposureTransform);

  processor = config->getProcessor(group);

I'm using the same display shader for both.

--
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: OpenColorIO stewardship

Mark Boorer <mark...@...>
 

Hi All,

Apologies Mark, I missed your previous request for an update, it's been a bit busier this year than I expected!

Andy, et al; As Haarm-Pieter put it, I am currently awaiting his final changes before I can merge his ACES 1.0.1 config into the repo. At the moment, the OpenColorIO-Configs repository is not versioned in lock step with the library, so I see no reason why this cannot go out immediately. Initially I'd had some reservations about the sheer size of the commits, and that the addition of other, non OpenColorIO related data would have an adverse effect on the usability / maintainability of the repository, but people seem keen to use this repo as a central ACES reference implementation, rather than just a place for OCIO configs, so I plan on putting it through in one go.

The current re-factoring work is regrettably still not finished, as my other day-to-day production tasks at DNeg have become more pressing of late. I have some time for dev work booked out in the coming weeks though, so hopefully I will have something more to show soon. My greater goal is to have everything out, feedback gathered, and tested before the SIGGRAPH 2016 deadline in order to make the changes available in the VFX platform for 2017.

In short, the ACES 1.0.1 configs will go out as soon as the final cleanup is done, and the library changes will be out for feedback hopefully not long after.

Cheers,
Mark

On Tue, Mar 8, 2016 at 8:26 PM, Haarm-Pieter Duiker <li...@...> wrote:
Hey Andy,

Here's an update from my side on the issue. After a bit of delay, Mark and the OCIO leadership have agreed to accept the pull request to integrate the ACES 1.0.1 config into the main OCIO configs repo. They have asked me to combine the commit history into a single commit before doing so, so the commit history for the general repo doesn't suddenly have a huge list of commits that won't mean much to most people. It's on my to do list. I'm also on a project that is barreling head-long towards a deadline this week, so that's taking precedence right now. I'm hoping to have the commits squashed this weekend so the pull request can be accepted.

Mark, correct me if that's not in line with your understanding.

HP




On Tue, Mar 8, 2016 at 2:37 PM, Andy Jones <andy....@...> wrote:
Bumping this, specifically WRT ACES 1.0 in the configs.  It would be great to get some kind of (hopefully short) timeline on that.  The configs in Nuke seem to be some ancient checkout of the examples, and we'd like to pressure them to bring them up to date for their next release.  We'd really like to see ACES 1.0 included in that update.  It seems like there's a chance Nuke might end up pulling from HP's github if the update doesn't happen soon, but I would imagine it's in everyone's best interest to keep everything pointed at the original repo.

If there's a big refactor of the configs going on for the major release mentioned above, perhaps it's worth making a branch and merging HP's ACES 1.0 config into master until that's ready?  Even if the configs are likely to need to change with the updates, it seems like places may need a legacy ACES 1.0 config for a while, until the future library makes its way into the apps.

--
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: OpenColorIO stewardship

Haarm-Pieter Duiker <li...@...>
 

Hey Andy,

Here's an update from my side on the issue. After a bit of delay, Mark and the OCIO leadership have agreed to accept the pull request to integrate the ACES 1.0.1 config into the main OCIO configs repo. They have asked me to combine the commit history into a single commit before doing so, so the commit history for the general repo doesn't suddenly have a huge list of commits that won't mean much to most people. It's on my to do list. I'm also on a project that is barreling head-long towards a deadline this week, so that's taking precedence right now. I'm hoping to have the commits squashed this weekend so the pull request can be accepted.

Mark, correct me if that's not in line with your understanding.

HP




On Tue, Mar 8, 2016 at 2:37 PM, Andy Jones <andy....@...> wrote:
Bumping this, specifically WRT ACES 1.0 in the configs.  It would be great to get some kind of (hopefully short) timeline on that.  The configs in Nuke seem to be some ancient checkout of the examples, and we'd like to pressure them to bring them up to date for their next release.  We'd really like to see ACES 1.0 included in that update.  It seems like there's a chance Nuke might end up pulling from HP's github if the update doesn't happen soon, but I would imagine it's in everyone's best interest to keep everything pointed at the original repo.

If there's a big refactor of the configs going on for the major release mentioned above, perhaps it's worth making a branch and merging HP's ACES 1.0 config into master until that's ready?  Even if the configs are likely to need to change with the updates, it seems like places may need a legacy ACES 1.0 config for a while, until the future library makes its way into the apps.

--
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: OpenColorIO stewardship

Andy Jones <andy....@...>
 

Bumping this, specifically WRT ACES 1.0 in the configs.  It would be great to get some kind of (hopefully short) timeline on that.  The configs in Nuke seem to be some ancient checkout of the examples, and we'd like to pressure them to bring them up to date for their next release.  We'd really like to see ACES 1.0 included in that update.  It seems like there's a chance Nuke might end up pulling from HP's github if the update doesn't happen soon, but I would imagine it's in everyone's best interest to keep everything pointed at the original repo.

If there's a big refactor of the configs going on for the major release mentioned above, perhaps it's worth making a branch and merging HP's ACES 1.0 config into master until that's ready?  Even if the configs are likely to need to change with the updates, it seems like places may need a legacy ACES 1.0 config for a while, until the future library makes its way into the apps.


proper FileTransform usage

Paul Miller <pa...@...>
 

I need advice on the correct way to use a LUT file transform in an OCIO processor. My results when using a FileTransform look different than in Nuke, with whites appearing more subdued using the test LUT I have. Am I doing this right?

My normal OCIO processor looks like this:

DisplayTransformRcPtr transform = DisplayTransform::Create();
transform->setInputColorSpaceName(colorSpaceName);
transform->setDisplay(displayName);
transform->setView(lookName);
transform->setLinearCC(gainTransform);
transform->setChannelView(swizzle);
transform->setDisplayCC(exposureTransform);

processor = config->getProcessor(transform);

However, I also allow bringing in an external LUT file, and I use it like this in lieu of the DisplayTransform:

FileTransformRcPtr fileTransform = FileTransform::Create();
fileTransform->setSrc(path);
fileTransform->setInterpolation(OCIO::INTERP_LINEAR);

GroupTransformRcPtr group = GroupTransform::Create();
group->push_back(gainTransform);
group->push_back(fileTransform);
group->push_back(exposureTransform);

processor = config->getProcessor(group);

I'm using the same display shader for both.


Re: OpenColorIO stewardship

Mark Visser <mvi...@...>
 

Hi Mark,

Could you give us an update on the timeline?

thanks,
-Mark

On Tuesday, November 24, 2015 at 10:55:48 AM UTC-5, Mark Boorer wrote:
Hi Mark,

We have a number of large changes about to land in the public repository, and whilst I know it's frustrating to see the repo stagnant, by no means is the project dead.
My current goal is to put our humungous patch out into the public domain, seek feedback, and then assess how that affects the state of the existing pull requests / issues.
This patch should tackle a number of outstanding issues, primarily the plugin arcitecture, differences between the GPU and CPU code-paths, better unit testing, improved CMake code for cross platform builds, documentation, and repository structure. There are others working on new file-format plugins whose work I am hoping to integrate soon.

In addition, there is also a large amount of organisation happening behind-the-scenes to do with our official ACES implementation on the config side of things.

I am working towards having this ready for feedback by the new year, and once this is done we will hopefully see a lot more activity in the open again.

Cheers,
Mark



On Tue, Nov 24, 2015 at 3:31 PM, Mark Visser <mvi...@...> wrote:
Hi all, 

Development in the main imageworks/OpenColorIO branch seems to have stalled. The last commit is from September, 2014, and the number of issues and pull requests continues to grow.

What do folks think about creating an OpenColorIO github organization and centralizing development there? I know there are several active forks at other studios, but looking at the official repo and web site, the project would appear to be dead. I don't imagine downstream maintainers will pull from anywhere but the official repo, so any fixes and features made in other forks won't show up in Nuke/Maya/RV/etc.

best,
Mark

--
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: Compatible software list

simon smith <si.c....@...>
 

Could you also add HDR Light Studio v5.0+ (www.lightmap.co.uk) as compatible software too please.

We ship the OCIO configs with the main application to allow users to convert source image data into linear color space, to generated final content in the supported output color space, and also the internal views can be mapped via the native support for OpenColorIO on the appropriate display toolbars.

Cheers,
  Simon C. Smith
   CTO and Co-Founder Lightmap LTD.

On Thursday, October 8, 2015 at 6:11:50 PM UTC+1, Alexandre Gauthier wrote:
Hi,

Could you add Natron (www.natron.fr) as compatible software on the corresponding page on http://opencolorio.org/CompatibleSoftware.html ?
It is made compatible in a very similar way to how Nuke nodes do it. 
The following nodes are available: OCIOCDLTransform, OCIOColorSpace, OCIODisplay, OCIOFileTransform, OCIOLookTransform, OCIOLogConvert

All OCIO configs are bundled in Natron (Aces 1.0, Blender, Nuke-default,Spi-Anim, Spi-Vfx). They can be selected in the Preferences of the application, and the Blender profile is set as default.

cheers,

Alex


Re: Creating mipmapped textures with OpenImageIO

John Coldrick <john.c...@...>
 

Got it!  Cool, thanks Larry...

J.C.


On Friday, January 22, 2016 at 3:29:07 PM UTC-5, Larry Gritz wrote:
There is an oiio-dev group: http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

The oiiotool command line you use is writing a tiled file, but there's more to a MIP-map. When you use maketx, it's creating a multi-resolution (MIP-map levels) as well as embedding some other assorted things in the metadata that help at render time.

Somewhere on my list is to add a feature to oiiotool that would cause it to do exactly the same thing that maketx does. But at present, you're expected to use maketx for that final MIPmap creation step.



On Jan 22, 2016, at 11:49 AM, John Coldrick <john...@...> wrote:

Profuse apologies if this is an inappropriate place to ask about OIIO, but I couldn't find a group for it specifically...

We've been starting to use oiiotool to prep texture maps for 3D, and recently I've been getting incorrect behaviour wrt mipmapping.  We were running this on Windows and I thought perhaps it might have been an obscure bug that slipped between the cracks since most folks are probably using it on Linux, but I recently compiled oiio on centos and got the same results.

If I have an exr file, already linearized, that I wish to mipmap I run:

$ oiiotool ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

and when I run iinfo on this I get 

mymipmap.exr : 2048 x 2048, 4 channel, half openexr


if I run:

$ maketx ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

iinfo provides:

mymipmap.exr : 2048 x 2048, 4 channel, half openexr (+mipmap)


I've verified by testing with render packages that indeed oiiotool is not creating a mipmap and maketx is.


I've tested this with OpenImageIO 1.5.16, 1.5.22 and 1.7.1dev - same results.

Am I doing something fundamentally wrong?  Many thanks for your thoughts...

J.C.

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

--
Larry Gritz
l....@...



Re: Creating mipmapped textures with OpenImageIO

Larry Gritz <l...@...>
 

There is an oiio-dev group: http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

The oiiotool command line you use is writing a tiled file, but there's more to a MIP-map. When you use maketx, it's creating a multi-resolution (MIP-map levels) as well as embedding some other assorted things in the metadata that help at render time.

Somewhere on my list is to add a feature to oiiotool that would cause it to do exactly the same thing that maketx does. But at present, you're expected to use maketx for that final MIPmap creation step.



On Jan 22, 2016, at 11:49 AM, John Coldrick <john.c...@...> wrote:

Profuse apologies if this is an inappropriate place to ask about OIIO, but I couldn't find a group for it specifically...

We've been starting to use oiiotool to prep texture maps for 3D, and recently I've been getting incorrect behaviour wrt mipmapping.  We were running this on Windows and I thought perhaps it might have been an obscure bug that slipped between the cracks since most folks are probably using it on Linux, but I recently compiled oiio on centos and got the same results.

If I have an exr file, already linearized, that I wish to mipmap I run:

$ oiiotool ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

and when I run iinfo on this I get 

mymipmap.exr : 2048 x 2048, 4 channel, half openexr


if I run:

$ maketx ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

iinfo provides:

mymipmap.exr : 2048 x 2048, 4 channel, half openexr (+mipmap)


I've verified by testing with render packages that indeed oiiotool is not creating a mipmap and maketx is.


I've tested this with OpenImageIO 1.5.16, 1.5.22 and 1.7.1dev - same results.

Am I doing something fundamentally wrong?  Many thanks for your thoughts...

J.C.

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

--
Larry Gritz
l...@...



Creating mipmapped textures with OpenImageIO

John Coldrick <john.c...@...>
 

Profuse apologies if this is an inappropriate place to ask about OIIO, but I couldn't find a group for it specifically...

We've been starting to use oiiotool to prep texture maps for 3D, and recently I've been getting incorrect behaviour wrt mipmapping.  We were running this on Windows and I thought perhaps it might have been an obscure bug that slipped between the cracks since most folks are probably using it on Linux, but I recently compiled oiio on centos and got the same results.

If I have an exr file, already linearized, that I wish to mipmap I run:

$ oiiotool ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

and when I run iinfo on this I get 

mymipmap.exr : 2048 x 2048, 4 channel, half openexr


if I run:

$ maketx ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

iinfo provides:

mymipmap.exr : 2048 x 2048, 4 channel, half openexr (+mipmap)


I've verified by testing with render packages that indeed oiiotool is not creating a mipmap and maketx is.


I've tested this with OpenImageIO 1.5.16, 1.5.22 and 1.7.1dev - same results.

Am I doing something fundamentally wrong?  Many thanks for your thoughts...

J.C.


Re: color picking role, used in Nuke?

lucien...@...
 

Hey guys,

thanks for you answers!

So one would grade aces material in Nuke by only looking at his viewer rather than picking a shade from the color wheel I guess.

Anyone wants to chime in, production experience of comping in Aces/AcesCG?

Cheers


Le lundi 9 novembre 2015 12:47:45 UTC-8, Troy James Sobotka a écrit :

Greetings Lucien. Fellow Vancouverite here.

I made a simple OCIO configuration to test whether or not colour pickers are colour managed. It is only a rotation of sRGB primaries so that it is deadly obvious whether or not the application is colour managing correctly.

If you are using a wider gamut reference, the colour primaries will be quite different, and as such, the pickers would need to be properly transformed to whatever display is currently in use. Chances are, the picker isn't, and is instead dumping ambiguous RGB values direct to the display, putting the primaries in whatever the display currently happens to be.

The test config should reveal it quite quickly. If the pickers aren't colour managed, then artists have no real clue what they are picking. This would, for example, result in picking rough sRGB display values by eye, while the RGB triplets represent something else entirely in the reference space.

Feel free to email me privately if you have issues with the configuration.

https://github.com/sobotka/OpenColorIO-Colour-Management-Test

With respect,
TJS


On Mon, Nov 9, 2015, 11:39 AM Deke Kincaid <deke...@...> wrote:
Nuke does not use the colorpicking role and it selectively uses the roles in general as there is no direct mapping for some of them.

On Mon, Nov 9, 2015 at 11:17 AM, <luci...@...> wrote:
Hi everyone,

Let me start by introducing myself, I currently work at Image Engine, Vancouver and previously I was at Framestore, London.

I'm looking at doing comp work with wider gamut sources and I'm wondering about the color picker color management in Nuke.

Does anyone have found if the color picking role is ever being used by Nuke?
Should I do transformation myself if not?Anyone has tips to do that elegantly?

Cheers

Lucien

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

--
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: disabling specific channels during view

Paul Miller <pa...@...>
 

Thanks Matt - that code is pretty much what I already had. But the Nuke code doesn't handle a channelHot of 1,1,0,0 either. When I do this, it solos the alpha channel instead.

On 12/29/15 10:23 AM, Matt Plec wrote:
Hi Paul -

The Nuke OCIO Display node does that and also sets up a matrix transform for a swizzle with setChannelView() -- https://github.com/imageworks/OpenColorIO/blob/master/src/nuke/OCIODisplay/OCIODisplay.cpp#L337

One thing to watch out for: If I'm remembering right, this is applied before the view colorspace conversion in the display transform, so if there's crosstalk in that then you can still end up with non-zero values in channels you had zeroed out.



On Mon, Dec 28, 2015 at 9:05 AM, Paul Miller <pa...@...> wrote:
I'm trying to figure out how I can get just red and green to show up for example. I've tried setting channelsHot to [1, 1, 0, 0] in the MatrixTransform::View() function but that doesn't do the right thing. I've also tried setting lumcoeff[2] = 0 but that doesn't have any effect.

Any suggestions?

--
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: disabling specific channels during view

Matt Plec <mp...@...>
 

Hi Paul -

The Nuke OCIO Display node does that and also sets up a matrix transform for a swizzle with setChannelView() -- https://github.com/imageworks/OpenColorIO/blob/master/src/nuke/OCIODisplay/OCIODisplay.cpp#L337

One thing to watch out for: If I'm remembering right, this is applied before the view colorspace conversion in the display transform, so if there's crosstalk in that then you can still end up with non-zero values in channels you had zeroed out.



On Mon, Dec 28, 2015 at 9:05 AM, Paul Miller <pa...@...> wrote:
I'm trying to figure out how I can get just red and green to show up for example. I've tried setting channelsHot to [1, 1, 0, 0] in the MatrixTransform::View() function but that doesn't do the right thing. I've also tried setting lumcoeff[2] = 0 but that doesn't have any effect.

Any suggestions?

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


disabling specific channels during view

Paul Miller <pa...@...>
 

I'm trying to figure out how I can get just red and green to show up for example. I've tried setting channelsHot to [1, 1, 0, 0] in the MatrixTransform::View() function but that doesn't do the right thing. I've also tried setting lumcoeff[2] = 0 but that doesn't have any effect.

Any suggestions?

761 - 780 of 2216