Hi Jeremy,

On Thu, Aug 5, 2010 at 4:16 PM, Jeremy Selan <jeremy...@gmail.com> wrote:

Good catch.  I've updated the git repo and the downloads site (
http://code.google.com/p/opencolorio/downloads/list ) so all the
configs will work with the latest trunk release.

Thanks - it's running happily now.

Unfortunately, I'm also a bit behind in the publishing the docs. (I
have a version internally, but they're a but out of date).  I'll do my
best to repost them all within a day or two.

I'm currently working on writing a quicktime generator using OpenImageIO,
OpenColorIO, libquicktime and Qt.

I'd like to check that I'm correctly understanding OpenColorIO's intention.

Is it intended that it will handle the color transforms and that those
transforms
will be stored in it's own XML based format?

If so, would it be within the scope of the project to build importers
and exporters that for various formats? I'm thinking of cases where
I want to bring in a LUT to apply to footage or when I want to supply
a LUT from OpenImageIO to another application.

Of course, in the next few months I'd like the library to be entirely
self documenting (doxygen), and if anyone would like to help get the
ball rolling, i'd be very appreciative. (i'm happy to write them all,
I just dont have doxygen formatting / makefile experience).

I can probably throw in with the doxygen style comments - they're
pretty easy so if you're cool with me passing some dumb questions
(like the ones above) I'd be happy to help out ther.

I'd also like to have the color profiles be self documenting. (I
picture a command-line tool that will load a config, and generate an
html page outlining its use, options, etc).

That sounds like a fantastic idea - LUT formats don't seem to have
info needed to really know how to use them. Like what stage they're
intended for, the direction of the transform, whether the user will want
to offset/multiply/whatever afterward.

Cheers,

Alan.

Alan,

Good catch. I've updated the git repo and the downloads site (
http://code.google.com/p/opencolorio/downloads/list ) so all the
configs will work with the latest trunk release.

Unfortunately, I'm also a bit behind in the publishing the docs. (I
have a version internally, but they're a but out of date). I'll do my
best to repost them all within a day or two.

Of course, in the next few months I'd like the library to be entirely
self documenting (doxygen), and if anyone would like to help get the
ball rolling, i'd be very appreciative. (i'm happy to write them all,
I just dont have doxygen formatting / makefile experience).

I'd also like to have the color profiles be self documenting. (I
picture a command-line tool that will load a config, and generate an
html page outlining its use, options, etc).

-- Jeremy

Hi all,

The example config doesn't appear to have the required luma
attributes. Could someone let me know what and where they should be?

Also is there any documentation around or should I just run doxygen
over the source?

Cheers,

Alan

It was great seeing some of you at today's Siggraph class!

If anyone is interested in more detailed info (or just wants to say
hello in person) we'll be having a BOF tomorrow. Hope to see some of
you there!

Birds of a Feather : OpenColorIO
WEDNESDAY, 28 JULY | 2:30 PM - 3:30 PM | ROOM 506

Cheers,
Jeremy

Hi Jeremy,

oops never mind looks like it will support it.

Yep it all looks ok to me, just really feel like spliting out the
non-core stuff into a plugin or similar dir.

For now I think nearest iterp is fine as we normally have enough
points for 10bits in all channels, we have used Catmull-Rom in
the past. As we will be only using this for viewing scene linear it
should be ok in the short term.

I don't need 4 channel luts, but other people might.

.malcolm

I've been using that lately on OIIO and OSL, and for our simple needs it works just fine. Also nice because if you're already using Boost for anything else, you can use its unit tests without adding any new dependencies.

-- lg


On Jul 21, 2010, at 8:57 AM, Jeremy Selan wrote:

Boost sounds great; let's start with that.

-- Jeremy

On Wed, Jul 21, 2010 at 7:31 AM, Bruno Nicoletti
<bruno.j....@googlemail.com> wrote:

We use boost's unit test suite here as well, a few quibbles but it
works fairly well.

b

On 21 July 2010 15:23, Malcolm Humphreys <malcolmh...@mac.com> wrote:

Hi,

I would like to write tests for the work that I do.

What unit test framework are you planning on using, as I guess it adds another
dependancy. I have gotten used to using the boost framework but I'm sure you
have something else planned.

