I tend to agree on the per-colourspace concept, given that OCIO cannot deduce between a well-defined colourspace and an EOTF etc. What *is* required is a method to query metadata about the reference,

Hi, I came across this thread. Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I

Hi, I know it is an old question but I could not find a working solution. Is there a walkthrough to build OCIO including PyOpenColorIO on Windows? Or something precompiled that might work? My current

This is timely, I was going to raise the issue of whether it's appropriate for OCIO to be colorimetry intelligent or not. Where OCIO would define the chromaticites per colorspace, as Malcolm

I loved this idea when Mark originally hinted at it at SIGGRAPH, but frankly, it would probably require some deeper sculpting unless someone can figure out an elegant solution for the parser on each

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace. Question would be would this just be metadata or actually used to

Greetings all. Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO? Currently it is

I noticed that OCIO is used in Nuke for CDL exports. Are there any other programs apart from Nuke that create CDLs from matched grades? I was looking through the OCIO code and didn't see any code

I think it would be very interesting to take a look at an OpenCL OCIO implementation. It seems like: #304, #396, + Kevin's CDL parse, would be easy first steps to get these creaky joints moving

Nathan and others interested, I've attached a PDF describing our OpenCL extensions to OpenColorIO. An accurate OpenGL path would do something very similar with multiple shader parameters, and would

> Dennis, is your fork containing the OpenCL code path available to browse currently? Nathan, no, but I could put something together for you if you'd like to review it. ///d@

+1 to Dennis's offer of fixed GPU path code, fixing the banding issue would be fantastic! I can pitch in with testing and code review if that helps. I too would love to see what DNeg has been up to,

Erlang, wow. That .travis.yml looks like it dates from when dinosaurs roamed the earth. Having recently set it up for OIIO and OSL, perhaps I can take a stab at it. -- Larry Gritz l...@...

I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps. Larry we did setup a very basic travis file back in 2012 but it

Once again, thanks for chiming in everyone. It's definitely encouraging to see. Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that

I'd like to also support Larry's suggestions, especially the prioritisation/grouping of issues and using CI. From my work point of view I'd like to see anything relating to image quality near the

Very happy to see this thread. I don't have a lot to add, other than my support for the direction Larry outlined. Also, thanks for kicking this thread off, Nathan! The one thing I do want to add is

Apologies for the name similarity Sean, people were very excited for your return when they heard I was starting haha.

Been lurking but glad to see a clearly outlined direction. Also trying not to be mistook as Sean Cooper. Sean Looper

Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-) It has never been SPI's intention to abandon this project, and we definitely want to continue having a