Date   

Review: Building/config related docs

"dbr/Ben" <b...@...>
 

Added Python versions of most of the C++ usage examples (except the GPU one, as the Processor.getGpuLut3D method isn't exposed). Might not be terribly practical code, but it's a nice demo of the Python bindings (plus not being hugely familiar with C++, I find it extremely useful seeing both side by side!)



Other commits relate the docs, mainly the setup page:

Link to license page from FAQ

"Building from source" page. Not totally sure this is best-practices etc, but seem sensible and looks similar to the existing INSTALL file

Mention the LD_ and DYLD_LIBRARY_PATH env-vars on setup page

"Nuke configuration" section on setup page

...and reorganise the headings for the above changes, to keep the ToC tidy (rST's heading notation is slightly.. odd)

Temporarily copied a built version of the updated docs to http://dl.dropbox.com/u/796113/ocio_docs_temp/index.html

Shall do the CLA tomorrow afternoon!
- Ben


Re: Review: Support python with --exec-prefix and registering Nuke viewer processes

"dbr/Ben" <b...@...>
 

Good point about the viewers. Thinking about it now, I wouldn't use the viewer-proc registration from the OCIO installation, as it'd be untweakable.. So, perhaps this would be more appropriate as part of the documentation, rather than something installed by default?

I've made some changes to the Sphinx docs which, among other things, mention the ocio_populate_viewer - shall write a separate "Review:" mail about this to keep things tidy.

Thanks for all the feedback!
- Ben

On 12/01/2011, at 10:58 AM, Jeremy Selan wrote:

Done.

I've checked this into master, with a few changes:
* Nuke_INSTALL_PATH is now NUKE_INSTALL_PATH (all caps)

I know the old value predates this checkin, but now that it's
publicized I figure we should make it all caps to match all the other
CMake configuration options.

* OCIO python module is now put in the global namespace, so it's
available to other scripts (and the script panel).

* The ocio viewer mojo is not executed by default in menu.py. Users
are free to call ocio_populate_menu() though at any time to run the
code though.

-- Jeremy

On Tue, Jan 11, 2011 at 1:21 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
It all looks great other than the ocio_viewer as I would need to disable this for our install.

I think the nuke nodes should only be registered as part of the ocio project initialisation.

Viewer gizmo's are normally a per company/project configuration, maybe it would be better to include this as a separate example gizmo for people to copy in to their setup.

.malcolm

On 12/01/2011, at 6:07 AM, Jeremy Selan wrote:

Thanks for the commits!

Look great at first glance. (I'll run it all this afternoon to make
sure it works multi-platform, etc). I like all the nuke cleanup, very
sensible.

My one concern is I'm not convinced the pre-filled display nodes at
startup are appropriate in menu.py. Your new code is an excellent
example to point folks in the right direction, but it may a bit too
overbearing to actually create instances for the user at startup.
Would you expect the average facility to use the code, as written? Or,
is this just an example which you would expect people to customize?
Perhaps this function should be in a different file, which the user is
encouraged to customize as needed?

You can link into the viewer's gain/gamma (just make an expression to
Viewer1.gain, Viewer1.gamma), but there's no way to prevent nuke from
applying the cc math when the sliders are moved. In the short term
maybe the foundry could expose monitor options to disable the
gain/gamma math? (In the long terms, there's potential to have nuke
directly ship with builtin OCIO color management)

-- Jeremy


On Tue, Jan 11, 2011 at 4:28 AM, dbr/Ben <dbr....@...> wrote:
I've made a few minor changes, partly to familiarise myself with the
code, partly to say thanks for open-sourcing this extremely useful
project!


First change - there was a hardcoded Nuke path, which meant you
couldn't do "cmake -D Nuke_INSTALL_PATH=/blah". Not sure if there's a
reason this this was hardcoded, but it's a (trivially) nicer than
using the env-variable:

https://github.com/dbr/OpenColorIO/commit/321625205caa1ad9a8735571f617a226493c6b44


Second a slightly less trivial - to support Python installations that
use --exec-prefix to put arch-specific stuff in a separate directory -
before it would fail to compile, complaining "pyconfig.h was not
found" (I guess it's pretty uncommon to use --exec-prefix, as even
PyQT had/has this issue..)

