Bruno Nicoletti <bruno.j....@...>
thanks for the reply. A few more questions....
These reference various .spiXXX files, are you going to open up the- how do you representPlease see the file config_v0.ocs, you will see examples of all 3.
format of those files?
Little CMS was the one mumbled about here. Not sure how important this- any open source ones?What open source lut formats are you referring to?
is, need to get back to our folks.
By some sort of plugin method, you mentioned this in your reply withAre you looking at making it extensible?Not sure what you mean here. Anyone can add or create a custom
respect to proprietary CMS systems.
I'd simply say you couldn't process while manipulating the the configuration.What level of thread safety is there?The library is fully thread safe. (and efficient in a multi-thread
We are playing with OpenCL and it might be useful to have that at some- have you thought about OpenCL code generation?Not yet. Are you interested in opengl?
point. Not a high priority for us at the moment.
Sorry, 'XFM' is my bizarre short hand for 'transform', but that stillAre you shipping it with any vanilla XFMs that you have created atWhat's an XFM? A configuration I presume? (im now calling them .ocs
I suppose what we are missing are use cases of the library in
practice. I have a pretty good guess as to how it would work at big
film houses, film houses collaborating and film houses sharing work
with smaller shops, but clear descriptions of that would be great.
I guess my major concern is that if The Foundry is using this as the
basis of a cross product CMS, we still need to make it work for the
small shops in isolation, and they need tools to do at least the basic
stuff that the big boys have in-house specialist do. So display
calibration profiles and so on. Have you had any thoughts as to that?