Date   

Review: Updated ocio2icc

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

https://github.com/imageworks/OpenColorIO/pull/163

Added support for --lut command-line argument. Instead of requiring an
ocio profile, users can specify a lut (or a chain of luts) to create
an icc profile.

Example:

ocio2icc --lut filmlut.3dl --lut calibration.3dl
~/Library/ColorSync/Profiles/test.icc

This is in response to the Soles email to ocio-dev, "Can I Create An
ICC Profile From An Existing 3dl/csp LUT?".

-- Jeremy


Re: FileTransform interface changes

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

Would FileTransform::setOptionString(...) introduce the same complexity?

Say you wanted to create the OCIOFileTransform in nuke. In this
system, would you expect to see a single knob, 'optionString', or
multiple knobs (cccid, etc)? If a single knob is exposed, how would
the user know what to set? Would we just provide helptext which
documented the options?

What would the string format be? JSON/YAML?

What keys would be supported in 1.0? shaper interpolation + cccid?
How about normal interpolation?

-- Jeremy

On Fri, Sep 16, 2011 at 2:40 AM, Malcolm Humphreys
<malcolmh...@...> wrote:

Could we find a halfway point?
FileTransform::getOptionString()
FileTransform::setOptionString(const char * id)

This could take a 'token1=value1;token2=value2' string. This is a bit ugly
but does allow for the interface to be not so format specific while also
allowing to add other options if they are needed for fixing bugs on the path
to 2.0.

eg.
FileTransform::setOptionString("CCCId=myfavshot;");


Re: FileTransform interface changes

Kai-Uwe Behrmann <ku...@...>
 

Am 15.09.11, 17:50 -0700 schrieb Jeremy Selan:
*everywhere*? For example, at SPI we have a vm with an old libstdc++
for compatibility testing. Core OCIO builds fine on this machine, but
littlecms has linking issues. (below).

