Date   

Re: Review: Inital pass at searchpath impl

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

I've checked in this patch to the master branch. The code itself
looks good; whether we choose to backtrack from that API direction in
the upcoming weeks can/should be a separate issue from this particular
checkin.

-- Jeremy

On Mon, Oct 25, 2010 at 10:55 PM, Jeremy Selan <jeremy...@...> wrote:
Malcolm,

I wish I had known you were thinking about writing this particular
piece of code; I probably would have asked you to hold off on it for a
little while... (This is my mistake, I do realize that this task was
listed in the OCIO TODO file).

We've just started testing the current version of OCIO at Imageworks,
and already we've run into some major confusion regarding lut paths.
This past week's experiences (with Joseph playing the kind role of
guinea pig) illuminates this discussion, and makes me think that some
backtracking may be in order on this topic.

* An OCIO profile is not just a single configuration file in isolation
- it's a config AND a set of associated luts.  Keeping these together
all times (and conceptually thinking of them as inseparable) is
probably the only way to avoid ambiguity and errors.   An OCIO config
is not useful if it gets separated from its luts, and vice-versa.   In
fact, if it's possible to separate the two, it WILL happen, and only
bad will come of it.  It's hit us once this week, I'd like to prevent
anyone else from ever having to track down this type of issue.

* I'd like for an OCIO profile to be able to be distributed, and used,
either as a single self contained file or as a working directory.

* Consider, what would the OCIO world look like if we 'locked down' a
fixed directory layout that all profiles had to conform to?

Fixed OCIO profile (in directory form)

rootdir/
         config.txt
         filetransforms/
               a.lut, b.lut, etc.

Point $OCIO at the root directory, (not the config,txt file), and
everything "just works". All search paths, resource paths, go away.  A
bit inconvenient? Perhaps.   But unambiguous and simple?  Definitely.

* With this model, the "single file" profile + luts representation
becomes trivial:  we would just support pointing $OCIO at a compressed
version of the .ocio directory layout (zip, tgz, etc).

Want to know what's inside your .ocio.zip config?  Easy, just unzip it
using the normal os tools.  You can also unzip a profile, drag and
drop a new lut internally, and then re-zip it for distribution. Super
easy, and no lut transcoding needed.

But what would the API look like if we went with this approach?   It
would be more directory / file based, and less stream centric.
Would the "write" call write a directory instead?  (and copy all
referenced luts into a fixed local lut dir?) Probably.

As foreign as this idea sounds, putting the OCIO configuration on
rails and locking down a fixed directory layout may really help to
minimize errors and confusion going forward.

On a slighly different topic, I think it will be preferable when
possible to minimize the use of envvars. Consider the case where the
'global config' (created with $OCIO) is not used. (where config
objects are instead manually initialized). Any options specified with
envvars, such as search paths, will by definition be 'global' and will
have to be worked around (unset) in the the other profiles.

-- Jeremy


---------- Forwarded message ----------
From: Malcolm Humphreys <malcolmh...@...>
Date: Mon, Oct 25, 2010 at 3:29 AM
Subject: Re: [ocio-dev] Review: Inital pass at searchpath impl
To: ocio...@...


- fixed a bug with abs searchpath entries
- empty '::' searchpaths now resolve to the profile cwd

http://github.com/malcolmhumphreys/OpenColorIO/commit/5d922362259e86073592481d428926de1054414d

.malcolm

On 25/10/2010, at 6:59 PM, Malcolm Humphreys wrote:

- removed the EnvExpand recusion limits as this didn't work in the production env which
has more than 30 env vars. might want to add limits in later if this becomes a problem.

http://github.com/malcolmhumphreys/OpenColorIO/commit/a172426e59ddebc4ccd0691b796bfe493677ec9f

.malcolm

On 25/10/2010, at 6:17 PM, Malcolm Humphreys wrote:

Inital pass at searchpath impl
- added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand())
- added FileExists() function to PathUtils.h
- added searchpath functionality into Config:: class (setSearchPath(path), getSearchPath(expand), findFile(filename)) this hasn't be plugged into anything yet.
- added ocio_core_tests.sh.in so we can pass in some env vars for the unit tests