Tested on CentOS, with the exec-prefix'd Python, and OS X 10.6 with
the default system Python, both worked work fine.

https://github.com/dbr/OpenColorIO/commit/131efac091419aaa9d7729ba7f330c241d75917f


Final two commits are to the init.py and menu.py - automagical loading/
menu'ing of the OCIO nodes, and a first attempt at registering
OCIODisplay nodes as Nuke viewer processes.

It adds one process for every display and every transform (e.g "Film1D
(sRGB)", "Log (sRGB)", "Film1D (P3)", "Log (P3)") - seemed like the
most Nuke'ish solution given the limitations of the viewer
customisation.

On that subject, I wonder if it's possible to somehow tie the viewer's
exposure/gamma controls to the OCIODIsplay node.. I suspect not
currently.

https://github.com/dbr/OpenColorIO/commit/0cdf665eba7bd9dbeadcb94d9d446a4424a81303
https://github.com/dbr/OpenColorIO/commit/8151eca9edf3acf027e2a60ea3857f2240af6461


As I said, nothing too exciting.. I'm hoping to integrate OCIO into
the pipeline at work soon, so will almost certainly have more patches/
questions/feature-requests soon!

Oh, I've not signed a CLA yet - these changes seemed trivial enough
for it not to be necessary, but I will do so soon. Let me know if this
is a problem

Anyway, thanks again to everyone involved in this project!
- Ben Dickson


Re: GPUAllocation?

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

In your example, is the native type float linear?

Presuming so, I would check two things. In your gpu version, make
sure that the gpu texture buffer you're loading into is floating
point. You'll want to make sure you're using something like
GL_RGB16F_ARB (as opposed to GL_RGB). If you were referencing the
ociodisplay app as an example, it unfortunately makes exactly this
mistake. (It's fixed though in my most recent code submission, not
yet rolled into the trunk).
Yep this fixed it, and yeah I was just copying large sections of ociodisplay.

The other thing to check is the allocation for the colorspace. The
allocation determines, if a 3d lut stage is necessary, how to perform
the allocation. For 'typical' HDR data, I would recommend something
like,

allocation: lg2
allocationvars: [-12, 6]

What this means is that the gpu should sample the colorspace using a
logarathimic allocation (code value proportional to stops), from
2**-12, to 2**6. I.e., anything less than 0.0002 or greater than
64.0 is clamped.
Ok thats good to know.

I've been using what ever the values are in the current spi-vfx profile just
to cutout any added malcolm factor.

.malcolm

-- Jeremy

On Wed, Jan 12, 2011 at 9:13 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
While working on this ocio photoshop plugin I noticed a difference in the cpu vs gpu path.

Attached is a screenshot.

The image on top has been imported by the plugin already and processed on the cpu, while the dialog below is a GL canvas using the gpu path for preview.

I'm guessing this is the allocation we are using on the gpu?

.malcolm






Re: GPUAllocation?

Jeremy Selan <jeremy...@...>
 

In your example, is the native type float linear?

Presuming so, I would check two things. In your gpu version, make
sure that the gpu texture buffer you're loading into is floating
point. You'll want to make sure you're using something like
GL_RGB16F_ARB (as opposed to GL_RGB). If you were referencing the
ociodisplay app as an example, it unfortunately makes exactly this
mistake. (It's fixed though in my most recent code submission, not
yet rolled into the trunk).

The other thing to check is the allocation for the colorspace. The
allocation determines, if a 3d lut stage is necessary, how to perform
the allocation. For 'typical' HDR data, I would recommend something
like,

allocation: lg2
allocationvars: [-12, 6]

What this means is that the gpu should sample the colorspace using a
logarathimic allocation (code value proportional to stops), from
2**-12, to 2**6. I.e., anything less than 0.0002 or greater than
64.0 is clamped.


-- Jeremy

On Wed, Jan 12, 2011 at 9:13 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
While working on this ocio photoshop plugin I noticed a difference in the cpu vs gpu path.

Attached is a screenshot.

The image on top has been imported by the plugin already and processed on the cpu, while the dialog below is a GL canvas using the gpu path for preview.

I'm guessing this is the allocation we are using on the gpu?

.malcolm






Re: Review: updated ociodisplay + ocioconvert

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

LGTM

I was thinking rather than having these in src/examples they should be src/apps as
they will be pretty useful things to have around.

.malcolm

On 13/01/2011, at 10:06 AM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/51

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/afe8a04366515a152197c345e0362bd6f5540c37

* Added makefile support for ociodisplay + ocioconvert.

These are built optionally, if one adds the proper cmake options.

Example:
mkdir -p build && cd build
mkdir -p install
cmake -D CMAKE_BUILD_TYPE=Release \
-D CMAKE_INSTALL_PREFIX=install \
-D USE_OPENGL=1 \
-D USE_OIIO=1 \
-D OIIO_PATH=/net/homedirs/jeremys/svn/oiio/dist/spinux1/ \
-D PYTHON=/usr/bin/python2.5 \
../
make -j8 && make install

setenv $LD_LIBRARY_PATH to include OIIO + OCIO
setenv $OCIO path to .config
ociodisplay <IMG>


-- Jeremy


GPUAllocation?

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

While working on this ocio photoshop plugin I noticed a difference in the cpu vs gpu path.

Attached is a screenshot.

The image on top has been imported by the plugin already and processed on the cpu, while the dialog below is a GL canvas using the gpu path for preview.

I'm guessing this is the allocation we are using on the gpu?

.malcolm


Review: updated ociodisplay + ocioconvert

Jeremy Selan <jeremy...@...>
 

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/51

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/afe8a04366515a152197c345e0362bd6f5540c37

* Added makefile support for ociodisplay + ocioconvert.

These are built optionally, if one adds the proper cmake options.

Example:
mkdir -p build && cd build
mkdir -p install
cmake -D CMAKE_BUILD_TYPE=Release \
-D CMAKE_INSTALL_PREFIX=install \
-D USE_OPENGL=1 \
-D USE_OIIO=1 \
-D OIIO_PATH=/net/homedirs/jeremys/svn/oiio/dist/spinux1/ \
-D PYTHON=/usr/bin/python2.5 \
../
make -j8 && make install

setenv $LD_LIBRARY_PATH to include OIIO + OCIO
setenv $OCIO path to .config
ociodisplay <IMG>


-- Jeremy


Re: Review: Misc fixes

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

LGTM

.malcolm


Review: Misc fixes

Jeremy Selan <jeremy...@...>
 

3 unrelated commits.

1) Updated an error message in config loading.
http://github.com/jeremyselan/OpenColorIO/commit/05b84bca45187f4f5f2c8117ce0bb2a553a36f16

