The above code gives me black pixels even if the lut3dTex is filled with values of 1.0 so there must be a problem with the usage of the 3dtexture and Qt.

Thanks Patrick, you are right, the result of the log is black because the values are negative, it works correclty.. stupid me. So it has something to do with the lookup table. Is there any way to

Hi, As a first investigation step, did you try using `ociodisplay` directly (i.e. as-is): `set OCIO=C:/daten/coding/imgview/imgView/AE_OCIO/config.ocio` `ociodisplay.exe -v

Found a possible reason for the black image. In the fragment shader code generated by ocio which look like this: vec4 OCIODisplayA(vec4 inPixel, sampler3D lut3d){ vec4 out_pixel =

Hi, I try to make a simple imageviewer with the help of QT and ocio. From the ociodisplay.cpp I tried to extract the needed pieces and transfer it to a Qt workflow. Displaying pictures with OpenGl

That's great news, thank you !

I'm currently writing new Python bindings for OCIO (with pybind11, targeting the 2.0 release), which will support Python 3 (and 2). Stills a ways to go, but it's in the works.

Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows. I tested with both OCIO 1.1 and OCIO 2.0 (master

Cancelled: OpenColorIO TSC meeting (weekly) This event has been cancelled. When: Monday, 14 October 2019 9:30am to 10:00am (UTC-07:00) America/Los

Thanks for the update Michael, That all makes sense. I saw that assignment bug and got worried that cut wasn't something I should really consider. Looking forward to 2.x. Cheers, - James

Hi James, OCIO 1.1.1 should compile if you tell your compiler to not treat warnings as errors, or pass a flag to ignore that particular warning. That warning was resolved in master a while back, but

Hi, I was trying to pick a more modern version of OCIO than the one I've been using (1.0.9) so I started at the latest at the old download location https://opencolorio.org/downloads.html with v1.1.1.

Sean, thank you for the detailed and well thought out proposal. I fully support it but agree the versioning plan needs some more discussion. Given that OCIO v2 has some features that are

The descriptions and release notes definitely needed some love, but since it was just a draft proposal I didn't put that effort in. I also think the release names could be better as

Maybe we keep the tags as they are but create smaller amount of explicit releases with good descriptions of what they are? Users will most likely look for releases anyway.

The dual version numbers is pretty gross, but I'm not sure how else you can have two independent versions tracked. Unless we just don't care about having independent ACES Config releases, and only

@Sean: I'm not saying we should remove them, but just clean up the stack: e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0? Thomas Mansencal - colour-science.org - thomasmansencal.com

@Deke The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible. I'd

Hi Deke, To be fair, at this stage, I don't think it hurts to leave them as they are. To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do

Comments on II #3 Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the