http://github.com/malcolmhumphreys/OpenColorIO/commit/80bfd194bd7fd3d787e7a8795ad63be6050702c6

.malcolm


Re: Review: Inital pass at searchpath impl

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

Malcolm,

I wish I had known you were thinking about writing this particular
piece of code; I probably would have asked you to hold off on it for a
little while... (This is my mistake, I do realize that this task was
listed in the OCIO TODO file).

We've just started testing the current version of OCIO at Imageworks,
and already we've run into some major confusion regarding lut paths.
This past week's experiences (with Joseph playing the kind role of
guinea pig) illuminates this discussion, and makes me think that some
backtracking may be in order on this topic.

* An OCIO profile is not just a single configuration file in isolation
- it's a config AND a set of associated luts. Keeping these together
all times (and conceptually thinking of them as inseparable) is
probably the only way to avoid ambiguity and errors. An OCIO config
is not useful if it gets separated from its luts, and vice-versa. In
fact, if it's possible to separate the two, it WILL happen, and only
bad will come of it. It's hit us once this week, I'd like to prevent
anyone else from ever having to track down this type of issue.

* I'd like for an OCIO profile to be able to be distributed, and used,
either as a single self contained file or as a working directory.

* Consider, what would the OCIO world look like if we 'locked down' a
fixed directory layout that all profiles had to conform to?

Fixed OCIO profile (in directory form)

rootdir/
config.txt
filetransforms/
a.lut, b.lut, etc.

Point $OCIO at the root directory, (not the config,txt file), and
everything "just works". All search paths, resource paths, go away. A
bit inconvenient? Perhaps. But unambiguous and simple? Definitely.

* With this model, the "single file" profile + luts representation
becomes trivial: we would just support pointing $OCIO at a compressed
version of the .ocio directory layout (zip, tgz, etc).

Want to know what's inside your .ocio.zip config? Easy, just unzip it
using the normal os tools. You can also unzip a profile, drag and
drop a new lut internally, and then re-zip it for distribution. Super
easy, and no lut transcoding needed.

But what would the API look like if we went with this approach? It
would be more directory / file based, and less stream centric.
Would the "write" call write a directory instead? (and copy all
referenced luts into a fixed local lut dir?) Probably.

As foreign as this idea sounds, putting the OCIO configuration on
rails and locking down a fixed directory layout may really help to
minimize errors and confusion going forward.

On a slighly different topic, I think it will be preferable when
possible to minimize the use of envvars. Consider the case where the
'global config' (created with $OCIO) is not used. (where config
objects are instead manually initialized). Any options specified with
envvars, such as search paths, will by definition be 'global' and will
have to be worked around (unset) in the the other profiles.

-- Jeremy


---------- Forwarded message ----------
From: Malcolm Humphreys <malcolmh...@...>
Date: Mon, Oct 25, 2010 at 3:29 AM
Subject: Re: [ocio-dev] Review: Inital pass at searchpath impl
To: ocio...@...


- fixed a bug with abs searchpath entries
- empty '::' searchpaths now resolve to the profile cwd

http://github.com/malcolmhumphreys/OpenColorIO/commit/5d922362259e86073592481d428926de1054414d

.malcolm

On 25/10/2010, at 6:59 PM, Malcolm Humphreys wrote:

- removed the EnvExpand recusion limits as this didn't work in the production env which
has more than 30 env vars. might want to add limits in later if this becomes a problem.

http://github.com/malcolmhumphreys/OpenColorIO/commit/a172426e59ddebc4ccd0691b796bfe493677ec9f

.malcolm

On 25/10/2010, at 6:17 PM, Malcolm Humphreys wrote:

Inital pass at searchpath impl
- added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand())
- added FileExists() function to PathUtils.h
- added searchpath functionality into Config:: class (setSearchPath(path), getSearchPath(expand), findFile(filename)) this hasn't be plugged into anything yet.
- added ocio_core_tests.sh.in so we can pass in some env vars for the unit tests

http://github.com/malcolmhumphreys/OpenColorIO/commit/80bfd194bd7fd3d787e7a8795ad63be6050702c6