.malcolm

--
Bruno Nicoletti

--
Larry Gritz
l...@imageworks.com

Boost sounds great; let's start with that.

-- Jeremy

On Wed, Jul 21, 2010 at 7:31 AM, Bruno Nicoletti
<bruno.j....@googlemail.com> wrote:

We use boost's unit test suite here as well, a few quibbles but it
works fairly well.

b

On 21 July 2010 15:23, Malcolm Humphreys <malcolmh...@mac.com> wrote:

Hi,

I would like to write tests for the work that I do.

What unit test framework are you planning on using, as I guess it adds another
dependancy. I have gotten used to using the boost framework but I'm sure you
have something else planned.

.malcolm

--
Bruno Nicoletti

Malcolm,

I believe the 1D lut op does allow for a different number of entries
per channel.
If we look at src/core/Lut1DOp.h,

you'll see the entry for each color channel lut is stored in an
individual vector: fv_t luts[3].
So in your loading code (if we hardcoded the sizes used in your example),

lut1d->luts[0].resize(11);
lut1d->luts[1].resize(6);
lut1d->luts[2].resize(6);

Does the rest of the Format loading code make sense to you? All your
work should be in a single file, a la FileFormat3DL.


A few additional questions for you:

* Currently, OCIO only support linear and nearest interpolation for 1D
luts. If the examples you've given are typical (where the 1d lut is
size 6) I couldnt imagine linear interpolation would suffice, and I'd
also imagine that the interpolation type chosen would highly influence
the resulting image. Does CSP dictate the interpolation type? What
type would you prefer? I have no problem adding higher types (cubic,
etc) I just hadnt had the need to yet. (Note that the .3dl shaper 1D
lut also has this issue (it's often size 17), I just hadnt tackled it
yet.)

* Do you care about 4 channel luts? (I.e., changing alpha) We've
never needed this at SPI, which is why the OCIO currently assumes 3
channels, but if other people think its important for completeness
sake Im open to it.


-- Jeremy


On Wed, Jul 21, 2010 at 6:11 AM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:

Hi,

I started looking at adding csp lut format to ocio.

A csp lut allows a 1D prelut with a different number of points per channel. The
current Lut1DOp only supports applying the same 1D lut to all channels.

I'm wondering if this is something you were thinking of supporting in ocio?

--snip--
Access LUT data via a gamma lookup
Red channel has gamma 2.0
Green channel has gamma 3.0 but also has fewer points
Blue channel has gamma 2.0 but also has fewer points
11
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
0.0 0.01 0.04 0.09 0.16 0.25 0.36 0.49 0.64 0.81 1.0
6
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.008 0.064 0.216 0.512 1.0
6
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.04 0.16 0.36 0.64 1.0
--snip--

.malcolm

We use boost's unit test suite here as well, a few quibbles but it
works fairly well.

b

--
Bruno Nicoletti

Hi,

I would like to write tests for the work that I do.

What unit test framework are you planning on using, as I guess it adds another
dependancy. I have gotten used to using the boost framework but I'm sure you
have something else planned.

.malcolm

Hi,

I started looking at adding csp lut format to ocio.

A csp lut allows a 1D prelut with a different number of points per channel. The
current Lut1DOp only supports applying the same 1D lut to all channels.

I'm wondering if this is something you were thinking of supporting in ocio?

--snip--
Access LUT data via a gamma lookup
Red channel has gamma 2.0
Green channel has gamma 3.0 but also has fewer points
Blue channel has gamma 2.0 but also has fewer points
11
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
0.0 0.01 0.04 0.09 0.16 0.25 0.36 0.49 0.64 0.81 1.0
6
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.008 0.064 0.216 0.512 1.0
6
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.04 0.16 0.36 0.64 1.0
--snip--

.malcolm

Friends,

So Siggraph is just around the corner, which means OpenColorIO is
going public! Both this google group, as well as the git repo are
now completely open to all.

If you're attending Siggraph, please come check us out:

Course: Color Enhancement and Rendering in Film and Game Production
TUESDAY, 27 JULY | 9:00 AM - 12:15 PM | ROOM 502 A
(my presentation time is tentatively 9:55 - 10:15, a portion of which
i'll use to introduce OpenColorIO).

Birds of a Feather : OpenColorIO
WEDNESDAY, 28 JULY | 2:30 PM - 3:30 PM | ROOM 506
This will be a more informal, in depth look at OCIO and it's roadmap /
integration schedule.

Imageworks will also have an official OCIO press-release on Monday.

If you're not able to make either of these, but are still interested
in talking in person, please contact me personally. My schedule is
flexible, and I'd love to meet everyone interested in this subject.

Also - not related to OCIO - but for those interested in open source
projects I'd highly recommend checking out:
Panel: Large Steps Toward Open Source
THURSDAY, 29 JULY | 9:00 AM - 10:30 AM | ROOM 408 AB
The speaker are excellent, representing such graphics projects as OSL,
Alembic, OpenEXR, PTex, etc.


Cheers,
Jeremy

I view these as two separate problems. One is gathering color
information. The other is performing color transforms. OCIO seems to
be focused on the latter. I would like to see the OCIO API stay open
enough to where we can use its color transform capability outside the
confines of a fixed color pipeline. The hybrid approach Jeremy
described may be just what we are looking for.

Another thing I would like to maintain the option for, and that was
hinted at in Jeremy's first response, is different mappings between
color spaces. As an example, when converting two RGB spaces with
different white points you have the option of preserving absolute
colorimetry or performing some form of chromatic adaptation. With a
static configuration, it seems like you have to pick one or the other
since each half of the conversion is built into the color space
definition. So you either have a chromatically adapted workflow, or
you don't. Also, it's a little weird in the sense that the chromatic
adaptation (if you were to use it) would have to be already built into
each colorspace definition (ICC D50 anyone? or maybe you would prefer
ACES D60?) but it may not be explicitly stated. I think this may be
problematic so long as the colorspaces define the halfway conversion
to the reference ("linear") space. There may need to be some
additional option for defining the connection space if we expect to
use anything other than a straightforward colorimetric transform.

Version 0.5.9 (June 28 2010):
* Renamed project, classes, namespaces to OpenColorIO (OCIO)
* Added single-pixel processor path
* Improved python path makefile detection
* Continued GPU progress (still under development)

Agreed. The issue isn't how to do the conversion, it is how to
determine the input arguments.

But OCIO has this problem anyway. There is no definition for how a
given image can help influence what conversion is used. In a
commercial tool, the conversion is chosen by the user, where the list
of options is everything in the config.

OCIO has routines to do a conversion if the "conversion name" is
provided. OCIO could easily have routines to do conversions if the
gamma-matrix-gamma is provided. Either way, commercial tools have to
decide if the conversion hints come from the user, the filename, the
header, the environment, or whatever.

RGB

I thought of a simpler way to summarize the topic:

In dynamic colorspaces, the color transforms are dependent upon a set
of potentially changing input arguments.

Our ideal solution is one where the input argument handing is
standardized so that OCIO can be supported out of the box in
commercial tools. But, the logic that interprets input arguments would
be structured to allow the use of facility-specific code and
conventions.

-- Jeremy

Stefan,

This has been brought up before (previously by Rod), and it's a great question.

Thinking out loud...

From a purely technological standpoint, the API required to support a
dynamic color workflow is basically in place. Colorspaces can be
added, deleted, and modified at runtime. The only restriction is that
they need unique names, but thats an easy problem solve. (Also left is
to expose all of the transforms functions you'll need, but this is
easy).

But...

From a design standpoint this approach would have pipeline
implications. Any dynamic colorspace system would likely have custom
logic, and I'd have concerns about the portability of such a system.
My hope is to have support for OCIO in many applications (either as
plugins or natively) right out of the box, and wouldn't want
supporting dynamic colorspaces to throw a wrench in this plan.

So what are the possible implementations?

1) If you only rely on custom (facility specific) OCIO plugins, you
could use the embed the cleverness on your end, and use the existing
dynamic colorspace interface to make all the right things happen.
But this approach isn't ideal, as it would require each client to have
it's own implementation of the clever bits (or link against something
that does), and would prevent you from utilizing built-in OCIO support
in commercial apps. (Which, if OCIO succeeds, will be really
convenient).

