Date   

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


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

1841 - 1860 of 2209