Re: Development Priorities?

srluka <srl...@...>

Hello Jeremy,

I would like to see OCIO grow into a library that can handle all our
color transformations. I can see it being used in the current xml'ized
form within our production environment to keep the color options well-
defined, but still want the eventual capability for dynamic color
transformations. Performance for realtime playback is also important
to us.

With that in mind, here are my top five:

- Developer API Docs
- Color Config Authoring Docs
- Overall performance optimization
- Dynamic Color API
- OpenImageIO


On Sep 16, 8:36 am, Marie Fétiveau <m....@...> wrote:
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 !


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.
On Sep 15, 4:49 pm, Alan Jones <sky...@...> wrote:
Hi Jeremy,
On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@...>
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.

Join to automatically receive all group messages.