.malcolm


Re: Reference !<Colorspace>

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

I'm not sure what promoting the reference colorspace to something
special - either in the API or the format - buys us. Can you provide
details on how this would make things simpler (or any other benefits
you see)?

Coming clean, I have to admit that in our internal SPI Color library
(the predecessor to OCIO) we actually never exposed a function call to
query the name of the reference colorspace in 7 years of use. There
was always a call to query scene linear, but the fact that this also
happened to be the internal profile connection space was never
relevant to end users.

My thought in adding it to OCIO was for completeness sake when
spec'ing out the ROLE listings, but until it has an obvious use case
perhaps we should remove ROLE_REFERENCE? It can always be added back
in, when needed. (This is probably the API corollary to premature
optimization, where you speculatively add a feature that only adds to
confusion and in practice is never used).

I do believe that understanding what a particular color configuration
uses as its connection space is critical, but in my opinion this is
best solved textually at a configuration level (i.e. config docs).

Thoughts?

In terms of your specific suggestions, I think I would prefer to have
the reference color space just be another colorspace, with no
particular distinction. While it doesn't have a transform block, it
does have all the other colorspace markup, so it really does feel
'colorspace-like'. I could also foresee a situation where someone was
using the connection space implicitly, and it wasn't intended to be
either named or used by the end user. (We havent done this, but I see
no reason to disallow it).

Addressing the extra nesting added to your .ocio transform block, your
version doesn't strike me as any more readable.
old: to_reference.children
new: to.reference.children

Isn't redundant nesting bad?

Perhaps there is a better name for the "to_reference" and
"from_reference" values? I'm totally open to revising that enum name.

-- Jeremy


Re: Review: added new yaml-cpp with YAML::Newline feature

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

Thanks,

LGTM

On Mon, Oct 25, 2010 at 3:05 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
On 26/10/2010, at 5:14 AM, Jeremy Selan wrote:

Is there a reason to not remove yaml-cpp-0.2.5* from ext?
No reason was just waiting to get the tick of approval, this is now removed.
http://github.com/malcolmhumphreys/OpenColorIO/commit/26aa9bfc1baa74796b355de0b2ec476960b1b481

.malcolm


Other than that, looks good to me.

-- Jeremy

On Mon, Oct 25, 2010 at 5:22 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
- added yaml-cpp r443 which contains the new YAML::Newline emitter manipulator
http://stackoverflow.com/questions/3982901/how-to-emit-a-blank-line-using-yaml-cpp
- added some 'out << YAML::Newline' to tryout this feature

http://github.com/malcolmhumphreys/OpenColorIO/commit/0de8ccb6842b223f942789f1ae68d768dab9de29

.malcolm


Re: Review: converted configs/testing/config.ocio to YAML

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

Looks good to me. I'll commit this after I finish working through the
search path checkins (tomorrow, hopefully).

-- Jeremy

On Mon, Oct 25, 2010 at 3:00 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
- converted configs/testing/config.ocio to YAML
- added OpenColorIOTest to the ctest run ie 'make test & make test_verbose'
- some test output was being written to /mcp changed this to /tmp for now

http://github.com/malcolmhumphreys/OpenColorIO/commit/c8000fa44fbc4fa62feeebb2f505c115883dad6d

.malcolm


Re: Reference !<Colorspace>

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


I don't see that the reference space should be separate in the profile. It's important, but it is just a role.
 
Is it just a role? seems like each colorspace needs it to convert between each other. Roles main purpose is to have abstract names / pointers for colorspaces. The reference space could also be a role but it is also a little more special and required field for a vaild profile where I see roles as a optional workflow UI feature.

Where the reference sits in the xml or yaml should matter much. Although quite a bit of effort is going into making the configuration files readable one of the goals of ocio, so I thought, was to not manually edit these files. I would imagine that there will be binary versions of configurations files not long after luts can be fully embedded.
 
The ascii versions should still be legible.

I was hoping to take a look at creating something which would take a ocio profile and create an embedded version. The basic idea would be to create a section at the bottom of the profile with all the luts / files that are contained in some !!binary tags. We could either update the src="foo" in the !<FileTransform> to references these embedded files or adapt the search path mechanism.