2) Put ALL the intelligence in OCIO. Currently, if you have a
colorspace, you've got all you need to know about it. But... what if
colorspaces could have optional arguments? In your example, you could
define a single colorspace that had a section of it that was computed
based on the arguments. Chromaticities in, pixel processing out.

But this makes writing a generic plugin for OCIO much more difficult.
Consider our nuke support. Right now we have nodes that allow for
color space conversion in the comp graph, and custom read-write nodes
that use our colorspace processing instead of the built-in support.
The UI for both cases is essentially a list of strings (the colorspace
names) What would a plugin look like that supported dynamic
colorspaces arguments? The colorspace conversion node would have to
support dynamic parameters, and the artist would need an interface
more complicated than a popdown to deal with the (potentially
optional) options. (The args data could be endoded into a single
string, but this would not make it more artist friendly, probably less
so). I know of a few applications that support this level of plugin
interface customizability, but not many. Also, the read and write
nodes would need to be more complex, as they would be required to
parse the file metadata, and populate the colorspace args
appropriately. Though this task is not difficult, it is facility
convention specific and would require a customized plugin.

But we're going to have to tackle this issue anyways. In the current
SPI color system, while we don't use dynamic colorspaces (we chose to
avoid this for validation reasons), we do use dynamic Display
Transforms. Specifically, on visual effects shows, different shot /
sequences often have different artistic looks - specified by the DI
house - and it's incredibly useful to be able to plug these into our
pipeline. In a concrete example, we have Filmlooks that are constant
across a show, and ones that aren't. In our image viewer, you can
view images with "Film" - a generic look - or "Film Onset", which is a
shot varying look that encompasses onset viewing parameters as
manipulated by the client. It would be great if we could support both
systems (your dynamic colorspaces, and our dynamic viewing luts) with
one approach.

