Date   

Re: [ocs-dev] Re: OpenColorSpace.h feedback

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

Hi Jeremy,

On 23/06/2010, at 4:55 AM, Jeremy Selan wrote:

We have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same code, I was hoping to replace this with an OCS::Op::CDL() op. This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases. For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op.
I still believe that ops should not be part of the external API,
though I think we can offer you a simple solution.
I like to keep about 3 classifications for colour operations:
- transforms (eg, matrix multiplication)
- transfer functions (eg, Rec709 -> Lin)
- look up tables

It's cool, I just need to get used to calling all of these transforms (which arguably they are all transformations of data) not ops.

Might be good to update the todo's at the top of OpenColorSpace.h so they talk about transforms not ops.

We will expose a
CDLTransform (note that it will be implemented without a native CDLOp,
relying on the existing MatrixOffset and Gamma Ops). Have you seen
the processor class in our recent checkin?
Sounds ok, but I was just using that as an example of why I think it would be nice to have Ops as plugins. ie. like what units are your CDL grade parameters in? we have them set in printer points so we can integrate with other grading systems.

These workflow decisions I think should be kept out of the OCS core.

I really like the idea of OCS largely being a protocol for describing and communicating these transformation chains. Its going to be a huge undertaking to try and conform everyones workflow, I would really call this a 'soft' long term goal. A 'hard' goal would be having OCS integrated on all major platforms and applications, with vendors sharing .ocs profiles, luts and transform plugins.

It currently has an
apply(ImageDesc & img) call. We can add an additional singlePixel
variant that takes a raw float *. This will make it efficient to apply
your cdl per-pixel with minimal overhead.
Thats a great addition.

I was also just thinking that renaming ImageDesc to TileDesc would make the interface a little more obvious (completely superficially) when used inside a 3d renderer.

ie. with a renderman simd plugin where you have access to an entire grid of points (which you can't in mantra), I would happily call that a tile of data not an image.. really I can live with how it is, but a suggestion none the less.

What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core. Cortex already has an Op for truelight which you might find interestinghttp://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTru... I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now.
I've been thinking a lot about op plugins -- I'm really on the fence
-- but my current thought it to avoid it for 1.0. First, I fear that
a plugin system, not done well, will lead to a lot of user confusion.
I agree if you can't do it well, leave it till you can.

I really want OCS files to be totally portable, where you dont have to
think about versions or compatibility. I can picture a lead FX house
coming up with an OCS configuration not realizing it's using an
optional plugin format, distributing it, and then complications
arising downsteam once they've distributed the profile. There would
also be a whole range of issues related to plugin binary
compatibility, registration, image quality, etc. Furthermore, I've
always been strongly philosophically opposed to 'locked' LUT formats,
and would like to discourage their use in interchange. (Locked lut
formats are all pretense anyways, if you give me an API where I can
process an image, I'll guarantee you I can fish the lut out. In fact,
the OCS GPU pipeline takes advantage of this approach!)
Other than yes it's easy to fish these functions out, thats not really what I was trying to get at.

I would say your adding a 4th hard goal (not in list of 3 I sent out before) to OCS.

- conform all color math operations between vendors

I can see this being something that works against OCS uptake in the short term at larger lead vendors where I guess you would like OCS to be used throughout the pipe.

You could slightly change this to a long term soft goal for OCS, where people can replicate their current internal workflow today with ocs profiles, internal ocs transforms and with custom developed in-house transforms. This would be a huge step in the right direction, over time I would hope to see either the in-house transforms are out in the open for everyone or they go away completely.

It's an open source project, so if
someone wants to add an additional 'custom' op so their workflow can
be supported, I'd prefer that.
Thats to say the company wants to open source it. All I'm trying to get at is if you support transform/op plugins you remove a potential road block for OCS uptake, which I think is this most important thing for a project like this.

Do you have any specific examples you
could provide more info on?
We use a different log transfer function designed to get scene referred values from a KodakLog file. This is also used throughout the viewing workflow to encode linear values from 3D for use with film emulation like cinespace or truelight.

The other is used in conjunction with this log transfer function which some people are calling 'paint' transfer. This is used to encode a linear image into a 16bit 'sRGB like' space for things like matte painting in photoshop.

On the round trip it has less than one cineon code value of loss which visually you can't perceive (the slight data loss is a compromise in getting something working in photoshop, which isn't a big deal when they are painting on the frame). We also create an icc profile so people can soft proof (ie. with the film emulation) their work while also in photoshop.