It would be nice to get some ideas on how you envisioned this stuff working, before I get carried away.

As a personal implementation preference I would only want to implement the definition of the reference as a pointer to another colorspace.
 
I think that is fine idea, what about something like.

--snip--
ocio_profile_version: 1
resource_path: luts
strictparsing: false
luma: [0.2126, 0.7152, 0.0722]
reference: lnh
roles:
  scene_linear: lnh
  compositing_log: lgh
colorspaces:
  - !<ColorSpace>
    name: lnh
...
  - !<ColorSpace>
    name: lgh
..
    to_reference: !<FileTransform> {src: lgf.spi1d, interpolation: linear}
--snip--

.malcolm



Just my 2 cents.

-Joseph



________________________________________
From: ocio...@... [ocio...@...] On Behalf Of Malcolm Humphreys [malcolmh...@...]
Sent: Monday, October 25, 2010 5:48 AM
To: OpenColorIO Developers
Subject: [ocio-dev] Reference !<Colorspace>

Do you think the 'reference' colorspace should in a separate section in the profile? This would be similar to the PCS in the icc world. It could be an extra line 'reference: !<ColorSpace> ..' before the colorspaces in the profile. The 'reference' name could be reserved so that colorspace -> reference transforms could work the same.

I can see this working as roles with ROLE_REFERENCE but it really feels like a more central OCIO concept than roles and should be separated.

Also looking at the serialization with to_referance and from_referance, I'm thinking it would be easy to read if it was structured like this? what do you think?

--from--
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from_reference: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--from--

--to--
reference:
to: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--to--

.malcolm




Re: Reference !<Colorspace>

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

Malcolm,

I don't see that the reference space should be separate in the profile. It's important, but it is just a role. Where the reference sits in the xml or yaml should matter much. Although quite a bit of effort is going into making the configuration files readable one of the goals of ocio, so I thought, was to not manually edit these files. I would imagine that there will be binary versions of configurations files not long after luts can be fully embedded.

As a personal implementation preference I would only want to implement the definition of the reference as a pointer to another colorspace.

Just my 2 cents.

-Joseph



________________________________________
From: ocio...@... [ocio...@...] On Behalf Of Malcolm Humphreys [malcolmh...@...]
Sent: Monday, October 25, 2010 5:48 AM
To: OpenColorIO Developers
Subject: [ocio-dev] Reference !<Colorspace>

Do you think the 'reference' colorspace should in a separate section in the profile? This would be similar to the PCS in the icc world. It could be an extra line 'reference: !<ColorSpace> ...' before the colorspaces in the profile. The 'reference' name could be reserved so that colorspace -> reference transforms could work the same.

I can see this working as roles with ROLE_REFERENCE but it really feels like a more central OCIO concept than roles and should be separated.

Also looking at the serialization with to_referance and from_referance, I'm thinking it would be easy to read if it was structured like this? what do you think?

--from--
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from_reference: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--from--

--to--
reference:
to: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--to--

.malcolm


Re: Review: added new yaml-cpp with YAML::Newline feature

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

On 26/10/2010, at 5:14 AM, Jeremy Selan wrote:

Is there a reason to not remove yaml-cpp-0.2.5* from ext?
No reason was just waiting to get the tick of approval, this is now removed.
http://github.com/malcolmhumphreys/OpenColorIO/commit/26aa9bfc1baa74796b355de0b2ec476960b1b481

.malcolm


Other than that, looks good to me.

-- Jeremy

On Mon, Oct 25, 2010 at 5:22 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
- added yaml-cpp r443 which contains the new YAML::Newline emitter manipulator
http://stackoverflow.com/questions/3982901/how-to-emit-a-blank-line-using-yaml-cpp
- added some 'out << YAML::Newline' to tryout this feature

http://github.com/malcolmhumphreys/OpenColorIO/commit/0de8ccb6842b223f942789f1ae68d768dab9de29

.malcolm


Review: converted configs/testing/config.ocio to YAML

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

