1. Ocio-Dev
  2. Messages

Expanded

Topics Messages Polls
   Date   
Re: Is the const type qualifier only in CG?

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

I already fixed this too; thought it was checked in last week. hold
for details.

-- Jeremy

On Mon, Jan 17, 2011 at 3:21 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
I'm having an unrelated problem when using a noop processor eg. scene_linear -> data on the gpu.

I'm getting a EXC_BAD_ACCESS when issuing glBegin(GL_QUADS). Having another shader for this case which doesn't reference 'tex2' fixes the problem. I have looked into it a little but it isn't clear why this is happening.

I'll be trying to commit some code that shows this soon.

.malcolm

On 18/01/2011, at 9:13 AM, Jeremy Selan wrote:

No problem!  Let me know if you have any troubles with the updated version.

I should also probably update the ociodisplay program to query the
glsl version, and select the best profile accordingly.

-- Jeremy

On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install.  (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier.  My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy
Re: Is the const type qualifier only in CG?

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

I'm having an unrelated problem when using a noop processor eg. scene_linear -> data on the gpu.

I'm getting a EXC_BAD_ACCESS when issuing glBegin(GL_QUADS). Having another shader for this case which doesn't reference 'tex2' fixes the problem. I have looked into it a little but it isn't clear why this is happening.

I'll be trying to commit some code that shows this soon.

.malcolm

On 18/01/2011, at 9:13 AM, Jeremy Selan wrote:

No problem! Let me know if you have any troubles with the updated version.

I should also probably update the ociodisplay program to query the
glsl version, and select the best profile accordingly.

-- Jeremy

On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install. (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier. My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy
Re: Is the const type qualifier only in CG?

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

No problem! Let me know if you have any troubles with the updated version.

I should also probably update the ociodisplay program to query the
glsl version, and select the best profile accordingly.

-- Jeremy

On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install.  (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier.  My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy
Re: Review: Building/config related docs

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

Committed.

Thanks!

-- Jeremy

On Sun, Jan 16, 2011 at 4:38 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

Oh, good point - I forgot PYTHONPATH also. Mentioned both of these, and few
other minor changes:
https://github.com/dbr/OpenColorIO/commit/573356952ca30f90b3cb4aafa925b33cbf974f99

LGTM
Re: Is the const type qualifier only in CG?

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

Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install. (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier. My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy
Re: Is the const type qualifier only in CG?

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

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install. (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier. My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy
Re: Is the const type qualifier only in CG?

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

Hi Mark,

Thanks for the reply, well that makes sense why it hasn't really been an issue till now.

How would you recommend to solve these types of issues? I can see two obvious ways. if/then blocks with it all mixed together like we are doing, or having it all separated out with cg, glsl_1.2, glsl_1.5 etc paths.

It doesn't seem to be a clean way to do this and both are kind of sucky.

.malcolm

On 18/01/2011, at 8:09 AM, Mark Alexander wrote:

There is a const qualifier in GLSL, and it should work on other
platforms without issue. The difference may be that OSX only supports
GLSL 1.20 currently, which is far behind most of NVidia's and ATI's
OpenGL implementations (GLSL 1.50 at least, more likely 3.30/4.10).
Perhaps this is the reason 'const' is required. Having a shader
compile across multiple GLSL versions and drivers can be tricky, and
I've run into a lot of issues on OSX that are simply GL version
related.

Mark

On Jan 16, 11:39 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
Is the 'const' qualifier in glsl? I have to change the following to get the glsl shader to compile on OSX.

I'm cool to add another if glsl or cg block, just wondering if this could be something else.

.malcolm

diff --git a/src/core/Processor.cpp b/src/core/Processor.cpp
index 2f0f83b..c22770f 100644
--- a/src/core/Processor.cpp
+++ b/src/core/Processor.cpp
@@ -81,7 +81,7 @@ OCIO_NAMESPACE_ENTER
}
else throw Exception("Unsupported shader language.");

- shader << " const uniform sampler3D " << lut3dName << ") \n";
+ shader << " in sampler3D " << lut3dName << ") \n";
shader << "{" << "\n";

if(lang == GPU_LANGUAGE_CG)
Re: Is the const type qualifier only in CG?

Mark Alexander <malex...@...>
 

There is a const qualifier in GLSL, and it should work on other
platforms without issue. The difference may be that OSX only supports
GLSL 1.20 currently, which is far behind most of NVidia's and ATI's
OpenGL implementations (GLSL 1.50 at least, more likely 3.30/4.10).
Perhaps this is the reason 'const' is required. Having a shader
compile across multiple GLSL versions and drivers can be tricky, and
I've run into a lot of issues on OSX that are simply GL version
related.

Mark

On Jan 16, 11:39 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
Is the 'const' qualifier in glsl? I have to change the following to get the glsl shader to compile on OSX.

I'm cool to add another if glsl or cg block, just wondering if this could be something else.

.malcolm

diff --git a/src/core/Processor.cpp b/src/core/Processor.cpp
index 2f0f83b..c22770f 100644
--- a/src/core/Processor.cpp
+++ b/src/core/Processor.cpp
@@ -81,7 +81,7 @@ OCIO_NAMESPACE_ENTER
             }
             else throw Exception("Unsupported shader language.");

-            shader << "    const uniform sampler3D " << lut3dName << ") \n";
+            shader << "    in sampler3D " << lut3dName << ") \n";
             shader << "{" << "\n";

             if(lang == GPU_LANGUAGE_CG)
Is the const type qualifier only in CG?

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

Is the 'const' qualifier in glsl? I have to change the following to get the glsl shader to compile on OSX.

I'm cool to add another if glsl or cg block, just wondering if this could be something else.

.malcolm

diff --git a/src/core/Processor.cpp b/src/core/Processor.cpp
index 2f0f83b..c22770f 100644
--- a/src/core/Processor.cpp
+++ b/src/core/Processor.cpp
@@ -81,7 +81,7 @@ OCIO_NAMESPACE_ENTER
}
else throw Exception("Unsupported shader language.");

- shader << " const uniform sampler3D " << lut3dName << ") \n";
+ shader << " in sampler3D " << lut3dName << ") \n";
shader << "{" << "\n";

if(lang == GPU_LANGUAGE_CG)
Review: Replaced config->getRoleNameByIndex

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

When building some UI menus, I wanted to get a list of defined roles. Config::getRoleNameByIndex() only returned the resolved colorspace name.

--snip--
Replaced config->getRoleNameByIndex (which returned the colorspace name, not the role name) with the following:

- getRoleName(int): get the role name at index, this will return values like 'scene_linear', 'compositing_log'. Returns NULL if index is out of range

- getRoleColorSpaceName(int): get the actual colorspace name at role index. Returns NULL when index is out of range

- getRoleColorSpaceName(char*): get the actual colorspace name from a role name. Returns NULL if roles is not defined
--snip--

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

.malcolm
Re: Review: Building/config related docs

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


Oh, good point - I forgot PYTHONPATH also. Mentioned both of these, and few other minor changes:


LGTM

Also a slightly-unrelated change, but for some reason when building on OS X, Boost was not optional, as Boost_INCLUDE_DIR was used in core, pyglue and testbed. Not entirely sure this is the right solution, but it works for me..


LGTM

This is a good fix till we add boost/shared_ptr.hpp to ocio or replace it with tr1/memory in OpenColorTypes.h. Right now you need boost on linux to build.

.malcolm

I think the former could be sensible - keep all the documentation in the git repository, so it is always in sync with the code, and make is simple to get the docs as they were for a given version

+1

.malcolm
Context/per-shot grades

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

If I understand correctly, the Context allows you to set a search path including env-variables (e.g $SEQ/$SHOT), so you can define a FileTransform, and it'll look in the shot's directory before the "default" directory? (just figured this out after writing the remainder of this email, so it might right slightly oddly..)

I wonder, could (or does) the context system allow parameterised transforms? E.g in pseudo-YAML:

context-values:
ab:
ab-123:
slope: [2, 1, 1]
default:
slope: [1, 1, 1]

displays:
- !<Display> {device: sRGB, name: "Film Graded", colorspace: srgb8_graded}

colorspaces:
- !<ColorSpace>
name: srgb8_graded
family: srgb
bitdepth: 8ui
isdata: false
from_reference: !<GroupTransform>
children:
- !<CDLTransform>
slope: $slope
offset: [0, 0, 0]
power: [1, 1, 1]
saturation: 1
- !<ColorSpaceTransform> {src: lnf, dst: lg10}
- !<FileTransform> {src: filmemulation.spi3d, interpolation: linear}


Possibly better to explain what I'm trying to achieve:

Say I have grades for a several shots, which should be used to view the comp (a CDL grade, or printer light offset etc). I could create a group transform containing: the parameterised colour transform, the log'ification and display LUT. Then you'd just need a simple script to populate the config with grade values (e.g from Shotgun)

The same concept could maybe be extended for, say, creating neutrally graded plates (a GroupTransform that linearises and applies a grade), but I can think of various problems/complexities with this, so it'd probably be simpler doing this with a modified version of the ocioconvert tool or something (as grading plates isn't a shot-specific thing, it's a scan specific thing, so the context would have to be based on file paths, which isn't something OCIO could really parse)

Hmm, being able to have per-shot FileTransform's (using the Context dynamic search path) is probably enough, e.g:

children:
- !<FileTransform>: {src: grade.spi1d}
- !<ColorSpaceTransform> {src: lnf, dst: lg10}
- !<FileTransform> {src: filmemulation.spi3d, interpolation: linear}

Although it would be nice to avoid writing a file per shot, and avoid turning a nice simple tuple3f into a LUT or transform matrix (then again, I've done per-shot LUT's in the past and it wasn't a problem, plus those files had to contain both the 1D grade and the 3D display LUT)

Hope some of that made sense - sorry for the slightly long-and-rambling email!
- Ben
Re: Review: Building/config related docs

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

On 14/01/2011, at 7:23 AM, Malcolm Humphreys wrote:

The only thing I can see is missing is a section on NUKE_PATH in the environment section.

Oh, good point - I forgot PYTHONPATH also. Mentioned both of these, and few other minor changes:


Also a slightly-unrelated change, but for some reason when building on OS X, Boost was not optional, as Boost_INCLUDE_DIR was used in core, pyglue and testbed. Not entirely sure this is the right solution, but it works for me..



On 14/01/2011, at 4:41 AM, Jeremy Selan wrote:

Oh, and an observation:  we now essentially have two masters for the
docs, the inline documentation, and the webpage version.  My
inclination is to treat the git version as the master, and then to do
periodic html / pdf drops to the website.    I'm thinking I could make
docs and post them for every dot release. Thoughts?

Do you mean having the http://opencolorio.org site be generated from the latest version's Sphinx docs? Or the sphinx docs be accessible from the site's "Documentation" link?

I think the former could be sensible - keep all the documentation in the git repository, so it is always in sync with the code, and make is simple to get the docs as they were for a given version

Should be pretty simple to tweak Sphinx so it works nicely as a homepage (with a nice intro page instead of just the table-of-contents and so on)

- Ben
Re: Review: Building/config related docs

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

rock and roll these docs are great.

The only thing I can see is missing is a section on NUKE_PATH in the environment section.

.malcolm


On 14/01/2011, at 1:11 AM, dbr/Ben wrote:

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
0.7.5 Released

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

**Version 0.7.5 (Jan 13 2011):**
* ociodisplay enhancements
* gpu display bugfix (glsl profile 1.0 only)
* Makefile enhancements
* Nuke installation cleanup
* Doc generation using sphinx (html + pdf)

Matching documentation (pdf/html) will be posted later today.
Re: Review: Building/config related docs

Joseph Slomka <jsl...@...>
 

This makes sense as you get to release. The code gets the most frequent updates and the webpage represents the current used version.

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Jeremy Selan
Sent: Thursday, January 13, 2011 10:11 AM
To: ocio...@...
Subject: Re: [ocio-dev] Review: Building/config related docs

Oh, and an observation: we now essentially have two masters for the
docs, the inline documentation, and the webpage version. My
inclination is to treat the git version as the master, and then to do
periodic html / pdf drops to the website. I'm thinking I could make
docs and post them for every dot release. Thoughts?

-- Jeremy

On Thu, Jan 13, 2011 at 10:08 AM, Jeremy Selan <jeremy...@...> wrote:
Looks good to me.
These commits were all on the same topic, so I merged them into a
single checkin, "Documentation cleanup".

Thanks!

-- Jeremy

On Thu, Jan 13, 2011 at 6:11 AM, dbr/Ben <b...@...> wrote:
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!)
https://github.com/dbr/OpenColorIO/commit/5e7c9e16519356e738261c690ad2932b8dea910f

Other commits relate the docs, mainly the setup page:
Link to license page from FAQ
https://github.com/dbr/OpenColorIO/commit/b84e3b4ac3fb2705c04e9004333474ae0d047d28
"Building from source" page. Not totally sure this is best-practices etc,
but seem sensible and looks similar to the existing INSTALL file
https://github.com/dbr/OpenColorIO/commit/c989ad2b3f560b20c54ef511752ca222aec522af
Mention the LD_ and DYLD_LIBRARY_PATH env-vars on setup page
https://github.com/dbr/OpenColorIO/commit/ff7a47595ddb2919f0fcdf7d9d66094087a340b0
"Nuke configuration" section on setup page
https://github.com/dbr/OpenColorIO/commit/0e8bbb922136d58271866dee82b747148244db70
...and reorganise the headings for the above changes, to keep the ToC tidy
(rST's heading notation is slightly.. odd)
https://github.com/dbr/OpenColorIO/commit/ed47a03cb2b47ef86b25a60ecad8370c54810a5d
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: updated ociodisplay + ocioconvert

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

Agreed; now moved into 'apps'.

On Wed, Jan 12, 2011 at 10:06 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
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
Re: Review: Building/config related docs

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

Oh, and an observation: we now essentially have two masters for the
docs, the inline documentation, and the webpage version. My
inclination is to treat the git version as the master, and then to do
periodic html / pdf drops to the website. I'm thinking I could make
docs and post them for every dot release. Thoughts?

-- Jeremy

On Thu, Jan 13, 2011 at 10:08 AM, Jeremy Selan <jeremy...@...> wrote:
Looks good to me.
These commits were all on the same topic, so I merged them into a
single checkin, "Documentation cleanup".

Thanks!

-- Jeremy

On Thu, Jan 13, 2011 at 6:11 AM, dbr/Ben <b...@...> wrote:
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!)
https://github.com/dbr/OpenColorIO/commit/5e7c9e16519356e738261c690ad2932b8dea910f

Other commits relate the docs, mainly the setup page:
Link to license page from FAQ
https://github.com/dbr/OpenColorIO/commit/b84e3b4ac3fb2705c04e9004333474ae0d047d28
"Building from source" page. Not totally sure this is best-practices etc,
but seem sensible and looks similar to the existing INSTALL file
https://github.com/dbr/OpenColorIO/commit/c989ad2b3f560b20c54ef511752ca222aec522af
Mention the LD_ and DYLD_LIBRARY_PATH env-vars on setup page
https://github.com/dbr/OpenColorIO/commit/ff7a47595ddb2919f0fcdf7d9d66094087a340b0
"Nuke configuration" section on setup page
https://github.com/dbr/OpenColorIO/commit/0e8bbb922136d58271866dee82b747148244db70
...and reorganise the headings for the above changes, to keep the ToC tidy
(rST's heading notation is slightly.. odd)
https://github.com/dbr/OpenColorIO/commit/ed47a03cb2b47ef86b25a60ecad8370c54810a5d
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: Building/config related docs

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

Looks good to me.
These commits were all on the same topic, so I merged them into a
single checkin, "Documentation cleanup".

Thanks!

-- Jeremy

On Thu, Jan 13, 2011 at 6:11 AM, dbr/Ben <b...@...> wrote:
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!)
https://github.com/dbr/OpenColorIO/commit/5e7c9e16519356e738261c690ad2932b8dea910f

Other commits relate the docs, mainly the setup page:
Link to license page from FAQ
https://github.com/dbr/OpenColorIO/commit/b84e3b4ac3fb2705c04e9004333474ae0d047d28
"Building from source" page. Not totally sure this is best-practices etc,
but seem sensible and looks similar to the existing INSTALL file
https://github.com/dbr/OpenColorIO/commit/c989ad2b3f560b20c54ef511752ca222aec522af
Mention the LD_ and DYLD_LIBRARY_PATH env-vars on setup page
https://github.com/dbr/OpenColorIO/commit/ff7a47595ddb2919f0fcdf7d9d66094087a340b0
"Nuke configuration" section on setup page
https://github.com/dbr/OpenColorIO/commit/0e8bbb922136d58271866dee82b747148244db70
...and reorganise the headings for the above changes, to keep the ToC tidy
(rST's heading notation is slightly.. odd)
https://github.com/dbr/OpenColorIO/commit/ed47a03cb2b47ef86b25a60ecad8370c54810a5d
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
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
1901 - 1920 of 2274