Folks,

If you're considering using OpenColorIO in the near term, we would
greatly appreciate it if you would respond and let us know which of
the topics below you personally consider to be most important.
Perhaps reply with the top 5 items you care about?

(Note: We plan on addressing all of these issues, but would love to
get a sense of what's holding people up in the short term).

If there's an important task that isn't represented on this list, please
add it!

Thanks!

-- Jeremy

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



Fall 2010 OpenColorIO Development Topics:

Documentation
- Quickstart Guide
- End User (Artist) Docs
- Developer API Docs
- Color Config Authoring Docs

Facility Integration
- Support for additional lut formats (import)
- Support for lut export
- 3rd party app plugins
RV
OFX
OpenImageIO
Houdini
<Your App Here!>

"Real" Color Configurations
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Add a example ACES ocio config
- Add a config that emulates the default nuke color configuration
- Add example color config authoring scripts
- Document 'best practice' for each config, and provide workflow
examples with imagery

Core Library:
- Unit testing / correctness validation
- Overall performance optimization

Issues deferred until after 1.0 (tentatively Jan '11):
- Dynamic Color API (OCIO Plugin API)
- Live CDL Support

Hi Jeremy,

On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@...> wrote:

Perhaps reply with the top 5 items you care about?

The top five for me would be as follows.

1) API Documentation (the classes and how the pieces are supposed to
work together - I guess that may count as config documentation)
2) LUT export
3) Unit testing (this kinda should be number one, but I'm trying to be
somewhat pragmatic)
4) Color config authoring docs
5) Additional LUT formats

I'd say for now the biggest thing holding me back on OIIO is there is
no big picture documentation. I don't really know how OCIO is intended
to work and what all the pieces are. I can try piece it together from
the code, but a document covering intended structure would make both
using it and identifying areas to provide meaningful contribution much
easier. The reason I say big picture rather than purely API is I'm
thinking not just of the API for how to access it, but how it's
intended to work within a pipeline.

Cheers,

Alan.

Hello Jeremy and all !

I don't have much time to focus on OCIO now but soon or late I will...;)

And when that day will come, I'll be happy to find :
- Developer API Docs
- Color Config Authoring Docs
- Add a example ACES ocio config
- End User (Artist) Docs
- Live CDL Support

Thanks !

Marie



On Thu, Sep 16, 2010 at 1:39 AM, Est <rame...@...> wrote:

Hi Jeremy,

I'm currently adding OpenColorIO support to my compositor.

My list would be:

- End User (Artist) Docs
- Developer API Docs
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Color Config Authoring Docs
- Add example color config authoring scripts

I can port the existing Colorspace and Display Nuke plugins to OFX
if there is interest. Just let me know.

Est.

On Sep 15, 4:49 pm, Alan Jones <sky...@...> wrote:

Hi Jeremy,

On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@...>

wrote:

Perhaps reply with the top 5 items you care about?

The top five for me would be as follows.

1) API Documentation (the classes and how the pieces are supposed to
work together - I guess that may count as config documentation)
2) LUT export
3) Unit testing (this kinda should be number one, but I'm trying to be
somewhat pragmatic)
4) Color config authoring docs
5) Additional LUT formats

I'd say for now the biggest thing holding me back on OIIO is there is
no big picture documentation. I don't really know how OCIO is intended
to work and what all the pieces are. I can try piece it together from
the code, but a document covering intended structure would make both
using it and identifying areas to provide meaningful contribution much
easier. The reason I say big picture rather than purely API is I'm
thinking not just of the API for how to access it, but how it's
intended to work within a pipeline.

Cheers,

Alan.