2) GLSL shader doesnt use invalid keywords in 1.0 mode. Also works
around glsl bug on osx.
http://github.com/jeremyselan/OpenColorIO/commit/1b2f112e46b78c8a351f779c7467b2510ab311ad

3) config.parseColorSpaceFromString(...) no longer can return a null ptr.
http://github.com/jeremyselan/OpenColorIO/commit/380978b8d88b438da601de8ea5b6a29b7893f9ca

-- Jeremy


Re: Review: Support python with --exec-prefix and registering Nuke viewer processes

Jeremy Selan <jeremy...@...>
 

Done.

I've checked this into master, with a few changes:
* Nuke_INSTALL_PATH is now NUKE_INSTALL_PATH (all caps)

I know the old value predates this checkin, but now that it's
publicized I figure we should make it all caps to match all the other
CMake configuration options.

* OCIO python module is now put in the global namespace, so it's
available to other scripts (and the script panel).

* The ocio viewer mojo is not executed by default in menu.py. Users
are free to call ocio_populate_menu() though at any time to run the
code though.

-- Jeremy

On Tue, Jan 11, 2011 at 1:21 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
It all looks great other than the ocio_viewer as I would need to disable this for our install.

I think the nuke nodes should only be registered as part of the ocio project initialisation.

Viewer gizmo's are normally a per company/project configuration, maybe it would be better to include this as a separate example gizmo for people to copy in to their setup.