It's not really my decision to make any of this opensource as it might have perceived value for my employers (as they pay me to re-develop them) or some other issues.

For me (and I'm guessing others) it would be great to deal with these two separately ie.
- using the OCS framework to describe/apply our colour pipeline
- getting vendors dealing with colour math the same

Finally, I'm worried about feature creep. My gut tells me that this
could be a can of worms, and we're short on time for 1.0 already.
There's a lot of intricacies in doing a proper plugin API, and I'd
rather give it the time it deserves. How does a plugin system work
with an .ocs bundle file? How does it work with GPU generation? What
about multi-platform plugin support? What about Op reuse? In the long
term, I'm totally open to reconsidering the idea; I feel it's just a
bit too much to add to our plate right now.
I agree, presenting something that isn't 100% coherent has the potential to add more confusion.

Thanks for the feedback!
No problem, happy to be involved in some way.

.malcolm


Re: An OCS by any other name?

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

FYI,

We've started the process for getting legal clearance on OpenColorIO.

Bonus kudos to Malcolm Humphreys for suggesting the name!

-- Jeremy


Re: OpenColorSpace.h feedback

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

We have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same code, I was hoping to replace this with an OCS::Op::CDL() op. This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases. For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op.
I still believe that ops should not be part of the external API,
though I think we can offer you a simple solution. We will expose a
CDLTransform (note that it will be implemented without a native CDLOp,
relying on the existing MatrixOffset and Gamma Ops). Have you seen
the processor class in our recent checkin? It currently has an
apply(ImageDesc & img) call. We can add an additional singlePixel
variant that takes a raw float *. This will make it efficient to apply
your cdl per-pixel with minimal overhead.


What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core. Cortex already has an Op for truelight which you might find interestinghttp://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTru... I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now.
I've been thinking a lot about op plugins -- I'm really on the fence
-- but my current thought it to avoid it for 1.0. First, I fear that
a plugin system, not done well, will lead to a lot of user confusion.
I really want OCS files to be totally portable, where you dont have to
think about versions or compatibility. I can picture a lead FX house
coming up with an OCS configuration not realizing it's using an
optional plugin format, distributing it, and then complications
arising downsteam once they've distributed the profile. There would
also be a whole range of issues related to plugin binary
compatibility, registration, image quality, etc. Furthermore, I've
always been strongly philosophically opposed to 'locked' LUT formats,
and would like to discourage their use in interchange. (Locked lut
formats are all pretense anyways, if you give me an API where I can
process an image, I'll guarantee you I can fish the lut out. In fact,
the OCS GPU pipeline takes advantage of this approach!)

For 'broken' current workflows that people need to emulate, I'd love
to attack them on case-by-case basis. I'd be really surprised if even
the worst workflows we need to support would rely on ops we couldn't
provide base level emulation of. It's an open source project, so if
someone wants to add an additional 'custom' op so their workflow can
be supported, I'd prefer that. Do you have any specific examples you
could provide more info on?

Finally, I'm worried about feature creep. My gut tells me that this
could be a can of worms, and we're short on time for 1.0 already.
There's a lot of intricacies in doing a proper plugin API, and I'd
rather give it the time it deserves. How does a plugin system work
with an .ocs bundle file? How does it work with GPU generation? What
about multi-platform plugin support? What about Op reuse? In the long
term, I'm totally open to reconsidering the idea; I feel it's just a
bit too much to add to our plate right now.

Thanks for the feedback!

-- Jeremy


OCS 0.5.8 posted

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

Version 0.5.8 (June 22 2010):
* Support for .3dl
* Support for matrix ops
* Code refactor (added Processors) to support gpu/cpu model
* Much better error checking
* Compilation support for python 2.5
* Compilation support for OSX


Re: [ocs-dev] OpenColorSpace.h feedback

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

On 20/06/2010, at 10:36 PM, Jeremy Selan wrote:

On another note that im about 50% done with the GPU design, and this
will change the class design a bit yet a again. (It introduces a
processor class, and all the ApplyTransforms go away. You instead do a
instead, and processors have fcns like renderCPU(Img),
getGPUShaderText, etc. It's actually much cleaner.
Cool, sounds good.

The big distinction between transforms and ops are that transforms are
client-facing, and ops never escape the library. I could ditch
GroupTransform in favor of a transformVec, but it seemed useful to
have to avoid all the trouble with returning a vector (windows dll
crap).
We have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same code, I was hoping to replace this with an OCS::Op::CDL() op.

This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases.

For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op.

What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core.

Cortex already has an Op for truelight which you might find interesting
http://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTruelight/TruelightColorTransformOp.cpp

I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now.

A family relates to bit-depthness, and though the concept is fully
fleshed out in our internal spi library im still grappling with how to
de-imageworks-ify it. For example, we use the colorspace 'lg10' for
10 bit file io, but the luts used dont have enough precision for 16
bit use. So we also have lg16 for that case. Also, lgh (h standing
for half float). These are all in the lg family. It's actually called
prefix in the SPI codebase. It would be cool if the concept could go
away, but I havent yet figure out how to efficiently make that happen.
That feels like you could drop the extra color spaces and make that part of the Transform() or TransformGroup(). This would make a ColorSpace() define how it would be represented in/at different bit depths.

colorspace(name='lgh')
to_reference(bitdepth='16f')
... op chain ...
to_reference(bitdepth='16ui')
... op chain ...
to_reference(bitdepth='10ui')
... op chain ...
...

The other option would be to make that part of the Lut1D and Lut3D Ops, ie reading different luts for different bit depths.

But after thinking about it I feel the to_reference(bitdepth='16f') would be better as you most likely will need different color op chains in certain situations which would get you back into having color spaces for different bit depths.

Roles (their concept) are super useful to have in production because
shows often names their colorspaces differently. We found ourselves
wanting 'constants' for a whole bunch of em repeatedly, so thats why
they're in the library. SCENE_LINEAR being an obvious one, where its
useful to want to sometimes reference it by its 'concept'. They are
also integral to the display pipeline (code not yet used), where they
correspond to certain defaults. (in the display pipeline, fstop
expose offsets default to a multiplier in SCENE_LINEAR, and this is
how it's driven).

The roles (and their API) are just strings though, so facilities are
free to use new ones at any time using the same storage mechanism.
(At SPI we add extra ones specifying each output media colorspace:
quicktime, avi, omf, etc).
I still feel this should be in OCS configuration of some kind with an small api for listing and selecting roles in the current context. I don't think a change in configuration like renaming or adding a role should require recompiling of the OCS core.

Give me a kick if this feedback is too much like noise.

.malcolm


On Sun, Jun 20, 2010 at 5:53 AM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:
Hi Jeremy and others,
After looking at OpenColorSpace.h a bit today I have some feedback.
First I just want to make sure I'm getting the concepts correct. Let me know
if these summaries on the core classes are correct?
class Config;
is a top level configuration object that can be serialised into a .ocs file.
Will also define the reference space (most likely scene linear)
class ColorSpace;
is a definition of color space with an operation chain to get from this
space to the top level reference space.
class Transform;
is the base class for color transform operations
class GroupTransform;
manages an ordered list of color transform operations
class FileTransform;
is the base class for look up table transforms ops (Lut1D and Lut3D)
I got a bit confused between Ops, Transform and GroupTransform when looking
through the code. I can see how they will work just the concepts feel a bit
mixed to me. I keep wanting to call a GroupTransform a Transform (or OpList
or OpChain) and a Transform an Op.
eg,
Config ('fabricated')
`- ColorSpace ('spacejam')
`- Transform (to_reference)
`- [ Op::Lut1D (), Op::Gamma (), Op::Foo () ]
I don't think FileTransform should be in here. I'll send another email about
Ops if this feedback is going in the right direction as I don't want to
create two much noise.
Family
Can you give a brief description of what a family is? I can see 'family'
referenced here and there but not currently used.
Roles
From the description:
"ColorSpace Roles are used so that plugins, in addition to this API can
have abstract ways of asking for common colorspaces, without referring to
them by hardcoded names."
I can see the need for an abstract way to tag colorspaces so that client
apps don't need to deal with production details like the same ocs color
space being called something slightly different on two shows. But it feels
wrong for that abstract list of roles to be then hardcoded into the header.
I would prefer to have a site-wide .ocs file which defines the possible
roles (this file could also define site-wide color space but it wouldn't
have too). Then in the local/show/project .ocs you would be able to link one
of these abstract role names to a color space in that file/context.
I would also like to be able to define new roles just in that project .ocs
as well. These show roles would only be used with tools within that show
that were written to support them. The long term idea would be to roll them
back into the site-wide role definition (if it made sense to do so) but have
some ability to test the roll in the show context. I could see my self using
roles also for things like dealing with fixed production devices
ie ROLE_STILLS_CAMERA1 but I'm not sure if thats what you had in mind.
.malcolm


Re: [ocs-dev] OpenColorSpace.h feedback

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

yah, these summaries are correct. go to the google group, and check
out the 'internal architecture overview' doc. It's still a huge work
in progress but provides a bit more of an overview.

I have to run in a few, gonna do a super-quick reply...

On another note that im about 50% done with the GPU design, and this
will change the class design a bit yet a again. (It introduces a
processor class, and all the ApplyTransforms go away. You instead do a
instead, and processors have fcns like renderCPU(Img),
getGPUShaderText, etc. It's actually much cleaner.

The big distinction between transforms and ops are that transforms are
client-facing, and ops never escape the library. I could ditch
GroupTransform in favor of a transformVec, but it seemed useful to
have to avoid all the trouble with returning a vector (windows dll
crap).

A family relates to bit-depthness, and though the concept is fully
fleshed out in our internal spi library im still grappling with how to
de-imageworks-ify it. For example, we use the colorspace 'lg10' for
10 bit file io, but the luts used dont have enough precision for 16
bit use. So we also have lg16 for that case. Also, lgh (h standing
for half float). These are all in the lg family. It's actually called
prefix in the SPI codebase. It would be cool if the concept could go
away, but I havent yet figure out how to efficiently make that happen.

Roles (their concept) are super useful to have in production because
shows often names their colorspaces differently. We found ourselves
wanting 'constants' for a whole bunch of em repeatedly, so thats why
they're in the library. SCENE_LINEAR being an obvious one, where its
useful to want to sometimes reference it by its 'concept'. They are
also integral to the display pipeline (code not yet used), where they
correspond to certain defaults. (in the display pipeline, fstop
expose offsets default to a multiplier in SCENE_LINEAR, and this is
how it's driven).

The roles (and their API) are just strings though, so facilities are
free to use new ones at any time using the same storage mechanism.
(At SPI we add extra ones specifying each output media colorspace:
quicktime, avi, omf, etc).

On Sun, Jun 20, 2010 at 5:53 AM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:
Hi Jeremy and others,
After looking at OpenColorSpace.h a bit today I have some feedback.
First I just want to make sure I'm getting the concepts correct. Let me know
if these summaries on the core classes are correct?
class Config;
is a top level configuration object that can be serialised into a .ocs file.
Will also define the reference space (most likely scene linear)
class ColorSpace;
is a definition of color space with an operation chain to get from this
space to the top level reference space.
class Transform;
is the base class for color transform operations
class GroupTransform;
manages an ordered list of color transform operations
class FileTransform;
is the base class for look up table transforms ops (Lut1D and Lut3D)
I got a bit confused between Ops, Transform and GroupTransform when looking
through the code. I can see how they will work just the concepts feel a bit
mixed to me. I keep wanting to call a GroupTransform a Transform (or OpList
or OpChain) and a Transform an Op.
eg,
Config ('fabricated')
  `- ColorSpace ('spacejam')
    `- Transform (to_reference)
`- [ Op::Lut1D (), Op::Gamma (), Op::Foo () ]
I don't think FileTransform should be in here. I'll send another email about
Ops if this feedback is going in the right direction as I don't want to
create two much noise.
Family
Can you give a brief description of what a family is? I can see 'family'
referenced here and there but not currently used.
Roles
From the description:
"ColorSpace Roles are used so that plugins, in addition to this API can
have abstract ways of asking for common colorspaces, without referring to
them by hardcoded names."
I can see the need for an abstract way to tag colorspaces so that client
apps don't need to deal with production details like the same ocs color
space being called something slightly different on two shows. But it feels
wrong for that abstract list of roles to be then hardcoded into the header.
I would prefer to have a site-wide .ocs file which defines the possible
roles (this file could also define site-wide color space but it wouldn't
have too). Then in the local/show/project .ocs you would be able to link one
of these abstract role names to a color space in that file/context.
I would also like to be able to define new roles just in that project .ocs
as well. These show roles would only be used with tools within that show
that were written to support them. The long term idea would be to roll them
back into the site-wide role definition (if it made sense to do so) but have
some ability to test the roll in the show context. I could see my self using
roles also for things like dealing with fixed production devices
ie ROLE_STILLS_CAMERA1 but I'm not sure if thats what you had in mind.
.malcolm


OpenColorSpace.h feedback

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

Hi Jeremy and others,

After looking at OpenColorSpace.h a bit today I have some feedback.

First I just want to make sure I'm getting the concepts correct. Let me know if these summaries on the core classes are correct? 

class Config;
is a top level configuration object that can be serialised into a .ocs file. Will also define the reference space (most likely scene linear)

class ColorSpace;
is a definition of color space with an operation chain to get from this space to the top level reference space.

class Transform;
is the base class for color transform operations

class GroupTransform;
manages an ordered list of color transform operations

class FileTransform;
is the base class for look up table transforms ops (Lut1D and Lut3D)

I got a bit confused between Ops, Transform and GroupTransform when looking through the code. I can see how they will work just the concepts feel a bit mixed to me. I keep wanting to call a GroupTransform a Transform (or OpList or OpChain) and a Transform an Op.

eg,
Config ('fabricated')
  `- ColorSpace ('spacejam')
    `- Transform (to_reference)
`- [ Op::Lut1D (), Op::Gamma (), Op::Foo () ]

I don't think FileTransform should be in here. I'll send another email about Ops if this feedback is going in the right direction as I don't want to create two much noise.

Family 
Can you give a brief description of what a family is? I can see 'family' referenced here and there but not currently used.

Roles
From the description:
"ColorSpace Roles are used so that plugins, in addition to this API can have abstract ways of asking for common colorspaces, without referring to them by hardcoded names."

I can see the need for an abstract way to tag colorspaces so that client apps don't need to deal with production details like the same ocs color space being called something slightly different on two shows. But it feels wrong for that abstract list of roles to be then hardcoded into the header.

I would prefer to have a site-wide .ocs file which defines the possible roles (this file could also define site-wide color space but it wouldn't have too). Then in the local/show/project .ocs you would be able to link one of these abstract role names to a color space in that file/context.

I would also like to be able to define new roles just in that project .ocs as well. These show roles would only be used with tools within that show that were written to support them. The long term idea would be to roll them back into the site-wide role definition (if it made sense to do so) but have some ability to test the roll in the show context. I could see my self using roles also for things like dealing with fixed production devices ie ROLE_STILLS_CAMERA1 but I'm not sure if thats what you had in mind.

.malcolm


Re: An OCS by any other name?

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

You've convinced me.

OpenColorIO is pretty damn good.

... and your summary is dead accurate as well.

After looking at OCS it feels like it's aiming to achieve 3 main things:
- a standard / protocol for describing colo(u)r transformation chains
- caching / baking of these chains (various lut formats)
- evaluation of these chains on the cpu / gpu
Let's ponder this for the weekend.


Re: [ocs-dev] Re: An OCS by any other name?

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

Pending on how the can of worm goes.

The main observation I had with the name OCS is kind of what people are saying here. I feel the name is wrong (with any project not just OCS) if your not using it in conversations with others, or if your spending large amounts of time explaining why it's not what it says on the tin. I would rather spend that energy (even if it is my hot air) in other areas like making the system more complete, usable and adoptable.

I think OpenColorManagement maybe is setting the bar a little two high for the project. Unless we think it will be a complete end to end solution. I can also see the ICC will be not be jumping for joy either. ;)

http://www.color.org
"The purpose of the ICC is to promote the use and adoption of open, vendor-neutral, cross-platform color management systems."

After looking at OCS it feels like it's aiming to achieve 3 main things:
- a standard / protocol for describing colo(u)r transformation chains
- caching / baking of these chains (various lut formats)
- evaluation of these chains on the cpu / gpu

If this is what the project is trying to achieve (which I think will be amazing) then I would vote for something more like OpenColorIO. Which not only aligns it self well with OIIO but for me it fits better with these 3 overall aims.

Really I could deal with pretty much any name other than OpenColorSpace.

.malcolm

On 19/06/2010, at 8:09 AM, Rod Bogart wrote:

I must admit, I've been calling it OpenColorSPIce.

RGB

On Fri, Jun 18, 2010 at 3:04 PM, Steve LaVietes
<steve.l...@gmail.com> wrote:
If it's the OCS part that matters:

Open Color System?

-stevel


On Fri, Jun 18, 2010 at 2:55 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Ope,

Turns out I may have opened a can of worms on our end. I didnt
realize this yesterday, but we'd already gotten legal signoff on the
"OCS" name, and changing it now is not gonna be simple.

So keep thinking of ideas, but don't anyone get their hopes up about
"Open Color Management" yet. :(

-- Jeremy


Re: [ocs-dev] Re: An OCS by any other name?

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

Hah! :)

On Fri, Jun 18, 2010 at 3:09 PM, Rod Bogart <bog...@gmail.com> wrote:
I must admit, I've been calling it OpenColorSPIce.

RGB

On Fri, Jun 18, 2010 at 3:04 PM, Steve LaVietes
<steve.l...@gmail.com> wrote:
If it's the OCS part that matters:

Open Color System?

-stevel


On Fri, Jun 18, 2010 at 2:55 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Ope,

Turns out I may have opened a can of worms on our end.  I didnt
realize this yesterday, but we'd already gotten legal signoff on the
"OCS" name, and changing it now is not gonna be simple.

So keep thinking of ideas, but don't anyone get their hopes up about
"Open Color Management" yet. :(

-- Jeremy


Re: [ocs-dev] Re: An OCS by any other name?

Rod Bogart <bog...@...>
 

I must admit, I've been calling it OpenColorSPIce.

RGB

On Fri, Jun 18, 2010 at 3:04 PM, Steve LaVietes
<steve.l...@gmail.com> wrote:
If it's the OCS part that matters:

Open Color System?

-stevel


On Fri, Jun 18, 2010 at 2:55 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Ope,

Turns out I may have opened a can of worms on our end.  I didnt
realize this yesterday, but we'd already gotten legal signoff on the
"OCS" name, and changing it now is not gonna be simple.

So keep thinking of ideas, but don't anyone get their hopes up about
"Open Color Management" yet. :(

-- Jeremy


Re: [ocs-dev] Re: An OCS by any other name?

Steve LaVietes <steve.l...@...>
 

If it's the OCS part that matters:

Open Color System?

-stevel

On Fri, Jun 18, 2010 at 2:55 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Ope,

Turns out I may have opened a can of worms on our end.  I didnt
realize this yesterday, but we'd already gotten legal signoff on the
"OCS" name, and changing it now is not gonna be simple.

So keep thinking of ideas, but don't anyone get their hopes up about
"Open Color Management" yet. :(

-- Jeremy


Re: An OCS by any other name?

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

Ope,

Turns out I may have opened a can of worms on our end. I didnt
realize this yesterday, but we'd already gotten legal signoff on the
"OCS" name, and changing it now is not gonna be simple.

So keep thinking of ideas, but don't anyone get their hopes up about
"Open Color Management" yet. :(

-- Jeremy


Re: [ocs-dev] Re: An OCS by any other name?

Larry Gritz <l...@...>
 

I vote for "Open Color Management."

But I'd use it no matter what name you choose.


On Jun 18, 2010, at 1:56 PM, Alex wrote:

I'm with the other's that this effort isn't really about defining
color spaces or color encodings but rather offering an open set of
libraries to manage color transformations. I believe the name should
probably reflect that.



On Jun 18, 10:59 am, Rod Bogart <bog...@gmail.com> wrote:
I agree that the system is more about conversion between spaces. OCC?

RGB

PS - nice try sneaking the "u" into color, Bruno...

On Fri, Jun 18, 2010 at 6:59 AM, Bruno Nicoletti

<bruno.j....@googlemail.com> wrote:
How about "Open Colour Management"? Seeing as it is more about
coordinating the whole mess of colour spaces and displays and so on,
rather than being a colour space per se.
b
On 18 June 2010 08:52, Jeremy Selan <jeremy...@gmail.com> wrote:
I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.
What are other people's feeling on "OCS"?
Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.
Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...
Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."
Malcolm's suggested a few additions (with my added notes)
- OpenColorWorkSpace (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)
None of these particularly jump out at me, but I'm open to all ideas.
What are peoples thoughts?
There's time yet to rethink OCS's name, but the window is closing...
--
Bruno Nicoletti
--
Larry Gritz
l...@imageworks.com


Re: An OCS by any other name?

Alex <alexfo...@...>
 

I'm with the other's that this effort isn't really about defining
color spaces or color encodings but rather offering an open set of
libraries to manage color transformations. I believe the name should
probably reflect that.

On Jun 18, 10:59 am, Rod Bogart <bog...@gmail.com> wrote:
I agree that the system is more about conversion between spaces.  OCC?

RGB

PS - nice try sneaking the "u" into color, Bruno...

On Fri, Jun 18, 2010 at 6:59 AM, Bruno Nicoletti

<bruno.j....@googlemail.com> wrote:
How about "Open Colour Management"? Seeing as it is more about
coordinating the whole mess of colour spaces and displays and so on,
rather than being a colour space per se.
b
On 18 June 2010 08:52, Jeremy Selan <jeremy...@gmail.com> wrote:
I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.
What are other people's feeling on "OCS"?
Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.
Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...
Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."
Malcolm's suggested a few additions (with my added notes)
- OpenColorWorkSpace   (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow  (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)
None of these particularly jump out at me, but I'm open to all ideas.
What are peoples thoughts?
There's time yet to rethink OCS's name, but the window is closing...
--
Bruno Nicoletti


Re: [ocs-dev] An OCS by any other name?

Rod Bogart <bog...@...>
 

I agree that the system is more about conversion between spaces. OCC?

RGB

PS - nice try sneaking the "u" into color, Bruno...

On Fri, Jun 18, 2010 at 6:59 AM, Bruno Nicoletti
<bruno.j....@googlemail.com> wrote:
How about "Open Colour Management"? Seeing as it is more about
coordinating the whole mess of colour spaces and displays and so on,
rather than being a colour space per se.

b

On 18 June 2010 08:52, Jeremy Selan <jeremy...@gmail.com> wrote:
I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.

What are other people's feeling on "OCS"?

Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.

Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...

Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."

Malcolm's suggested a few additions (with my added notes)

- OpenColorWorkSpace   (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow  (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)

None of these particularly jump out at me, but I'm open to all ideas.

What are peoples thoughts?

There's time yet to rethink OCS's name, but the window is closing...


--
Bruno Nicoletti


Re: [ocs-dev] An OCS by any other name?

Bruno Nicoletti <bruno.j....@...>
 

How about "Open Colour Management"? Seeing as it is more about
coordinating the whole mess of colour spaces and displays and so on,
rather than being a colour space per se.

b

On 18 June 2010 08:52, Jeremy Selan <jeremy...@gmail.com> wrote:
I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.

What are other people's feeling on "OCS"?

Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.

Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...

Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."

Malcolm's suggested a few additions (with my added notes)

- OpenColorWorkSpace   (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow  (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)

None of these particularly jump out at me, but I'm open to all ideas.

What are peoples thoughts?

There's time yet to rethink OCS's name, but the window is closing...
--
Bruno Nicoletti


An OCS by any other name?

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

I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.

What are other people's feeling on "OCS"?

Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.

Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...

Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."

Malcolm's suggested a few additions (with my added notes)

- OpenColorWorkSpace (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)

None of these particularly jump out at me, but I'm open to all ideas.

What are peoples thoughts?

There's time yet to rethink OCS's name, but the window is closing...


OCS now on github

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

We've setup a private repository for developers on github! Please
email your github account details you'd like access.

For everyone else, we will continue to post weekly code drops.


Re: Got Luts?

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

Oh I have never used this as it got released by RSR after we
implemented the csp format at RSP.

Not sure if it's helpful as I haven't spent anytime looking into it so
I wouldn't expect it to work out of the box.
https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/trunk/

.malcolm

On Jun 15, 10:13 pm, Malcolm Humphreys <malcolmh...@mac.com>
wrote:
Mostly using cinespace .csp, houdini .lut and .icc profiles for
photoshop.

The main lut format requirements for me is supporting some form of 1D
pre lut and a 3D cube.

I have uploaded the csp lut spec here as the RSR link out there never
seemed to work.http://groups.google.com.au/group/ocs-dev/web/cineSpace_LUT_format.zip

There is also an example 1D3D houdini lut if this helpshttp://groups.google.com.au/group/ocs-dev/web/lin_gamma22_1D3D.lut

.malcolm

On Jun 9, 7:16 am, Jeremy Selan <jeremy...@gmail.com> wrote:

Good feedback.  How about this:
Let's support all trivial image formats, as long as it doesn't
introduce a library dependency or support headache.  So PPM is in.  If
there's a simple raw/ascii float format someone can recommend, let's
add that too.
Exr, dpx, tiff, jpg, etc are out.
As OIIO supports ppm we just need to validate the conversion path, and
then we can recommend it's use as a pre-process.  (And OIIO will be
gaining DPX support this summer so then all bases are covered).
I'd like to avoid larry suggested 'raw lut access' approach in the
short-term, at least until the bundled .ocs file support is worked
out.
-- Jeremy
On Tue, Jun 8, 2010 at 1:58 PM, bsloan <bsl...@gmail.com> wrote:
I've used 10bit DPX for this purpose in the past (when I thought I'd
invented 2D 3D LUTs).
8 or 16 bit PPM may be a good compromise. It won't please everyone but
implementation requires so little code -- and the advantage of *not*
having to depend on openimageio may outweigh the disadvantage of
whining developers :).
There's some precedent for this -- NVidia's early Cg SDK provided the
source for a lightweight PPM IO library.
Who knows? This may be one case where OCS can influence the standard.
-blake
On Jun 8, 11:28 am, Larry Gritz <l....@imageworks.com> wrote:
I wouldn't burden OCS with the image-reading functionality.  You'll never make everybody happy without supporting a bzillion formats.  Why not just allow the lut to be specified as a big array and call it a day, and let apps that use OCS be responsible for reading the image files (or having its own dependency on an image-reading library) in order to pass the array?
On Jun 8, 2010, at 11:10 AM, Naty Hoffman wrote:
There are some subtleties with layout and mappings, so let me know
when it's time to implement the import/export logic and I'll write up
a spec.
As for file formats, people use different ones - TIFF and TGA are
common.  There are enough tools to support converting between 2D
formats that I don't know if it's worth adding complex library
dependencies to Open Color Space just for this. Does OCS have any 2D
image file formats supported at the moment? PPM (the RGB version of
PBM) could perhaps work - how widely is it supported by common image
viewing utilities, OS thumbnails, etc.?
Naty
Sent from my iPhone
On Jun 8, 2010, at 10:05 AM, Jeremy Selan <jeremy...@gmail.com>
wrote:
Yah, the "lut as image" approach should be really easy to support,
I'll add that to the short list.  My only concern would be which
fileformats to support.  I'd still like to keep our dependencies as
low as possible though.  Naty, when folks use this approach in
production, which file formats are actually used to store the pixel
data?
If it were a trivial ascii format (such as pbm,pnm, etc) that would be
ideal... ;)
-- Jeremy
On Jun 7, 7:04 pm, "Nathaniel Hoffman" <n....@io.com> wrote:
Jeremy,
The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:http://
udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...
Thanks,
Naty
Jeremy,
There are two LUT formats I know of that are used in game
development.
One is a 2D image format (any lossless image format will do -
we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the
planes
along the 3rd axis have been placed next to each other. So a
32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an
identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package,
and
then the colorized LUT is extracted.
The other format is a DDS (Microsoft DirectDraw Surface) file with
a 3D
texture in it, typically uncompressed. This is usually loaded
directly
into the game engine.
These are both a bit ad-hoc and not really standardized, so I
don't know
if they are relevant for OCS. If they are, let me know and I can
try to
work up something more like an actual spec for each of these.
Thanks,
Naty
Hello!
I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.
If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on
the
importers.
Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild.  (I need to
make
sure the internal API is rich enough to encompass current use
cases).
Many formats have been mentioned previously, including:
   - Truelight ASCII .cub 3D lut
   - Assimilate Scratch  (Arri /Kodak .3dl)
   - Iridas Framecycler  (Iridas .cube)
   - Autodesk            (MESH3D, .lut, etc.)
For the majority of these, I do not have either example files or
specifications. Please help! :)
Also, does anyone know if the majority of lut formats
identifiable by
their extension?  Are there common extension conflicts?  Ideally,
I'd
like to try and have format reader registered based on file
extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).
(Note that I'm not assuming 1 file == 1 lut.  (We will support
readers
where 1 file can generate multiple transforms, such as a 1d
shaper lut
-> 3d lut -> 1d shaper lut.))
--
Larry Gritz
l....@imageworks.com

2121 - 2140 of 2191