---- Commenter 1

This all looks really cool. I don't know what your budget for
getting this ready for a wider world is, but you may want to consider
removing the STL from the code. Some people are very particular about
what parts of the C++ standard they use. Also, you may want to
reconsider throwing exceptions. The API is very nice, I'd be happy to
call this code.

---- Jeremy

Thanks!

Does anyone else have concerns with the API being C++ (as opposed to
pure C)? My inclination is to leave it as C++ for now as most of the
initial apps / plugin APIs we're targeting right off the bat support C+
+. And, I think the average user probably won't be looking at the code
very often. My hope is that they'll follow some simple steps to
install the library and any associated plugins they care about, and
wont have to think about the language at all. I also think switching
to a pure C API may be a bit more work than I'd prefer at this
stage. OpenEXR solves this in a clever manner, with it's
ImfCRgbaFile.h compatibility header. Should it prove useful, we could
always add a C wrapper layer in that vein.

How do people feel about exceptions? I'm comfortable with them, but I
understand that many teams avoid using them. I would be happy to swap
out an exception approach with a success / fail return code if people
prefer. (The disadvantage being that good error reporting is harder
in these cases - you can always use a get/set errorstring approach,
but I've never loved that in a multi-thread environment).

---- Commenter 2

Adding some more applications:
- Adobe CS (Photoshop. Aftereffects, etc) (ICC profiles)
- Pixar Renderman 'It' viewer (Truelight ASCII .cub 3D lut)
- Assimilate Scratch (Arri /Kodak .3dl)
- Iridas Framecycler (Iridas .cube)
- Autodesk (MESH3D, .lut, etc.)

And for completeness (not sure if all of these make sense):
-Avid Media Composer
-Final Cut Pro
- OpenFX (plugin API) "

---- Jeremy

Good format additions, I'll add those to the FAQ. (Which I will resend
or turn into a google doc once enough updates accumulate). None these
sound difficult to support, particularly if people are open to sending
me format examples / docs. We already have basic support for
exporting ICC profiles and import .3dl support. (Though I thought .
3dl was an autodesk format, am I mistaken? probably...)


---- Commenter 2

Assuming tier 1 and 2 support for 3rd party applications are handled
by linking against commercial libraries, my vote is for the core
library to be the default built target. Requiring the developer to
explicitly list the packages for which 3rd party support is required,
eg:

configure --with-nuke=/usr/lib/nuke6 --with-rv=/usr/lib/rv

...would allow a single invocation of 'make' to build the plugins for
which the necessary libraries are present.

Code that may have proprietary library dependencies should live
alongside (not in) the main library:

colorlib-
|-common-
| |-include
| |-lib
|
|-3rd_party_plugins
|-foundry-
| |-nuke
|
|-apple-
|-shake
|-finalcut

Wrapping multiple 'product' directories under 'vendor' directories
addresses the case of some vendors that have inconsistent APIs across
products (autodesk, apple).

---- Jeremy

I'm just starting to think about the build system but this sounds like
a good approach. I shall use it for now.

My hope is also, to the extent possible, to provide pre-built
libraries and plugins. libstdc++ will likely be the biggest
dependency for linux, so we should be able to compile only a few
architectures and hit the major platforms, right? (I may be wrong
here though).


---- Commenter 2

Providing multiple levels of service:

Considering that small or offshore VFX facilities may not have
resources to compile plugins from source, it might be nice for the
library to be able to provide a lower level of service than the one it
is capable of delivering -- eg, an exporter of LUTs for use in an
application's native Lookup plugin.

In fact, even some medium-to-large facilities might elect to use the
library in 'tier-3' mode as a 'universal translator' for generating
show-specific LUTs for a range of 3rd party products (at the expense
of some lost accuracy).


---- Jeremy

Sure. I like this idea of providing lut exporters for as many formats
as possible. With the python API, these are really easy to write.


--
Subscription settings: http://groups.google.com/group/ocs-dev/subscribe?hl=en