.malcolm

On 12/01/2011, at 6:07 AM, Jeremy Selan wrote:

Thanks for the commits!

Look great at first glance.  (I'll run it all this afternoon to make
sure it works multi-platform, etc).  I like all the nuke cleanup, very
sensible.

My one concern is I'm not convinced the pre-filled display nodes at
startup are appropriate in menu.py.  Your new code is an excellent
example to point folks in the right direction, but it may a bit too
overbearing to actually create instances for the user at startup.
Would you expect the average facility to use the code, as written? Or,
is this just an example which you would expect people to customize?
Perhaps this function should be in a different file, which the user is
encouraged to customize as needed?

You can link into the viewer's gain/gamma (just make an expression to
Viewer1.gain, Viewer1.gamma), but there's no way to prevent nuke from
applying the cc math when the sliders are moved.    In the short term
maybe the foundry could expose monitor options to disable the
gain/gamma math?  (In the long terms, there's potential to have nuke
directly ship with builtin OCIO color management)

-- Jeremy


On Tue, Jan 11, 2011 at 4:28 AM, dbr/Ben <dbr....@...> wrote:
I've made a few minor changes, partly to familiarise myself with the
code, partly to say thanks for open-sourcing this extremely useful
project!


First change - there was a hardcoded Nuke path, which meant you
couldn't do "cmake -D Nuke_INSTALL_PATH=/blah". Not sure if there's a
reason this this was hardcoded, but it's a (trivially) nicer than
using the env-variable:

https://github.com/dbr/OpenColorIO/commit/321625205caa1ad9a8735571f617a226493c6b44


Second a slightly less trivial - to support Python installations that
use --exec-prefix to put arch-specific stuff in a separate directory -
before it would fail to compile, complaining "pyconfig.h was not
found" (I guess it's pretty uncommon to use --exec-prefix, as even
PyQT had/has this issue..)

Tested on CentOS, with the exec-prefix'd Python, and OS X 10.6 with
the default system Python, both worked work fine.

https://github.com/dbr/OpenColorIO/commit/131efac091419aaa9d7729ba7f330c241d75917f


Final two commits are to the init.py and menu.py - automagical loading/
menu'ing of the OCIO nodes, and a first attempt at registering
OCIODisplay nodes as Nuke viewer processes.

It adds one process for every display and every transform (e.g "Film1D
(sRGB)", "Log (sRGB)", "Film1D (P3)", "Log (P3)") - seemed like the
most Nuke'ish solution given the limitations of the viewer
customisation.

On that subject, I wonder if it's possible to somehow tie the viewer's
exposure/gamma controls to the OCIODIsplay node.. I suspect not
currently.

https://github.com/dbr/OpenColorIO/commit/0cdf665eba7bd9dbeadcb94d9d446a4424a81303
https://github.com/dbr/OpenColorIO/commit/8151eca9edf3acf027e2a60ea3857f2240af6461


As I said, nothing too exciting.. I'm hoping to integrate OCIO into
the pipeline at work soon, so will almost certainly have more patches/
questions/feature-requests soon!

Oh, I've not signed a CLA yet - these changes seemed trivial enough
for it not to be necessary, but I will do so soon. Let me know if this
is a problem

Anyway, thanks again to everyone involved in this project!
- Ben Dickson


Re: Review: Support python with --exec-prefix and registering Nuke viewer processes

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

It all looks great other than the ocio_viewer as I would need to disable this for our install.

I think the nuke nodes should only be registered as part of the ocio project initialisation.

Viewer gizmo's are normally a per company/project configuration, maybe it would be better to include this as a separate example gizmo for people to copy in to their setup.

.malcolm

On 12/01/2011, at 6:07 AM, Jeremy Selan wrote:

Thanks for the commits!

Look great at first glance. (I'll run it all this afternoon to make
sure it works multi-platform, etc). I like all the nuke cleanup, very
sensible.

My one concern is I'm not convinced the pre-filled display nodes at
startup are appropriate in menu.py. Your new code is an excellent
example to point folks in the right direction, but it may a bit too
overbearing to actually create instances for the user at startup.
Would you expect the average facility to use the code, as written? Or,
is this just an example which you would expect people to customize?
Perhaps this function should be in a different file, which the user is
encouraged to customize as needed?

You can link into the viewer's gain/gamma (just make an expression to
Viewer1.gain, Viewer1.gamma), but there's no way to prevent nuke from
applying the cc math when the sliders are moved. In the short term
maybe the foundry could expose monitor options to disable the
gain/gamma math? (In the long terms, there's potential to have nuke
directly ship with builtin OCIO color management)