3) Why not a hybrid system? For example, I could envision a plug-in
system (which I previously denounced in a prior email), whose inputs
were a bunch of information (filename, file metadata, all environment
variables, etc), and a plugin had the opportunity to interpret this
information in a facility specific manner, and return a dynamically
constructed colorspace. Because the inputs to the custom logic were
on rails, the OCIO plugins could be standardized and have a chance to
work right out of the box, but there would also be a customizable API
that facility specific code could be written against. And, if you had
to send support for any custom part out of house, the dynamic
colorspaces could always be 'baked' to a non-plugin ocs system for
export.

This approach also feels cleaner because it would not require anyone
to agree on what the "right" mapping is (across facility, I mean).
In your example, what matrix will you use for the transform? It could
be a simple chromaticity mapping, but maybe some other facility would
need to support different white points, and thus would require a
chromic adaptation matrix. Or, maybe you're converting wide gamut P3
to r709, and gamut mapping must be considered... My point is that only
*you* know about the exact situational requirements for what transform
is most appropriate, so the code turning a set of primaries into an
explicit set of image processing operations is must be highly
configurable, and will likely be specific to the use cases you find
yourself working with. Another point for the hybrid plugin approach.


In terms of timeline, we're not quite at the point where I can look at
implementing a potential solution. I'm in middle of getting the GPU
chunk running, and after that will be paying attention to better
default configurations and adding additional client app support.
(which should put us near siggraph). But, after that I think it would
make sense to open this back up.

Is there some sort of really simple solution I'm missing? :)

-- Jeremy

Jeremy, what are your thoughts on supporting a color pipeline that
queries the files and/or workspace for color information and uses that
information to define the transformation to the reference space on the
fly, as opposed to predefining all spaces in the config.ocs? For
example, most of the images we (I) encounter can described by a basic
RGB model consisting of a 1d encoding function and 3x3 color matrix.
If they are all white-normalized, then the 3x3 matrix reduces to 4 x,y
chromaticity pairs (RGBW). If it is possible, I would like to be able
to handle all images that fall into this category with a single
transformation that takes in a set of image dependent color
parameters, as opposed to enumerating every possible case we might
encounter in the config.ocs.

The new name is approved, OpenColorIO it is.

Both github and the google group appear to allow project renaming,
please email me directly if you can't find the group again.

http://groups.google.com/group/ocio-dev/

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