[ 48%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/Transform.cpp.o
.libs/cmserr.o: In function `feof_unlocked':
/usr/include/bits/stdio.h:123: multiple definition of `feof_unlocked'
.libs/cmscnvrt.o:/usr/include/bits/stdio.h:123: first defined here
.libs/cmserr.o: In function `ferror_unlocked':
That looks like cmake output. But littleCMS (alias lcms) uses autotools and is written in C not C++. Did you check with lcms' native build system?
Btw. the functions above are not present inside lcms' code. Usually lcms runs on a wide scale of systems, from embedded to many flawours of desktop systems. I would be astonished if there where unresolvable or even hard portability problems.

kind regards
Kai-Uwe Behrmann
--
developing for colour management www.behrmann.name + www.oyranos.org


Re: FileTransform interface changes

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


But considering that commercial apps are chomping at the bit to
release OCIO 1.0 binaries, and that we've promised an absolutely ready
to ship '1.0' just 2 weeks from now, I think it's too late in the game
to be considering non-trivial API changes. <tear/> Would you
concur? My gut tells me this is too much API design work to flesh out
in too short a time.
 
I leave it up to you to decide what makes it into 1.0. At the end of the day I would just be happy to somehow replace these:

FileTransform::getCCCId()
FileTransform::setCCCId(const char * id)

But I think for 2.0 a full blown solution would be a great addition.

Could we find a halfway point?
FileTransform::getOptionString()
FileTransform::setOptionString(const char * id)

This could take a 'token1=value1;token2=value2' string. This is a bit ugly but does allow for the interface to be not so format specific while also allowing to add other options if they are needed for fixing bugs on the path to 2.0.

eg.
FileTransform::setOptionString("CCCId=myfavshot;");

Of course I'm very open to considering such a change as a part of a
1.2 or 2.0 API. (As it wouldnt change the .ocio format, 1.2 is
possible). To do this issue 'right' we'd potentially want to give the
same treatment to all transform types, not just FileTransform. (As a
side effect all the static typed transforms would evaporate into a
single Transform with getType() !) See this #issue (from last week)
where we spec'd out some of the details.
https://github.com/imageworks/OpenColorIO/issues/155
 
 
I think that is a great idea and should be 2.0 as it's a big interface change. I like it even more after trying to wrap all the transforms types which is a hell of lot of boilerplate code.. (grumble)

So if you'd concur, let's go ahead and just add set/get
ShaperInterpolation in the meantime? What's the use case for
hasShaper? Is that for interface visibility?
 
yep just for the ui.

In terms of ICCTransform support, I have mixed feelings. First off, I
totally understand the use case, and I'm completely committed to
solving that workflow with OCIO's 'ecosystem'.
 
I would hope this would be just a straight FileTransform rather than a separate *Transform.

So do essentially would have to *require* core littlecms / icc support
to consider it. Are we willing to make that jump at this point? Is
OCIO's ICCTransfrom ready to ship? (and be locked down?).
https://github.com/imageworks/OpenColorIO/pull/87
 
 
I was more thinking of being able to add it in a 1.xx minor version rather than it being ready for 1.0.

I think my preference would be in the medium term, to add an OCIO API
where transforms such as ICC / Truelight / CTL could be built
externally - as needed - without introducing the build-time
dependency. Supporting apps wouldnt need to ship with these optional
plugins - the uses would compile them as required.
 
Well I'm all for that as it's originally what I suggested :) it would be good if this API also extended to adding additional file formats.
I would hope the long term goal would be to roll new formats into the core but this would allow adding/modifying existing support.

In the meantime, a compromise (suitable for 1.0.0) could be to add an
additional external app (or part of ocio2icc?) that handles the
functionality of ICCTransform, and bakes the result into a 3dlut
suitable for OCIO. That way folks who rely on ICC calibration would
have a command to generate the needed 3d display luts - it just would
happen as a preprocess, and not at runtime.
 
Sure, you kind can do that now as Ben has just posted so it's not really a big issue for 1.0 for me.

.malcolm

On Wed, Sep 14, 2011 at 7:00 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
> Hi,
> As we are fast approaching 1.0 I know it's a bit late in the day for some
> API changes. But I noticed these while doing the JNI wrapping for the
> android port some things which would be really good to change before 1.0.
> Could we add the following to control the interpolation of the shaper lut
> Interpolation FileTransform::getShaperInterpolation() const;
> void FileTransform::setShaperInterpolation(Interpolation interp);
> bool FileTransform::hasShaper();
> Also these seem a bit smelly and very format specific in the current
> interface.
> FileTransform::getCCCId();
> FileTransform::setCCCId(const char * id);
> Could this be replaced with some kind of key, type, value interface.
> Maybe along the lines of (I would think the order of vars/parameters would
> be important for ui's which is why it's all index based):
> int FileTransform::getNumVars();
> VarType FileTransform::getVarType(int index);
> const char * FileTransform::getVarName(int index);
> int FileTransform::getVarIndex(const char * name);
> void FileTransform::setStringVar(int index, const char * value);
> const char * FileTransform::getStringVar(int index);
> void FileTransform::setFloatVar(int index, float value);
> float FileTransform::getFloatVar(int index);
> enum VarType
> {
>         VAR_TYPE_NONE = 0,
>         VAR_TYPE_STRING = 1,
>         VAR_TYPE_FLOAT = 2
> };
> eg.
> --snip--
> int index = ptr->getVarIndex("CCCId");
> if(ptr->getVarType(index) == VAR_TYPE_STRING)
> ptr->setStringVar(, "MYSHOTCCC");
> --snip--
> This would allow me to move the ICCTransfrom code into a FileTransform impl
> which would be nice.
> If your down with the idea I'm happy to whip something up when I have
> sometime after work.
> .malcolm
>


Re: FileTransform interface changes

Andrew Hunter <and...@...>
 

Hey Jeremy,

On Thu, Sep 15, 2011 at 8:50 PM, Jeremy Selan <jeremy...@...> wrote:
[...]
In the meantime, a compromise (suitable for 1.0.0) could be to add an
additional external app (or part of ocio2icc?) that handles the
functionality of ICCTransform, and bakes the result into a 3dlut
suitable for OCIO.  That way folks who rely on ICC calibration would
have a command to generate the needed 3d display luts - it just would
happen as a preprocess, and not at runtime.
This would be absolutely suitable for my workflow. It would be ideal
to be able to support ICC characterization directly in ocio but that
can wait until it's ready if there exists a means for me to get the
characterization of my display into an ocio supporting app.

[...]

Cheers,

Andrew


Re: FileTransform interface changes

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

Malcolm,

Sorry for the delay in responding.

First, I agree with you that dynamically defined FileTransform options
would have more elegant. (prman is a great example of how such an API
can stay awesomely forwards compatible even decades later).

But considering that commercial apps are chomping at the bit to
release OCIO 1.0 binaries, and that we've promised an absolutely ready
to ship '1.0' just 2 weeks from now, I think it's too late in the game
to be considering non-trivial API changes. <tear/> Would you
concur? My gut tells me this is too much API design work to flesh out
in too short a time.

Of course I'm very open to considering such a change as a part of a
1.2 or 2.0 API. (As it wouldnt change the .ocio format, 1.2 is
possible). To do this issue 'right' we'd potentially want to give the
same treatment to all transform types, not just FileTransform. (As a
side effect all the static typed transforms would evaporate into a
single Transform with getType() !) See this #issue (from last week)
where we spec'd out some of the details.
https://github.com/imageworks/OpenColorIO/issues/155

So if you'd concur, let's go ahead and just add set/get
ShaperInterpolation in the meantime? What's the use case for
hasShaper? Is that for interface visibility?


In terms of ICCTransform support, I have mixed feelings. First off, I
totally understand the use case, and I'm completely committed to
solving that workflow with OCIO's 'ecosystem'.

But in terms of adding it ICCTransfrom to the core library, I have a
concern. How confident are we that littlecms can be build
*everywhere*? For example, at SPI we have a vm with an old libstdc++
for compatibility testing. Core OCIO builds fine on this machine, but
littlecms has linking issues. (below).

[ 48%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/Transform.cpp.o
.libs/cmserr.o: In function `feof_unlocked':
/usr/include/bits/stdio.h:123: multiple definition of `feof_unlocked'
.libs/cmscnvrt.o:/usr/include/bits/stdio.h:123: first defined here
.libs/cmserr.o: In function `ferror_unlocked':

This particular error may be trivial to solve (I didnt even try), but
I wonder if adding littlecms to the core library may adversely impact
portability?

And making ICCTransform optional for core OCIO is a path I dont want
to go down. One of the best parts of OCIO is portability between apps,
and If we make an ICC transform optional at build time, OCIO will
become fractured into apps that support .icc, and those that don't.
What if you need .icc support, but one of the OCIO apps has chosen to
not build with support for it? If .icc profile support isnt
required, they're essentially useless. (The same argument applies
to Truelight, by the way).