-- Jeremy


On Tue, Jan 11, 2011 at 4:28 AM, dbr/Ben <dbr....@...> wrote:
I've made a few minor changes, partly to familiarise myself with the
code, partly to say thanks for open-sourcing this extremely useful
project!


First change - there was a hardcoded Nuke path, which meant you
couldn't do "cmake -D Nuke_INSTALL_PATH=/blah". Not sure if there's a
reason this this was hardcoded, but it's a (trivially) nicer than
using the env-variable:

https://github.com/dbr/OpenColorIO/commit/321625205caa1ad9a8735571f617a226493c6b44


Second a slightly less trivial - to support Python installations that
use --exec-prefix to put arch-specific stuff in a separate directory -
before it would fail to compile, complaining "pyconfig.h was not
found" (I guess it's pretty uncommon to use --exec-prefix, as even
PyQT had/has this issue..)

Tested on CentOS, with the exec-prefix'd Python, and OS X 10.6 with
the default system Python, both worked work fine.

https://github.com/dbr/OpenColorIO/commit/131efac091419aaa9d7729ba7f330c241d75917f


Final two commits are to the init.py and menu.py - automagical loading/
menu'ing of the OCIO nodes, and a first attempt at registering
OCIODisplay nodes as Nuke viewer processes.

It adds one process for every display and every transform (e.g "Film1D
(sRGB)", "Log (sRGB)", "Film1D (P3)", "Log (P3)") - seemed like the
most Nuke'ish solution given the limitations of the viewer
customisation.

On that subject, I wonder if it's possible to somehow tie the viewer's
exposure/gamma controls to the OCIODIsplay node.. I suspect not
currently.

https://github.com/dbr/OpenColorIO/commit/0cdf665eba7bd9dbeadcb94d9d446a4424a81303
https://github.com/dbr/OpenColorIO/commit/8151eca9edf3acf027e2a60ea3857f2240af6461


As I said, nothing too exciting.. I'm hoping to integrate OCIO into
the pipeline at work soon, so will almost certainly have more patches/
questions/feature-requests soon!

Oh, I've not signed a CLA yet - these changes seemed trivial enough
for it not to be necessary, but I will do so soon. Let me know if this
is a problem

Anyway, thanks again to everyone involved in this project!
- Ben Dickson


Re: Review: Support python with --exec-prefix and registering Nuke viewer processes

Jeremy Selan <jeremy...@...>
 

Thanks for the commits!

Look great at first glance. (I'll run it all this afternoon to make
sure it works multi-platform, etc). I like all the nuke cleanup, very
sensible.

My one concern is I'm not convinced the pre-filled display nodes at
startup are appropriate in menu.py. Your new code is an excellent
example to point folks in the right direction, but it may a bit too
overbearing to actually create instances for the user at startup.
Would you expect the average facility to use the code, as written? Or,
is this just an example which you would expect people to customize?
Perhaps this function should be in a different file, which the user is
encouraged to customize as needed?

You can link into the viewer's gain/gamma (just make an expression to
Viewer1.gain, Viewer1.gamma), but there's no way to prevent nuke from
applying the cc math when the sliders are moved. In the short term
maybe the foundry could expose monitor options to disable the
gain/gamma math? (In the long terms, there's potential to have nuke
directly ship with builtin OCIO color management)