- converted configs/testing/config.ocio to YAML
- added OpenColorIOTest to the ctest run ie 'make test & make test_verbose'
- some test output was being written to /mcp changed this to /tmp for now

http://github.com/malcolmhumphreys/OpenColorIO/commit/c8000fa44fbc4fa62feeebb2f505c115883dad6d

.malcolm


Re: Review: added new yaml-cpp with YAML::Newline feature

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

Is there a reason to not remove yaml-cpp-0.2.5* from ext?

Other than that, looks good to me.

-- Jeremy

On Mon, Oct 25, 2010 at 5:22 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
- added yaml-cpp r443 which contains the new YAML::Newline emitter manipulator
http://stackoverflow.com/questions/3982901/how-to-emit-a-blank-line-using-yaml-cpp
- added some 'out << YAML::Newline' to tryout this feature

http://github.com/malcolmhumphreys/OpenColorIO/commit/0de8ccb6842b223f942789f1ae68d768dab9de29

.malcolm


Re: Review: Inital pass at GCC visibility

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

Looks good to me.
(I tested this, as well as all the related post-email updates).

-- Jeremy

On Thu, Oct 21, 2010 at 1:44 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
- Inital pass at GCC visibility http://gcc.gnu.org/wiki/Visibility
 to hide unnecessary public symbols in an effort to maintain ABI
- Added -fvisibility-inlines-hidden and -fvisibility=hidden to the yaml-cpp patch, YAML::* symbols should now be hidden in libOpenColorIO.so
- Added export/OpenColorIO/OpenColorABI.h
- Added some '#pragma GCC visibility' for some external libs

Before Visibility:
:nm -C -D src/core/libOpenColorIO.so | grep " T " | wc -l
958

After Visibility:
:nm -C -D src/core/libOpenColorIO.so | grep " T " | wc -l
306

http://github.com/malcolmhumphreys/OpenColorIO/commit/aa888b4d4f969e6c903eb73d7c20a9d9f546298f
http://github.com/malcolmhumphreys/OpenColorIO/commit/08b4208717221426ba90058b6324e3358930d376
http://github.com/malcolmhumphreys/OpenColorIO/commit/3ec1be5204291aaf40e56cdbdb1c7c0f757664eb

.malcolm


Reference !<Colorspace>

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

Do you think the 'reference' colorspace should in a separate section in the profile? This would be similar to the PCS in the icc world. It could be an extra line 'reference: !<ColorSpace> ...' before the colorspaces in the profile. The 'reference' name could be reserved so that colorspace -> reference transforms could work the same.

I can see this working as roles with ROLE_REFERENCE but it really feels like a more central OCIO concept than roles and should be separated.

Also looking at the serialization with to_referance and from_referance, I'm thinking it would be easy to read if it was structured like this? what do you think?

--from--
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from_reference: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--from--

--to--
reference:
to: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--to--

.malcolm


Review: added new yaml-cpp with YAML::Newline feature

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

- added yaml-cpp r443 which contains the new YAML::Newline emitter manipulator
http://stackoverflow.com/questions/3982901/how-to-emit-a-blank-line-using-yaml-cpp
- added some 'out << YAML::Newline' to tryout this feature

http://github.com/malcolmhumphreys/OpenColorIO/commit/0de8ccb6842b223f942789f1ae68d768dab9de29

.malcolm


Re: Review: Inital pass at searchpath impl

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

- fixed a bug with abs searchpath entries
- empty '::' searchpaths now resolve to the profile cwd

http://github.com/malcolmhumphreys/OpenColorIO/commit/5d922362259e86073592481d428926de1054414d

.malcolm

On 25/10/2010, at 6:59 PM, Malcolm Humphreys wrote:

- removed the EnvExpand recusion limits as this didn't work in the production env which
has more than 30 env vars. might want to add limits in later if this becomes a problem.

http://github.com/malcolmhumphreys/OpenColorIO/commit/a172426e59ddebc4ccd0691b796bfe493677ec9f

.malcolm

On 25/10/2010, at 6:17 PM, Malcolm Humphreys wrote:

