1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
Re: Review: FileTransform supports .cc and .ccc files

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

LGTM

.malcolm

On 22/01/2011, at 1:29 PM, Jeremy Selan wrote:

Commits:
http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613
http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a

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

Prior Thread:
http://groups.google.com/group/ocio-dev/browse_thread/thread/61f660d1eb96121b

This adds support for loading .cc and .ccc files in the FileTransform
operator / node.
.CC files are the ASC CDL <ColorCorrection> text stored in a single file
.CCC files are the ASC CDL <ColorCorrectionCollection> group of
transforms (a well defined format).

To support the .ccc format, a new parameter on filetransform is added,
"cccid". When a .ccc file is specified, this is required to
determine which transform contained in the list is used. The new
cccid parameter supports the Context lookups (woohoo!), so one can
define it conveniently using an environment variable. This should
fully address the context/per-shot grade workflow mentioned above by
Ben.

There is one known bug in this implementation; when I exposed this new
cccid property as a String_Knob in nuke, when I update the value in
the interface it does not appear that the value is being incorporated
into the Op's hash id. Is this a limitation of Nuke? An issue with
using PixelIop(s)? I have confirmed that if I use the File_Knob UI
type, everything works as expected...

-- Jeremy
Review: Processor.getGpuShaderTextCacheID()

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

LGTM

Begin forwarded message:

From: Jeremy Selan <jeremy...@...>
Date: 22 January 2011 1:21:46 PM AEDT
To: OpenColorIO Developers <ocio...@...>
Subject: [ocio-dev] Review: Processor.getGpuShaderTextCacheID()
Reply-To: ocio...@...

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
Re: Review: DisplayTransform interface update

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

Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

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

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: FileTransform supports .cc and .ccc files

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

Nice job on the docs. By all means, check them in! (Even partial
docs are better than nothing). :)

I wonder, could the cccid's be presented in a drop-down, similar to the
colour-space listings?
I like this, but I'm not sure that there's a nuke UI widget rich
enough for this behavior. What we want is a popdown that lets you
choose from a bunch of pre-defined options, but also lets you type in
new values (such as envvars). Im not sure that nuke popdowns can
allow text entry capability. The other difficulty is that in nuke if
you use the popdowns, the underlying value is an int index rather than
a string. This sucks because if you were to update the array, change
the underlying value, etc, the only precious data for nuke is what
order it was in the list. (Whereas in our case the value is precious).
So I think it's safer to keep it a string for now. But... what if
we added a button that when pressed provided a popup for the user?
(Calling out to OCIO to enumerate the options). That would make it
convenient + keep data value 'native'.

I like the use of the invisible flag. I'll investigate setting it up.

-- Jeremy
Re: Review: FileTransform supports .cc and .ccc files

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

On 22/01/2011, at 12:59 PM, Jeremy Selan wrote:

This adds support for loading .cc and .ccc files in the FileTransform
operator / node.
.CC files are the ASC CDL <ColorCorrection> text stored in a single file
.CCC files are the ASC CDL <ColorCorrectionCollection> group of
transforms (a well defined format).

To support the .ccc format, a new parameter on filetransform is added,
"cccid".   When a .ccc file is specified, this is required to
determine which transform contained in the list is used.  The new
cccid parameter supports the Context lookups (woohoo!), so one can
define it conveniently using an environment variable.  This should
fully address the context/per-shot grade workflow mentioned above by
Ben.

This is great. Nice and intuitive \o/

!<FileTransform> {src: grades/grades.ccc, cccid: "beauty/${SEQ}/${SHOT}"}

..or, could split the grades into one file per seq and do ({src: "grades/${SEQ}_beautygrades.ccc", cccid: "${SHOT}"}) etc

..which worked pretty much exactly how I expected.

This seems like it could be a good way to (at some point) implement env-dependant transform parameters, e.g:

- !<ExponentTransform> {file: "settings_${SHOT}.yaml", key: "exponent/${SHOT}", direction: inverse}

..and

exponent:
  ab-123:
    values: [2.2, 2.2, 2,2, 1]

..but that'd be a trivial feature, as the CDL grades will more than suffice! Most of the grades I'd need to apply are in code value/printer light offsets, which map directly to the slope control, if linearising using "Josh Pines log-lin"


Started writing a "contexts" page for the docs. Does this explanation match with how you intended them to work?




There is one known bug in this implementation; when I exposed this new
cccid property as a String_Knob in nuke, when I update the value in
the interface it does not appear that the value is being incorporated
into the Op's hash id.  Is this a limitation of Nuke? An issue with
using PixelIop(s)?   I have confirmed that if I use the File_Knob UI
type, everything works as expected...

Not sure why the String_Knob would not be automatically added to the hash, but you could manually append to it by doing something like:

void NodeThingy::append(Hash& hash)
{
  hash.append(cccid);
}

I wonder, could the cccid's be presented in a drop-down, similar to the colour-space listings? Might circumvent the oddness too... Also, it'd be nice if the cccid field only appeared when loading a .ccc file (I think you just need to set the invisible flag on the knob in _validate)
Review: FileTransform supports .cc and .ccc files

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

Commits:
http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613
http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a

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

Prior Thread:
http://groups.google.com/group/ocio-dev/browse_thread/thread/61f660d1eb96121b

This adds support for loading .cc and .ccc files in the FileTransform
operator / node.
.CC files are the ASC CDL <ColorCorrection> text stored in a single file
.CCC files are the ASC CDL <ColorCorrectionCollection> group of
transforms (a well defined format).

To support the .ccc format, a new parameter on filetransform is added,
"cccid". When a .ccc file is specified, this is required to
determine which transform contained in the list is used. The new
cccid parameter supports the Context lookups (woohoo!), so one can
define it conveniently using an environment variable. This should
fully address the context/per-shot grade workflow mentioned above by
Ben.

There is one known bug in this implementation; when I exposed this new
cccid property as a String_Knob in nuke, when I update the value in
the interface it does not appear that the value is being incorporated
into the Op's hash id. Is this a limitation of Nuke? An issue with
using PixelIop(s)? I have confirmed that if I use the File_Knob UI
type, everything works as expected...

-- Jeremy
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
1821 - 1840 of 2209