-- Jeremy

On Tue, Jan 11, 2011 at 4:28 AM, dbr/Ben <dbr....@...> wrote:
I've made a few minor changes, partly to familiarise myself with the
code, partly to say thanks for open-sourcing this extremely useful
project!


First change - there was a hardcoded Nuke path, which meant you
couldn't do "cmake -D Nuke_INSTALL_PATH=/blah". Not sure if there's a
reason this this was hardcoded, but it's a (trivially) nicer than
using the env-variable:

https://github.com/dbr/OpenColorIO/commit/321625205caa1ad9a8735571f617a226493c6b44


Second a slightly less trivial - to support Python installations that
use --exec-prefix to put arch-specific stuff in a separate directory -
before it would fail to compile, complaining "pyconfig.h was not
found" (I guess it's pretty uncommon to use --exec-prefix, as even
PyQT had/has this issue..)

Tested on CentOS, with the exec-prefix'd Python, and OS X 10.6 with
the default system Python, both worked work fine.

https://github.com/dbr/OpenColorIO/commit/131efac091419aaa9d7729ba7f330c241d75917f


Final two commits are to the init.py and menu.py - automagical loading/
menu'ing of the OCIO nodes, and a first attempt at registering
OCIODisplay nodes as Nuke viewer processes.

It adds one process for every display and every transform (e.g "Film1D
(sRGB)", "Log (sRGB)", "Film1D (P3)", "Log (P3)") - seemed like the
most Nuke'ish solution given the limitations of the viewer
customisation.

On that subject, I wonder if it's possible to somehow tie the viewer's
exposure/gamma controls to the OCIODIsplay node.. I suspect not
currently.

https://github.com/dbr/OpenColorIO/commit/0cdf665eba7bd9dbeadcb94d9d446a4424a81303
https://github.com/dbr/OpenColorIO/commit/8151eca9edf3acf027e2a60ea3857f2240af6461


As I said, nothing too exciting.. I'm hoping to integrate OCIO into
the pipeline at work soon, so will almost certainly have more patches/
questions/feature-requests soon!

Oh, I've not signed a CLA yet - these changes seemed trivial enough
for it not to be necessary, but I will do so soon. Let me know if this
is a problem

Anyway, thanks again to everyone involved in this project!
- Ben Dickson


Review: Support python with --exec-prefix and registering Nuke viewer processes

"dbr/Ben" <dbr....@...>
 

I've made a few minor changes, partly to familiarise myself with the
code, partly to say thanks for open-sourcing this extremely useful
project!


First change - there was a hardcoded Nuke path, which meant you
couldn't do "cmake -D Nuke_INSTALL_PATH=/blah". Not sure if there's a
reason this this was hardcoded, but it's a (trivially) nicer than
using the env-variable:

https://github.com/dbr/OpenColorIO/commit/321625205caa1ad9a8735571f617a226493c6b44


Second a slightly less trivial - to support Python installations that
use --exec-prefix to put arch-specific stuff in a separate directory -
before it would fail to compile, complaining "pyconfig.h was not
found" (I guess it's pretty uncommon to use --exec-prefix, as even
PyQT had/has this issue..)

Tested on CentOS, with the exec-prefix'd Python, and OS X 10.6 with
the default system Python, both worked work fine.

https://github.com/dbr/OpenColorIO/commit/131efac091419aaa9d7729ba7f330c241d75917f


Final two commits are to the init.py and menu.py - automagical loading/
menu'ing of the OCIO nodes, and a first attempt at registering
OCIODisplay nodes as Nuke viewer processes.