So do essentially would have to *require* core littlecms / icc support
to consider it. Are we willing to make that jump at this point? Is
OCIO's ICCTransfrom ready to ship? (and be locked down?).
https://github.com/imageworks/OpenColorIO/pull/87

I think my preference would be in the medium term, to add an OCIO API
where transforms such as ICC / Truelight / CTL could be built
externally - as needed - without introducing the build-time
dependency. Supporting apps wouldnt need to ship with these optional
plugins - the uses would compile them as required.

In the meantime, a compromise (suitable for 1.0.0) could be to add an
additional external app (or part of ocio2icc?) that handles the
functionality of ICCTransform, and bakes the result into a 3dlut
suitable for OCIO. That way folks who rely on ICC calibration would
have a command to generate the needed 3d display luts - it just would
happen as a preprocess, and not at runtime.

Thoughts?

-- Jeremy



On Wed, Sep 14, 2011 at 7:00 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,
As we are fast approaching 1.0 I know it's a bit late in the day for some
API changes. But I noticed these while doing the JNI wrapping for the
android port some things which would be really good to change before 1.0.
Could we add the following to control the interpolation of the shaper lut
Interpolation FileTransform::getShaperInterpolation() const;
void FileTransform::setShaperInterpolation(Interpolation interp);
bool FileTransform::hasShaper();
Also these seem a bit smelly and very format specific in the current
interface.
FileTransform::getCCCId();
FileTransform::setCCCId(const char * id);
Could this be replaced with some kind of key, type, value interface.
Maybe along the lines of (I would think the order of vars/parameters would
be important for ui's which is why it's all index based):
int FileTransform::getNumVars();
VarType FileTransform::getVarType(int index);
const char * FileTransform::getVarName(int index);
int FileTransform::getVarIndex(const char * name);
void FileTransform::setStringVar(int index, const char * value);
const char * FileTransform::getStringVar(int index);
void FileTransform::setFloatVar(int index, float value);
float FileTransform::getFloatVar(int index);
enum VarType
{
        VAR_TYPE_NONE = 0,
        VAR_TYPE_STRING = 1,
        VAR_TYPE_FLOAT = 2
};
eg.
--snip--
int index = ptr->getVarIndex("CCCId");
if(ptr->getVarType(index) == VAR_TYPE_STRING)
ptr->setStringVar(, "MYSHOTCCC");
--snip--
This would allow me to move the ICCTransfrom code into a FileTransform impl
which would be nice.
If your down with the idea I'm happy to whip something up when I have
sometime after work.
.malcolm