Inital pass at searchpath impl
- added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand())
- added FileExists() function to PathUtils.h
- added searchpath functionality into Config:: class (setSearchPath(path), getSearchPath(expand), findFile(filename)) this hasn't be plugged into anything yet.
- added ocio_core_tests.sh.in so we can pass in some env vars for the unit tests

http://github.com/malcolmhumphreys/OpenColorIO/commit/80bfd194bd7fd3d787e7a8795ad63be6050702c6

.malcolm


Re: Review: Inital pass at searchpath impl

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

- removed the EnvExpand recusion limits as this didn't work in the production env which
has more than 30 env vars. might want to add limits in later if this becomes a problem.

http://github.com/malcolmhumphreys/OpenColorIO/commit/a172426e59ddebc4ccd0691b796bfe493677ec9f

.malcolm

On 25/10/2010, at 6:17 PM, Malcolm Humphreys wrote:

Inital pass at searchpath impl
- added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand())
- added FileExists() function to PathUtils.h
- added searchpath functionality into Config:: class (setSearchPath(path), getSearchPath(expand), findFile(filename)) this hasn't be plugged into anything yet.
- added ocio_core_tests.sh.in so we can pass in some env vars for the unit tests

http://github.com/malcolmhumphreys/OpenColorIO/commit/80bfd194bd7fd3d787e7a8795ad63be6050702c6

.malcolm


Review: Inital pass at searchpath impl

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

Inital pass at searchpath impl
- added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand())
- added FileExists() function to PathUtils.h
- added searchpath functionality into Config:: class (setSearchPath(path), getSearchPath(expand), findFile(filename)) this hasn't be plugged into anything yet.
- added ocio_core_tests.sh.in so we can pass in some env vars for the unit tests

http://github.com/malcolmhumphreys/OpenColorIO/commit/80bfd194bd7fd3d787e7a8795ad63be6050702c6

.malcolm


Review: fix the gcc visibility on linux

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

- removed some #pragma's which were breaking the build on linux,
there are a few more warnings now to do with template<> visibility
in yaml-cpp but it should now link on linux (was working on OSX)
http://github.com/malcolmhumphreys/OpenColorIO/commit/378d9fb3729255bd665f216ef68a487657bd666d

.malcolm


Review: Inital pass at GCC visibility

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

- Inital pass at GCC visibility http://gcc.gnu.org/wiki/Visibility
to hide unnecessary public symbols in an effort to maintain ABI
- Added -fvisibility-inlines-hidden and -fvisibility=hidden to the yaml-cpp patch, YAML::* symbols should now be hidden in libOpenColorIO.so
- Added export/OpenColorIO/OpenColorABI.h
- Added some '#pragma GCC visibility' for some external libs

Before Visibility:
:nm -C -D src/core/libOpenColorIO.so | grep " T " | wc -l
958

After Visibility:
:nm -C -D src/core/libOpenColorIO.so | grep " T " | wc -l
306

http://github.com/malcolmhumphreys/OpenColorIO/commit/aa888b4d4f969e6c903eb73d7c20a9d9f546298f
http://github.com/malcolmhumphreys/OpenColorIO/commit/08b4208717221426ba90058b6324e3358930d376
http://github.com/malcolmhumphreys/OpenColorIO/commit/3ec1be5204291aaf40e56cdbdb1c7c0f757664eb

.malcolm


Re: Review: Misc Yaml Updates

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

- Can we call AddBaseTransformPropertiesToYAMLMap = EmitBaseTransformKeyValues
- Can we call ReadBaseTransformPropertiesFromYAMLMap = ReadBaseTransformKeyValues, and can the argument order be swaped to match the other >> operators ie. (TransformRcPtr & t, const YAML::Node & node) -> (const YAML::Node & node, TransformRcPtr &)
Done.
-- jeremy


OCIO 0.7.0 posted

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

The first release based on YAML is now ready for download. Thanks to
Malcolm for his help on this.

An updated set of 0.7-format color configs (with many more color
spaces!) will be posted tomorrow.

Version 0.7.0 (Oct 21 2010):
* Switched file format from XML to Yaml

-- Jeremy

2001 - 2020 of 2209