It adds one process for every display and every transform (e.g "Film1D
(sRGB)", "Log (sRGB)", "Film1D (P3)", "Log (P3)") - seemed like the
most Nuke'ish solution given the limitations of the viewer
customisation.

On that subject, I wonder if it's possible to somehow tie the viewer's
exposure/gamma controls to the OCIODIsplay node.. I suspect not
currently.

https://github.com/dbr/OpenColorIO/commit/0cdf665eba7bd9dbeadcb94d9d446a4424a81303
https://github.com/dbr/OpenColorIO/commit/8151eca9edf3acf027e2a60ea3857f2240af6461


As I said, nothing too exciting.. I'm hoping to integrate OCIO into
the pipeline at work soon, so will almost certainly have more patches/
questions/feature-requests soon!

Oh, I've not signed a CLA yet - these changes seemed trivial enough
for it not to be necessary, but I will do so soon. Let me know if this
is a problem

Anyway, thanks again to everyone involved in this project!
- Ben Dickson


Re: Review: Exposed gamma control on Nuke OCIODisplay node

Jeremy Selan <jeremy...@...>
 

done.

On Mon, Jan 10, 2011 at 6:00 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
On 11/01/2011, at 12:54 PM, Jeremy Selan wrote:

Spaces in knob names have always worried me.  How about an underscore
in the knob name?
perfect


On Mon, Jan 10, 2011 at 5:51 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
On 11/01/2011, at 12:49 PM, Jeremy Selan wrote:
UI Label or underlying knob name?
I would do both just for consistency.


On Mon, Jan 10, 2011 at 5:48 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
LGTM

I would be tempted to name the knob 'display gamma'.

.malcolm

On 11/01/2011, at 12:43 PM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node.  The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy


Re: Review: Exposed gamma control on Nuke OCIODisplay node

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

On 11/01/2011, at 12:54 PM, Jeremy Selan wrote:

Spaces in knob names have always worried me. How about an underscore
in the knob name?
perfect


On Mon, Jan 10, 2011 at 5:51 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
On 11/01/2011, at 12:49 PM, Jeremy Selan wrote:
UI Label or underlying knob name?
I would do both just for consistency.


On Mon, Jan 10, 2011 at 5:48 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
LGTM

I would be tempted to name the knob 'display gamma'.

.malcolm

On 11/01/2011, at 12:43 PM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node. The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy


Re: Review: Exposed gamma control on Nuke OCIODisplay node

Jeremy Selan <jeremy...@...>
 

Spaces in knob names have always worried me. How about an underscore
in the knob name?

On Mon, Jan 10, 2011 at 5:51 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
On 11/01/2011, at 12:49 PM, Jeremy Selan wrote:
UI Label or underlying knob name?
I would do both just for consistency.


On Mon, Jan 10, 2011 at 5:48 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
LGTM

I would be tempted to name the knob 'display gamma'.

.malcolm

On 11/01/2011, at 12:43 PM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node.  The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy


Re: Review: Exposed gamma control on Nuke OCIODisplay node

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

On 11/01/2011, at 12:49 PM, Jeremy Selan wrote:
UI Label or underlying knob name?
I would do both just for consistency.


On Mon, Jan 10, 2011 at 5:48 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
LGTM

I would be tempted to name the knob 'display gamma'.

.malcolm

On 11/01/2011, at 12:43 PM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node. The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy


Re: Review: Exposed gamma control on Nuke OCIODisplay node

Jeremy Selan <jeremy...@...>
 

UI Label or underlying knob name?

On Mon, Jan 10, 2011 at 5:48 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
LGTM

I would be tempted to name the knob 'display gamma'.

.malcolm

On 11/01/2011, at 12:43 PM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node.  The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy


Re: Review: Exposed gamma control on Nuke OCIODisplay node

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

LGTM

I would be tempted to name the knob 'display gamma'.

.malcolm

On 11/01/2011, at 12:43 PM, Jeremy Selan wrote:

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node. The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy


Review: Exposed gamma control on Nuke OCIODisplay node

Jeremy Selan <jeremy...@...>
 

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/45

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/c206c4fe65d415b5c87c09acde3e05013dc0ab9f

I've exposed a gamma control for the Nuke OCIODisplay node. The gamma
control, like the origin one in nuke's monitor, is post-display
transform.

-- Jeremy

1861 - 1880 of 2215