Re: FileTransform interface changes

Andrew Hunter <and...@...>
 

Hey,

Just giving my two cents but having ocio support icc transforms would be a killer feature. Would this be too invasive a change to make it into 1.0?

Cheers,

Andrew

On Sep 14, 2011 10:04 AM, "Malcolm Humphreys" <malcolmh...@...> wrote:
> Hi,
>
> As we are fast approaching 1.0 I know it's a bit late in the day for some API changes. But I noticed these while doing the JNI wrapping for the android port some things which would be really good to change before 1.0.
>
> Could we add the following to control the interpolation of the shaper lut
>
> Interpolation FileTransform::getShaperInterpolation() const;
> void FileTransform::setShaperInterpolation(Interpolation interp);
> bool FileTransform::hasShaper();
>
> Also these seem a bit smelly and very format specific in the current interface.
>
> FileTransform::getCCCId();
> FileTransform::setCCCId(const char * id);
>
> Could this be replaced with some kind of key, type, value interface.
>
> Maybe along the lines of (I would think the order of vars/parameters would be important for ui's which is why it's all index based):
>
> int FileTransform::getNumVars();
> VarType FileTransform::getVarType(int index);
> const char * FileTransform::getVarName(int index);
> int FileTransform::getVarIndex(const char * name);
>
> void FileTransform::setStringVar(int index, const char * value);
> const char * FileTransform::getStringVar(int index);
>
> void FileTransform::setFloatVar(int index, float value);
> float FileTransform::getFloatVar(int index);
>
> enum VarType
> {
> VAR_TYPE_NONE = 0,
> VAR_TYPE_STRING = 1,
> VAR_TYPE_FLOAT = 2
> };
>
> eg.
> --snip--
> int index = ptr->getVarIndex("CCCId");
> if(ptr->getVarType(index) == VAR_TYPE_STRING)
> ptr->setStringVar(, "MYSHOTCCC");
> --snip--
>
> This would allow me to move the ICCTransfrom code into a FileTransform impl which would be nice.
>
> If your down with the idea I'm happy to whip something up when I have sometime after work.
>
> .malcolm
>


FileTransform interface changes

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

Hi,

As we are fast approaching 1.0 I know it's a bit late in the day for some API changes. But I noticed these while doing the JNI wrapping for the android port some things which would be really good to change before 1.0.

Could we add the following to control the interpolation of the shaper lut

Interpolation FileTransform::getShaperInterpolation() const;
void FileTransform::setShaperInterpolation(Interpolation interp);
bool FileTransform::hasShaper();

Also these seem a bit smelly and very format specific in the current interface.

FileTransform::getCCCId();
FileTransform::setCCCId(const char * id);

Could this be replaced with some kind of key, type, value interface.

Maybe along the lines of (I would think the order of vars/parameters would be important for ui's which is why it's all index based):

int FileTransform::getNumVars();
VarType FileTransform::getVarType(int index);
const char * FileTransform::getVarName(int index);
int FileTransform::getVarIndex(const char * name);

void FileTransform::setStringVar(int index, const char * value);
const char * FileTransform::getStringVar(int index);

void FileTransform::setFloatVar(int index, float value);
float FileTransform::getFloatVar(int index);

enum VarType
{
        VAR_TYPE_NONE = 0,
        VAR_TYPE_STRING = 1,
        VAR_TYPE_FLOAT = 2
};

eg.
--snip--
int index = ptr->getVarIndex("CCCId");
if(ptr->getVarType(index) == VAR_TYPE_STRING)
ptr->setStringVar(, "MYSHOTCCC");
--snip--

This would allow me to move the ICCTransfrom code into a FileTransform impl which would be nice.

If your down with the idea I'm happy to whip something up when I have sometime after work.

.malcolm


Re: ocio2icc - Can I Create An ICC Profile From An Existing 3dl/csp LUT?

dbr/Ben <dbr....@...>
 

