|
Re: Slack invite
remia...@...
Hello, I'd like to join too : remia...@... Thanks !
On Monday, December 18, 2017 at 5:08:56 PM UTC+1, Sean Wallitsch wrote:
|
|
|
|
Re: Converting Primaries
Troy Sobotka <troy.s...@...>
Convert the xy coordinates to XYZ, with red being the first column, then green, then blue. That forms a 3x3 matrix for taking linearized RGB to the XYZ domain.
toggle quoted messageShow quoted text
From there you would need to perform a chromatic adaptation via Bradford or CAT02 to the AP1 or AP0 white point required. The final matrix would be from XYZ, achromatic point aligned, to AP1 or AP0 RGB, which are well documented. With respect, TJS
On Wed, Mar 7, 2018, 8:20 AM Markel <markel.j...@...> wrote:
|
|
|
|
"pure virtual method called" crash when developing nuke OP plugin with OCIO
Yanli Zhao <yanli...@...>
Hi All, I'm a new to both Nuke and OCIO. For some reason, I need to develop a nuke OP similar to OCIOFileTransform. But when I add just one simple line such as "OCIO::GetCurrentConfig()",
I got a crash with the terrible "Pure Virtual method called" error. I was
wondering that maybe I was linking the wrong version of OCIO. Has anyone
met with similar issues? I'm developing plugin for Nuke 10.0v5 with
OCIO 1.0.9.
|
|
|
|
Pure Virtual Function crash when developing a nuke OP with OCIO / OpenColorIO API
Yanli Zhao <yanli...@...>
Hi, For some reason, I need to write a pixelOp similar to OCIOFileTransform with OCIO API. But when I add just one simple line such as "OCIO::GetCurrentConfig()", I got a crash with the terrible "Pure Virtual Function" error. I was wondering that maybe I was linking the wrong version of OCIO. Has anyone met with similar issues? I'm developing plugin for Nuke 10.0v5 with OCIO 1.0.9 on Linux. Apple
|
|
|
|
Support of the Java interface
Patrick Hodoul <patric...@...>
Hi all, I would like to know if OCIO java public interface is used? and should be maintained ? OCIO currently supports three public interfaces: 1) The native C++, 2) The Python interface (built on top of the C++ one), and 3) the Java one (built on top of of the C++ one) It seems that Java interface is not so much used by tools. My 2 cents... Any feedbacks ? Regards, Patrick.
|
|
|
|
Re: 1.1.0 Release
Sean Cooper <se...@...>
Version 1.1.0 has just been released and is located on the "RB-1.1" branch for long-term support. Please continue to evaluate and we will release patches as necessary. Thanks!
On Fri, Jan 12, 2018 at 1:47 PM, Richard Shaw <hobbe...@...> wrote:
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
Crap, never mind again... Richard
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
Ok, I spoke too soon, this doesn't look like a missing package problem: ! Package babel Error: You haven't specified a language option. See the babel package documentation for explanation. Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
I'm getting it figured out... It's missing texlive packages but I don't want to install EVERYTHING because there's tons of packages, so I'm having to find what's missing one at a time and keep trying to build. Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
On Fri, Jan 12, 2018 at 6:48 AM, Sean Cooper <se...@...> wrote:
In my previous email I pasted the output from building the pdf documentation. For some reason pdflatex is getting to an interactive prompt which is of course bad when trying to build a package :) Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Sean Cooper <se...@...>
What issues are you having with the documentation?
On Jan 12, 2018 12:44 PM, "Richard Shaw" <hobbe...@...> wrote:
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
On Fri, Jan 12, 2018 at 4:57 AM, Sean Cooper <se...@...> wrote:
Yes, this is with the PR already being applied as a patch, I appear to only be having issues with building the documentation. I can disable that but I would hate to release a new package without the documentation when the previous one had it... Is it just the extended documentation that I would be missing? Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Sean Cooper <se...@...>
Richard, have you tested Patrick's PR for the GCC fixes? I'm looking to release today and don't want to slot in unnecessary commits to the release, they have already been merged to master so will show up in OCIO 1.1.1 down the road. Let me know you thoughts
On Fri, Jan 12, 2018 at 12:28 AM, Richard Shaw <hobbe...@...> wrote:
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
Ok, so I "fixed" it by adding --install-dir to all the python external projects but now I run into this: [ 61%] Building pdf doc cd /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/docs/build-latex && /usr/bin/pdflatex OpenColorIO.tex This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdflatex) restricted \write18 enabled. entering extended mode (./OpenColorIO.tex LaTeX2e <2016/03/31> Babel <3.9r> and hyphenation patterns for 3 language(s) loaded. (./sphinxmanual.cls Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual) (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls Document Class: report 2014/09/29 v1.4h Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo kpathsea: Running mktextfm cmr10 /usr/share/texlive/texmf-dist/web2c/mktexnam: Could not map source abbreviation for cmr10. /usr/share/texlive/texmf-dist/web2c/mktexnam: Need to update ? mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input cmr10 This is METAFONT, Version 2.7182818 (TeX Live 2016) (preloaded base=mf) kpathsea: Running mktexmf cmr10 ! I can't find file `cmr10'. <*> ...e:=ljfour; mag:=1; nonstopmode; input cmr10 Please type another input file name ! Emergency stop. <*> ...e:=ljfour; mag:=1; nonstopmode; input cmr10 Transcript written on mfput.log. grep: cmr10.log: No such file or directory mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input cmr10' failed to make cmr10.tfm. kpathsea: Appending font creation commands to missfont.log. ! Font OT1/cmr/m/n/10=cmr10 at 10.0pt not loadable: Metric (TFM) file not found . <to be read again> relax l.54 \normalsize ? And it pauses there waiting for input, which is bad of course since it should be non-interactive. Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
On Wed, Jan 10, 2018 at 7:23 PM, Patrick Hodoul <patric...@...> wrote:
Yeah, I've thought about it. I actually added most of the USE_EXTERNAL... stuff when I first got OCIO in Fedora but I have far fewer free cycles these days. Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Patrick Hodoul <patric...@...>
On Wednesday, January 10, 2018 at 4:40:41 PM UTC-5, Richard wrote:
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
I think that's because ubuntu uses debian's scheme instead of /usr/lib{,64} like RPM based distros. Either way, there's still the question about why the system installed setuptools isn't used... Thanks, Richard
|
|
|
|
Re: 1.1.0 Release
Patrick Hodoul <patric...@...>
double-checked using the ubuntu 16 & gcc 5.4.0 docker image and setuptools is working fine.
On Tuesday, January 9, 2018 at 10:23:15 AM UTC-5, Richard wrote:
|
|
|
|
Re: 1.1.0 Release
Richard Shaw <hobbe...@...>
Ok, next error, setuptools is built thinking it needs /usr/lib but installs to /usr/lib64 (as it should) and then it gets confused. Side question: Why do we have to build a bundled setuptools instead of using what's available, at least on linux? Thanks, Richard creating build/lib/setuptools copying setuptools/dist.py -> build/lib/setuptools copying setuptools/script template (dev).py -> build/lib/setuptools copying setuptools/depends.py -> build/lib/setuptools copying setuptools/package_index.py -> build/lib/setuptools copying setuptools/archive_util.py -> build/lib/setuptools copying setuptools/compat.py -> build/lib/setuptools copying setuptools/ssl_support.py -> build/lib/setuptools copying setuptools/py27compat.py -> build/lib/setuptools copying setuptools/sandbox.py -> build/lib/setuptools copying setuptools/py26compat.py -> build/lib/setuptools copying setuptools/version.py -> build/lib/setuptools copying setuptools/py24compat.py -> build/lib/setuptools copying setuptools/__init__.py -> build/lib/setuptools copying setuptools/site-patch.py -> build/lib/setuptools copying setuptools/extension.py -> build/lib/setuptools copying setuptools/script template.py -> build/lib/setuptools creating build/lib/_markerlib ... [ 31%] Performing install step for 'setuptools' cd /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/src/core_tests && /usr/lib64/ccache/c++ -DOCIO_SOURCE_DIR=/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1 -DOCIO_UNIT_TEST -DOpenColorIO_STATIC -DUSE_SSE -I/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/export -I/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/export -I/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/ext/oiio/src/include -I/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/ext/dist/include -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2 -msse2 -O2 -g -DNDEBUG -DTIXML_USE_STL -fPIC -fvisibility=hidden -o CMakeFiles/ocio_core_tests.dir/__/core/GpuShaderUtils.cpp.o -c /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/src/core/GpuShaderUtils.cpp cd /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/docs/setuptools-prefix/src/setuptools && PYTHONPATH=/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/ext/dist/lib64/python2.7/site-packages: python setup.py install --prefix=/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/ext/dist ... TEST FAILED: /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/ext/dist/lib/python2.7/site-packages/ does NOT support .pth files error: bad install directory or PYTHONPATH You are attempting to install a package to a directory that is not on PYTHONPATH and which Python does not read ".pth" files from. The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/ext/dist/lib/python2.7/site-packages/ and your PYTHONPATH environment variable currently contains: '/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/build/ext/dist/lib64/python2.7/site-packages:' Here are some of your options for correcting the problem: * You can choose a different installation directory, i.e., one that is on PYTHONPATH or supports .pth files * You can add the installation directory to the PYTHONPATH environment variable. (It must then also be on PYTHONPATH whenever you run Python and want to use the package(s) you are installing.) * You can set up the installation directory to support ".pth" files by using one of the approaches described here: Please make the appropriate changes for your system and try again.
|
|
|
|
Re: 1.1.0 Release
Patrick Hodoul <patric...@...>
Please have a look to PR #498 to have the standalone fix (for gcc 5.4.0)
On Sunday, January 7, 2018 at 9:37:50 PM UTC-5, Patrick Hodoul wrote:
|
|
|