Date   

Review: Processor.getGpuShaderTextCacheID()

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

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/7ffb711edea3b4b3c4aa0ad046c15de8f70b936e

I added a call to get the cacheID for the shadertext on the processor
object. Note that querying the shadertext is an inexpensive
operation, so there arent as many benefits to deferred shadertext
calls (compared to, say, the 3dlut generation). However, for those
writing display apps it's convenient to have.

-- Jeremy


Review: DisplayTransform interface update

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

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297ed0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing
to do with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices. The
config format has been updated to reflect these modified names. Also
available are two new entries, device_defaults + alias_defaults which
allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively use
the public OCIO for all upcoming productions.

-- Jeremy


Re: Review: Replaced config->getRoleNameByIndex

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

Thanks!

I like the intent, but have two minor issues:

First, the trivial: I'd prefer to never allow NULL values as return
types from const char * functions. Please use an empty string ""
instead.

The reason being, OCIO expects the client to copy the returned string
value, if the client intends to hang onto it. So it's often convenient
in your code to do a directly assign the function result to a
std::string,

std::string rolename = config->getRoleNameByIndex(i);

If the API promises to never return a NULL value, this will work
great. However, if OCIO can return a null pointer than the above code
will crash. Thus for all char * return functions the user would be
required to explicitly add a null check. This is probably counter to
user expectations, and I expect that a few would slip through and
result in occasionally crashy client code. (This would be likely
because most of the time it *would* work fine. Only on invalid
configurations, or other corner cases, would this sharp corner be run
into. I'd like to keep OCIO as friendly as reasonable.)

(See http://github.com/imageworks/OpenColorIO/issues#issue/20 for more
thoughts on this topic).
Sure that sounds great, i'll fix that.

The second issue is that you've exposed two helper functions
(getRoleColorSpaceName), that are not quite as helpful as they appear.
Is the client supposed to use these at runtime to determine which
colorspace to use for a given role?

Allow me to answer... "No!"

:)

ConstColorSpaceRcPtr getColorSpace(const char * name) const;
already does this in the 'correct' way, and this should be the *only*
allowed mechanism for getting a ColorSpace from a name. It
encapsulates a bit of extra mojo your new function does not, such as
looking at the 'strictParsing', and if allowed returning the DEFAULT
colorspace role in fall-through situations. It also resolves the
ambiguity where a role name and colorspace name overlap, and having
this resolution only defined in a single place seems preferable.

What if we renamed your functions to make it super clear that they are
not intended for color-space resolution, but instead as configuration
setup/ui purposes?

I.e.
setRole(const char * role, const char * colorSpaceName);
const char * getRoleName(int index);
const char * getRoleValue(int index);
I don't remind removing them altogether.

I was really just adding them to match the old functionality of getRoleNameByIndex() which returned the colorspace name not the role name, I wasn't sure if you were needing the colorspace name.

Calling getColorSpace(getRoleName(0)) seems nice an clean to me.

.malcolm

Even though the role 'value' is a colorspace name, I think the
function would be far less tempting for the naive API user to
accidentally call.

If we'd like a convenience function to do the resolution, we could add
const char * getColorSpaceName(const char * name) const;

which would internally rely on config::getColorSpace.

-- Jeremy

On Sun, Jan 16, 2011 at 8:22 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
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: Replaced config->getRoleNameByIndex

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

Thanks!

I like the intent, but have two minor issues:

First, the trivial: I'd prefer to never allow NULL values as return
types from const char * functions. Please use an empty string ""
instead.

The reason being, OCIO expects the client to copy the returned string
value, if the client intends to hang onto it. So it's often convenient
in your code to do a directly assign the function result to a
std::string,

std::string rolename = config->getRoleNameByIndex(i);

If the API promises to never return a NULL value, this will work
great. However, if OCIO can return a null pointer than the above code
will crash. Thus for all char * return functions the user would be
required to explicitly add a null check. This is probably counter to
user expectations, and I expect that a few would slip through and
result in occasionally crashy client code. (This would be likely
because most of the time it *would* work fine. Only on invalid
configurations, or other corner cases, would this sharp corner be run
into. I'd like to keep OCIO as friendly as reasonable.)

(See http://github.com/imageworks/OpenColorIO/issues#issue/20 for more
thoughts on this topic).

The second issue is that you've exposed two helper functions
(getRoleColorSpaceName), that are not quite as helpful as they appear.
Is the client supposed to use these at runtime to determine which
colorspace to use for a given role?

Allow me to answer... "No!"

:)

ConstColorSpaceRcPtr getColorSpace(const char * name) const;
already does this in the 'correct' way, and this should be the *only*
allowed mechanism for getting a ColorSpace from a name. It
encapsulates a bit of extra mojo your new function does not, such as
looking at the 'strictParsing', and if allowed returning the DEFAULT
colorspace role in fall-through situations. It also resolves the
ambiguity where a role name and colorspace name overlap, and having
this resolution only defined in a single place seems preferable.

What if we renamed your functions to make it super clear that they are
not intended for color-space resolution, but instead as configuration
setup/ui purposes?

I.e.
setRole(const char * role, const char * colorSpaceName);
const char * getRoleName(int index);
const char * getRoleValue(int index);

Even though the role 'value' is a colorspace name, I think the
function would be far less tempting for the naive API user to
accidentally call.

If we'd like a convenience function to do the resolution, we could add
const char * getColorSpaceName(const char * name) const;

which would internally rely on config::getColorSpace.

-- Jeremy

On Sun, Jan 16, 2011 at 8:22 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
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: Context/per-shot grades

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