With "mylut.csp", and the following saved as "example.yaml" (http://pastie.org/2523829 incase the formatting is screwed up):


ocio_profile_version: 1

# Look in current working dir for LUT
resource_path: "."

roles:
  scene_linear: ref

displays:
  blah:
    - !<View> {device: blahview, name: ref, colorspace: ref}

colorspaces:
  - !<ColorSpace>
    name: ref
    family: ref
    bitdepth: 32f
    isdata: false

  - !<ColorSpace>
     name: mylut
     family: mylut
     bitdepth: 32f
     isdata: false

     from_reference: !<FileTransform>{src: mylut.csp, interpolation: linear}


Then run:

ociobakelut --iconfig example.yaml --inputspace ref --outputspace mylut --format houdini out.lut

..or:

ocio2icc --iconfig example.yaml --inputspace ref --outputspace mylut out.icc


Not entirely straight forward, would be nice to specify a file as an argument to ociobakelut (or maybe a separate ocioconvertlut?)

On 13/09/2011, at 6:06 AM, Jordan Soles wrote:

Hi Jeremy,

Thanks very much for your response and it would be absolutely amazing if you could add that option into to specify a 3D lut path.

If that's a fairly substantial amount of work, is there a way to work-around it for now by just defining it in the ocio profile?

Thanks,
Jordan


Re: ocio2icc - Can I Create An ICC Profile From An Existing 3dl/csp LUT?

Jordan Soles <jor...@...>
 

Hi Jeremy,

Thanks very much for your response and it would be absolutely amazing if you could add that option into to specify a 3D lut path.

If that's a fairly substantial amount of work, is there a way to work-around it for now by just defining it in the ocio profile?

Thanks,
Jordan


Re: ocio2icc - Can I Create An ICC Profile From An Existing 3dl/csp LUT?

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

On Fri, Sep 9, 2011 at 3:20 PM, Gresham Lochner
<gresham...@...> wrote:
 I believe I heard Jeremy mention Sony
brings their stuff in a neutral color space (in photoshop) rather than
trying to match what nuke see's with a cubic lut applied. Is that true?
Let me clarify. The colorspace we work in for texturing is partially
(but not totally) neutral.

Our rendering is in HDR linear, and the way our pixels get to the
scene is (approx):

(HDR scene-linear image) -> 1D Tonemapping to Display space (LDR
display pixels) -> 3D Filmic Color Warp (final film emulation preview)

In nuke/katana, as we're starting with hdr linear, both of these steps
(1d tone mapping + 3d color warp) happen in the viewer.

In photoshop, we paint directly in the LDR display pixel space, and we
apply only need to apply the 3D filmic component to preview the image
accurately.

It's nice to paint in this 'intermediate' colorspace because:
- the transformation back to scene-linear for rendering is only a 1d
transform (no inverse 3d luts)
- also, because the ldr painting space has a gamma very similar to the
monitor, things like color pickers / reference art work well.

For those who are not familiar with opencolorio.org, we've put
together a basic description of our color practices which is available
here. Of particular interest is the dt colorspace (diffuse-texture),
which corresponds to the intermediate space mentioned above.

http://opencolorio.org/workflow/spi_workflow.html
http://opencolorio.org/workflow/spi_vfx.html

-- Jeremy


Re: ocio2icc - Can I Create An ICC Profile From An Existing 3dl/csp LUT?

Gresham Lochner <gresham...@...>
 

Hey all,

This exact issue has been on my to do list for a long time. Previously I looked at spaceman icc (http://www.lightillusion.com/spaceman.htm) but never had enough time to get it working properly. I'd love to see this feature added to ocio. While we're on the issue, I'd love to get people's opinion on their photoshop-nuke workflow. I believe I heard Jeremy mention Sony brings their stuff in a neutral color space (in photoshop) rather than trying to match what nuke see's with a cubic lut applied. Is that true?
Ultimately I'm looking for a way to have a cubic lut that's being applied in nuke, affect my matte paintings in photoshop and it look identical.

Thanks,

- Gresham

On 9/9/2011 11:29 AM, Jeremy Selan wrote:
First off, major congrats and thanks for open-sourcing this as it's
something I'm very interested in embedding in our studio.
Thanks!

That said, I was wondering if there was a way to create an ICC profile
directly from 3DL or CSP lut? I think it's possible, but it appears to be
somewhat constrained to the creation of a proper ocio config (which I'm
still learning how to build).
Currently, no.

Both ociobakelut and ocio2icc require an ocio profile. However, it
would be a pretty simple change to add the functionality to allow you
to specify a single lut (or luts) on the command-line instead.

I'll see if I can knock this feature off in the next few days.

-- Jeremy


Re: ocio2icc - Can I Create An ICC Profile From An Existing 3dl/csp LUT?

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

First off, major congrats and thanks for open-sourcing this as it's
something I'm very interested in embedding in our studio.
Thanks!

That said, I was wondering if there was a way to create an ICC profile
directly from 3DL or CSP lut? I think it's possible, but it appears to be
somewhat constrained to the creation of a proper ocio config (which I'm
still learning how to build).
Currently, no.

Both ociobakelut and ocio2icc require an ocio profile. However, it
would be a pretty simple change to add the functionality to allow you
to specify a single lut (or luts) on the command-line instead.

I'll see if I can knock this feature off in the next few days.

-- Jeremy


ocio2icc - Can I Create An ICC Profile From An Existing 3dl/csp LUT?

Jordan Soles <jor...@...>
 

First off, major congrats and thanks for open-sourcing this as it's something I'm very interested in embedding in our studio.

That said, I was wondering if there was a way to create an ICC profile directly from 3DL or CSP lut? I think it's possible, but it appears to be somewhat constrained to the creation of a proper ocio config (which I'm still learning how to build).

Thanks,
Jordan


OpenColorIO 1.0 RC1 Release

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

As promised, OpenColorIO 1.0 Release Candidate 1 is now available for testing.

(No branches necessary, it's the top of the master repository.)
https://github.com/imageworks/OpenColorIO

We will continue to do heavy testing for the next few weeks, and hope
to designate it 1.0 by Oct 1st.

Also, to the best of our knowledge, OCIO 1.0 RC1 is ready for
production use (and is being rolled out at SPI). The reason we're
calling it RC1 is just to play it super conservative.

Enjoy!

-- Jeremy

------------------------------------------------------------------------

API Changes from 0.8->1.0

--- Functions Removed ---
ColorSpace::getEditableTransform
ColorSpace::isTransformSpecified
Config::getEditableTransform
Config::setDisplayColorSpaceName
GroupTransform::getEditableTransform
DisplayTransform::setDisplayColorSpaceName
DisplayTransform::getDisplayColorSpaceName

--- Misc Changes ---
PlanarImageDesc / PackedImageDesc now have simpler (non-virtual)
implementations, which is more consistent with the rest of OCIO.
Change should be source compatible in most cases.


Review: Makefile

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

https://github.com/imageworks/OpenColorIO/pull/162

Exposes additional build options
Allows more flexibility at cmake build time, including...
- build unittests without building library
- build documentation without compiling any code

Addresses issue #151

For 0.9/1.0 only

-- Jeremy


Review: remove testbed directory

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

0.9 / 1.0 branch only

https://github.com/imageworks/OpenColorIO/pull/161
Addresses issue #150

-- Jeremy


Review: Nuke OCIOFileTransform src knob renamed to 'file'

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

0.9 / 1.0 branch only

https://github.com/imageworks/OpenColorIO/pull/160
Addresses issue #154

-- Jeremy


OCIO 0.8.6 released

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

OCIO 0.8.6 has been released.

This will be the final 0.8 release before the 1.0 release candidate
later this week.

The biggest change in 0.8.6 is the config reading / writing has been
updated to match 1.0, to allow for greatest interoperability. So if
you've rolled out 0.8 to your facility, and want to support a common
set of ocio profiles in both 0.8 and 1.0 simultaneously, this update
is for you. (This is how we'll be working at SPI until we've fully
transitioned to OCIO 1.0).

-- Jeremy

**Version 0.8.6 (Sept 7 2011):**
* Updated .ocio config reading / writing to be forwards compatibile with 1.0
(Profiles written in 0.8.6+ will be 1.0 compatible.
Compatibility from prior versions is likely, though not guaranteed.)
* Better logging
* Added ColorSpace.equalitygroup (makes ColorSpace equality explicit)
* Substantial Nuke node updates
* Added support for Iridas .itx read/write
* Windows Build Support


Review: Further enabled the NukeWrapper for channel swizzling

Sean Looper <sean....@...>
 

https://github.com/imageworks/OpenColorIO/pull/159

Fixed some misspellings and re-enabled all the NukeWrapper features, redoing the knob layouts. I did remove some knobs rather than use the ObsoleteKnob. Wasn't sure if that was necessary yet. If it is, I can revisit. It doesn't hurt anything, but it does scare users when Nuke warns them that it can't find a knob for a knob value.

-sean

1621 - 1640 of 2242