Unfortunately we dont have support yet for environment-driven
numerical parameters. It's something I'd like to add eventually, but
there are few hotter API issues I need to tackle first.

To summarize the current system...

You can reference any envvars in the specification of FilmTransform's
src parameter, either using relative or absolute paths:
Examples:
* <FileTransform>: {src: grade_$SHOT.spi1d}
* !<FileTransform>: {src: /shots/$SHOW/$SHOT/grade.spi3d}

Relative paths are resolved using the config.getSearchPath, which a
colon-delimited list of directory names. These directory are relative
or absolute (relative dirs being relative to the config's local
'working' dir), and both can also contain envvars.

The OCIO::Context is an implementation detail. Unless your application
will want to switch the values during runtime, you dont have to worry
about using the Context class. (When your application is launched,
the environment will be obeyed).

So in the meantime you'll need to write out your color correction to a
fileformat that OCIO obeys. Note that this doesnt have to be a baked
lut though. If your color correction can be represented in the
language of an ASC 'primary grade', I'd recommend just saving out the
ASC xml ColorCorrection element to its own file, and give it a .cc
extension. Or, you could put these all in a single .ccc and specify
which element to load using the envvars. This functionality isnt in
the master branch yet, I'll try to roll these into the master branch
very soon if you'd like it.

Example .cc file:
(Note that the asc does not specify a way to store a single
color-correction alone in it's own file, they only define a collection
of transforms. So i've stolen their xml syntax, put it as the root of
a document, and labelled it 'cc').

<ColorCorrection id="di_look">
<SOPNode>
<Description>
Created by jeremys at 2011-01-03 05:45pm
</Description>
<Slope>
1.000000 1.000000 1.000000
</Slope>
<Offset>
0.000000 0.000000 0.000000
</Offset>
<Power>
1.095000 1.130000 1.385000
</Power>
</SOPNode>
<SatNode>
<Saturation>
1.000000
</Saturation>
</SatNode>
</ColorCorrection>


-- Jeremy

On Sun, Jan 16, 2011 at 6:13 AM, dbr/Ben <b...@...> wrote:
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: Is the const type qualifier only in CG?

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

hmmm tried to do that last night, but something went left of field. I now have a branch thats up to date with imageworks/master but the commits are in the future.. doesn't really matter as I'm hoping to roll all the photoshop commits into one as their was a lot of unnecessary code in my initial commit.

.malcolm

On 19/01/2011, at 5:08 AM, Jeremy Selan wrote:

That's no problem at all.

FYI, this really easy to solve with the 'rebase' command. Say you
have a branch and you want to incorporate all changes on spi/master.

(I've already setup the spi remote, I am including my .git/config file
as an example. copy the 'spi' remote if you'd like).

git fetch --all (to get all branches up to date locally)
gitk --all (to visually inspect the commit tree)
git checkout photoshop (your branch name)
git rebase spi/master
If everything works, your new commits will be 'replayed' upon the
latest spi/master tree, bringing you up to date. If the rebase
doesn't work, you can always revert back with git rebase --abort.

-- Jeremy

On Mon, Jan 17, 2011 at 4:36 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Whoops, I should live by that mantra 'update or die'. I have a few
too many different checkouts of ocio, still a bit in svn land, goto to
get used to using local git branches.

This fixed this issue as well. :)

.malcolm


Re: Is the const type qualifier only in CG?

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

That's no problem at all.

FYI, this really easy to solve with the 'rebase' command. Say you
have a branch and you want to incorporate all changes on spi/master.

(I've already setup the spi remote, I am including my .git/config file
as an example. copy the 'spi' remote if you'd like).

git fetch --all (to get all branches up to date locally)
gitk --all (to visually inspect the commit tree)
git checkout photoshop (your branch name)
git rebase spi/master
If everything works, your new commits will be 'replayed' upon the
latest spi/master tree, bringing you up to date. If the rebase
doesn't work, you can always revert back with git rebase --abort.

-- Jeremy

On Mon, Jan 17, 2011 at 4:36 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Whoops, I should live by that mantra 'update or die'. I have a few
too many different checkouts of ocio, still a bit in svn land, goto to
get used to using local git branches.

This fixed this issue as well. :)

.malcolm


Re: Is the const type qualifier only in CG?

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

Whoops, I should live by that mantra 'update or die'. I have a few
too many different checkouts of ocio, still a bit in svn land, goto to
get used to using local git branches.

This fixed this issue as well. :)

.malcolm

On 18/01/2011, at 10:30 AM, Jeremy Selan wrote:

Yes, if you look att Processor.cpp : 381, you'll see that on apple
platforms we always insert a sampling of the tex2 even if it's not
needed. It appeared that without this, if the 3dlut was unused it
would be incorrectly optimized away and the app would crash.

In your shader you should see a line that looks like,
"// OSX segfault work-around: Force a no-op sampling of the 3d lut."

are you seeing this line and still having the crash? What platform are you on?

-- Jeremy

On Mon, Jan 17, 2011 at 3:27 PM, Jeremy Selan <jeremy...@...> wrote:
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?

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

Yes, if you look att Processor.cpp : 381, you'll see that on apple
platforms we always insert a sampling of the tex2 even if it's not
needed. It appeared that without this, if the 3dlut was unused it
would be incorrectly optimized away and the app would crash.

In your shader you should see a line that looks like,
"// OSX segfault work-around: Force a no-op sampling of the 3d lut."

are you seeing this line and still having the crash? What platform are you on?

-- Jeremy

On Mon, Jan 17, 2011 at 3:27 PM, Jeremy Selan <jeremy...@...> wrote:
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?

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

1861 - 1880 of 2243