1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
Re: Homebrew version of OCIO not bringing all apps ...

Liam <liamfe...@...>
 

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam


On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg


On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
Re: Homebrew version of OCIO not bringing all apps ...

Larry Gritz <l...@...>
 

I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg


On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
Re: Homebrew version of OCIO not bringing all apps ...

bsloan <bsl...@...>
 

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake
Re: Homebrew version of OCIO not bringing all apps ...

Deke Kincaid <dekek...@...>
 

fyi homebrew/science has been deprecated.  Luckily they migrated oiio/ocio into homebrew/core (default repo).

On Thu, Jun 28, 2018 at 4:34 AM Haarm-Pieter Duiker <li...@...> wrote:
That’s the correct approach. The build steps from the readme are copied below. 

HP

Building on Mac OSX

Use the following commands to build these packages on Mac OSX

  • OpenColorIO
    • brew install -vd opencolorio --with-python
  • Update the homebrew repository of install scripts to make sure that OpenImageIO is included.
    • brew tap homebrew/science
  • Optional Dependencies for OpenImageIO
    • brew install -vd libRaw
    • brew install -vd OpenCV
  • OpenImageIO
    • brew install -vd openimageio --with-python
  • CTL
    • brew install -vd CTL
  • OpenColorIO, a second time. ociolutimage will build with openimageio installed.
    • brew uninstall -vd opencolorio
    • brew install -vd opencolorio --with-python

On Wed, Jun 27, 2018 at 10:27 PM Michael Dolan <mich...@...> wrote:
To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own. 

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Re: Homebrew version of OCIO not bringing all apps ...

Haarm-Pieter Duiker <li...@...>
 

That’s the correct approach. The build steps from the readme are copied below. 

HP

Building on Mac OSX

Use the following commands to build these packages on Mac OSX

  • OpenColorIO
    • brew install -vd opencolorio --with-python
  • Update the homebrew repository of install scripts to make sure that OpenImageIO is included.
    • brew tap homebrew/science
  • Optional Dependencies for OpenImageIO
    • brew install -vd libRaw
    • brew install -vd OpenCV
  • OpenImageIO
    • brew install -vd openimageio --with-python
  • CTL
    • brew install -vd CTL
  • OpenColorIO, a second time. ociolutimage will build with openimageio installed.
    • brew uninstall -vd opencolorio
    • brew install -vd opencolorio --with-python

On Wed, Jun 27, 2018 at 10:27 PM Michael Dolan <mich...@...> wrote:
To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own. 

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Re: Homebrew version of OCIO not bringing all apps ...

Larry Gritz <l...@...>
 

We should find a way to fix this cyclic dependency once and for all.

-- lg


On Jun 27, 2018, at 10:16 PM, Michael Dolan <mich...@...> wrote:

To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own. 

--
Larry Gritz
Re: Homebrew version of OCIO not bringing all apps ...

Michael Dolan <mich...@...>
 

To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own. 

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Re: how to write .cube luts?

Patrick Hodoul <patric...@...>
 

Just to highligth that ocio is expecting 'Red first' 3D luts.
Re: how to write .cube luts?

Dithermaster <dither...@...>
 

How does a 3D LUT work? Each numeric row has three entries, which represent R, G, and B output values, often 0.0 to 1.0 (but could be higher or negative for some cases).
Each row represents a position in the 64x64x64 input cube. The input R,G,B value (sometimes after running through a lg2 "shaper" if it is linear) gets multiplied by 63 (in the case of a 64x64x64 cube) and rounded to the nearest integer. Then the row number of r*64*64 + g*64 + b. For example, input of rgb={0.1, 0.2, 0.3} becomes rgb_index={6.3, 12.6, 18.9} which become rgb_index_int={6, 13, 19} which is row index 6*64*64 + 13*64 + 19 = 25427, if you are looking for the nearest element. It's actually more complex than that since tri-linear or tetrahedral interpolation is used, which means 8 or 4 elements surrounding the 3D position are looked up and interpolated to create the output RGB value.

///d@




On Wed, Jun 27, 2018 at 12:03 PM mc <michael...@...> wrote:
I've been searching for weeks and can't find a clear explanation of how
.cube files are written. Please help me understand them.

I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?

Thanks.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Re: how to write .cube luts?

Santiago Svirsky <radi...@...>
 

maybe multiply by 63 instead?


On Wed, Jun 27, 2018 at 1:03 PM mc <michael...@...> wrote:
I've been searching for weeks and can't find a clear explanation of how
.cube files are written. Please help me understand them.

I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?

Thanks.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
how to write .cube luts?

mc <michael...@...>
 

I've been searching for weeks and can't find a clear explanation of how .cube files are written. Please help me understand them.

I have a .cube file that was generated with 3D Lut Creator, with an image source of a HALD color image (64x64x64). No adjustments were applied to the image, so the .cube file should show input=output. But the decimal values in the lookup table mystify me. How were they generated? The decimal values, when multiplied by 64, do round to a number close to list position in the (64 64 64) list, but surely there's a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't really know the language. I want to write luts in Java. Can someone there help me?

Thanks.
Re: v1.1.0 compile problem with g++ 7.3.0

Patrick Hodoul <patric...@...>
 

Another option could be to use the installed yaml (instead of the OCIO one) with  USE_EXTERNAL_YAML


On Friday, June 15, 2018 at 9:30:41 AM UTC-4, Patrick Hodoul wrote:
Hi Jan,

According to the gcc documentation (Warning-Options), you could disable the warning with -Wno-deprecated-declarations

Patrick.

On Thursday, June 14, 2018 at 12:23:01 PM UTC-4, Jan Walter wrote:
Hi,

I tried to compile OCIO version 1.1.0 on a Debian based distro using g++ 7.3.0:

$ cat /etc/debian_version
buster/sid
$ g++ --version
g++ (Debian 7.3.0-11) 7.3.0

I get error messages related to "-Werror=deprecated-declarations".

Here is the first one:

$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/ocio ~/git/github/OpenColorIO
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
...
/home/jan/git/github/OpenColorIO/ociobuild/ext/dist/include/yaml-cpp/parser.h:46:8: error: ‘template<class> class std::auto_ptr’ is deprecated [-Werror=deprecated-declarations]
   std::auto_ptr<Scanner> m_pScanner;
        ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/c++/7/tr1/memory:39,
                 from /home/jan/git/github/OpenColorIO/ociobuild/export/OpenColorABI.h:63,
                 from /home/jan/git/github/OpenColorIO/export/OpenColorIO/OpenColorIO.h:38,
                 from /home/jan/git/github/OpenColorIO/src/core/OCIOYaml.cpp:31:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
In file included from /home/jan/git/github/OpenColorIO/ociobuild/ext/dist/include/yaml-cpp/yaml.h:8:0,
                 from /home/jan/git/github/OpenColorIO/src/core/OCIOYaml.cpp:75:

Any ideas how to make this work?

Thanks,

Jan
Re: v1.1.0 compile problem with g++ 7.3.0

Patrick Hodoul <patric...@...>
 

Hi Jan,

According to the gcc documentation (Warning-Options), you could disable the warning with -Wno-deprecated-declarations

Patrick.


On Thursday, June 14, 2018 at 12:23:01 PM UTC-4, Jan Walter wrote:
Hi,

I tried to compile OCIO version 1.1.0 on a Debian based distro using g++ 7.3.0:

$ cat /etc/debian_version
buster/sid
$ g++ --version
g++ (Debian 7.3.0-11) 7.3.0

I get error messages related to "-Werror=deprecated-declarations".

Here is the first one:

$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/ocio ~/git/github/OpenColorIO
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
...
/home/jan/git/github/OpenColorIO/ociobuild/ext/dist/include/yaml-cpp/parser.h:46:8: error: ‘template<class> class std::auto_ptr’ is deprecated [-Werror=deprecated-declarations]
   std::auto_ptr<Scanner> m_pScanner;
        ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/c++/7/tr1/memory:39,
                 from /home/jan/git/github/OpenColorIO/ociobuild/export/OpenColorABI.h:63,
                 from /home/jan/git/github/OpenColorIO/export/OpenColorIO/OpenColorIO.h:38,
                 from /home/jan/git/github/OpenColorIO/src/core/OCIOYaml.cpp:31:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
In file included from /home/jan/git/github/OpenColorIO/ociobuild/ext/dist/include/yaml-cpp/yaml.h:8:0,
                 from /home/jan/git/github/OpenColorIO/src/core/OCIOYaml.cpp:75:

Any ideas how to make this work?

Thanks,

Jan
v1.1.0 compile problem with g++ 7.3.0

jdb.w...@...
 

Hi,

I tried to compile OCIO version 1.1.0 on a Debian based distro using g++ 7.3.0:

$ cat /etc/debian_version
buster/sid
$ g++ --version
g++ (Debian 7.3.0-11) 7.3.0

I get error messages related to "-Werror=deprecated-declarations".

Here is the first one:

$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/ocio ~/git/github/OpenColorIO
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
...
/home/jan/git/github/OpenColorIO/ociobuild/ext/dist/include/yaml-cpp/parser.h:46:8: error: ‘template<class> class std::auto_ptr’ is deprecated [-Werror=deprecated-declarations]
   std::auto_ptr<Scanner> m_pScanner;
        ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/c++/7/tr1/memory:39,
                 from /home/jan/git/github/OpenColorIO/ociobuild/export/OpenColorABI.h:63,
                 from /home/jan/git/github/OpenColorIO/export/OpenColorIO/OpenColorIO.h:38,
                 from /home/jan/git/github/OpenColorIO/src/core/OCIOYaml.cpp:31:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
In file included from /home/jan/git/github/OpenColorIO/ociobuild/ext/dist/include/yaml-cpp/yaml.h:8:0,
                 from /home/jan/git/github/OpenColorIO/src/core/OCIOYaml.cpp:75:

Any ideas how to make this work?

Thanks,

Jan
Homebrew version of OCIO not bringing all apps ...

Abraham Schneider <abraham....@...>
 

I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own. 
Re: no function in (Python) API to get colorspace of defined role?

Abraham Schneider <abraham....@...>
 

Seems to work, thanks. Not quite obvious from the documentation, especially if you only look at the API docs and not the user guide first.

Am Montag, 28. Mai 2018 16:39:02 UTC+2 schrieb Sean Cooper:

Not at a computer to verify, but I believe you can just do a getColorspace() call using the user defined or default roles, the query the name of the returned object. Role names are equivalent to color space names. Its a bit obtuse I must admit.

On Mon, 28 May 2018, 3:21 pm Abraham Schneider, <abrah...@...> wrote:
Just had a look in the Python API and wondered how I could get the referenced colorspace of a named role. Some of the roles are predfined as constants (OCIO.Constants.ROLE_...), but what's with user defined roles? So for example the compositing_linear one in the ACES config, or a self defined one?

Shouldn't there be just an easy function like 'getRole(rolename)' that just gives back the name of the colorspace that the role is linking to!?

Really confused at the moment on how to use roles via API.

Thanks!

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: no function in (Python) API to get colorspace of defined role?

Sean Cooper <se...@...>
 

Not at a computer to verify, but I believe you can just do a getColorspace() call using the user defined or default roles, the query the name of the returned object. Role names are equivalent to color space names. Its a bit obtuse I must admit.


On Mon, 28 May 2018, 3:21 pm Abraham Schneider, <abraham....@...> wrote:
Just had a look in the Python API and wondered how I could get the referenced colorspace of a named role. Some of the roles are predfined as constants (OCIO.Constants.ROLE_...), but what's with user defined roles? So for example the compositing_linear one in the ACES config, or a self defined one?

Shouldn't there be just an easy function like 'getRole(rolename)' that just gives back the name of the colorspace that the role is linking to!?

Really confused at the moment on how to use roles via API.

Thanks!

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
no function in (Python) API to get colorspace of defined role?

Abraham Schneider <abraham....@...>
 

Just had a look in the Python API and wondered how I could get the referenced colorspace of a named role. Some of the roles are predfined as constants (OCIO.Constants.ROLE_...), but what's with user defined roles? So for example the compositing_linear one in the ACES config, or a self defined one?

Shouldn't there be just an easy function like 'getRole(rolename)' that just gives back the name of the colorspace that the role is linking to!?

Really confused at the moment on how to use roles via API.

Thanks!
Re: Which colorspace is used as the reference space for an OCIO config?

Haarm-Pieter Duiker <li...@...>
 

Hey,

I came to the same conclusion. I had thought the first colorspace was the special ‘reference’ colorspace (pretty sure Jeremy told me that...), but there is nothing in the code enforcing or depending on that. As long as all the colorspace’s to and from transforms go to and from the same _implied_ reference colorspace, then the reference colorspace is effectively defined. 

If you have a colorspace with no to or from transform list, which had better be what you think of as your reference space, it can at the front of the list, the end, or anywhere in between. 

I think it is a good convention to 
- have a colorspace definition with no to or from transform lists to make the reference colorspace definition explicit
- have that be the first colorspace
- have the ‘reference’ role to point to that colorspace

All that said, these are currently suggested conventions. They aren’t hard requirements. I’d be in favor of making them hard requirements for a well formed config. 

HP



On Fri, Apr 20, 2018 at 4:06 PM Dithermaster <dither...@...> wrote:
I've read the source. I didn't see anything special about the "first" colorspace. Unless someone can show me (either in the code or by an API call example) where it is somehow special, I won't believe it.

///d@


On Fri, Apr 20, 2018 at 5:58 PM, <chris....@...> wrote:
Hi folks-

H.P., I also agree with that definition. But - it's also true that if you are converting to or from the 1st colorspace in the config list (aka "Reference" colorspace) we should see the to_reference or from_reference transform (or inverse as-needed) applied alone. More specifically, we don't need to explicitly convert from colorspace A to Reference colorspace, then from Reference colorspace to colorspace B because the conversion from Reference to Reference is a non-op. So the OCIO ColorSpace isn't ignoring the reference colorspace in its conversion (as we can explicitly use it if desired), it's simply skipping the conversion from Reference<>Reference that is implied which seems to be standard OCIO behavior. Nevertheless I agree - it's up to the config author to accuratly define the to_reference and from_reference transforms. 

From my view, the relevant issues that crop up are symptoms of inconsistent implementations, esp. where Roles are used for implied conversions in the host application.

For example, I can see that Nuke OCIO CDLTransform uses the "reference" ROLE assignment for converting to/from the "working space" assigned in the OCIO CDLTransform node. This is inconsistent, because for other standard operations Nuke honors the reference colorspace that is implied by the first colorspace in the config file. A Read node transforms colors from the Read node colorspace to the Project Settings working space, as do other standard Nuke nodes with colorspace assignments. Of course, we can set the Project Settings working space to the reference/1st colorspace if we want to, and the conversions still happen as expected.

As for the Roles in the config - some of them are used to populate the color Project Settings assignments for "working space," "log files," etc. when a given config file is first loaded. But when some plugins like OCIO CDLTransform use OCIO Roles in its own way, ignoring the Nuke color Project Settings, things are getting overly complicated.

From the source code comments: 

    ColorSpace Roles are used so that plugins, in addition to this API can have
    abstract ways of asking for common colorspaces, without referring to them
    by hardcoded names.
All this considered, I conclude that the "reference" role should always be the "reference" (1st) colorspace in the config list. A few suggestions for improved behavior in the wild:

1. As users, get in the habit of setting the reference role to the 1st colorspace in the list. 
2. OCIO sanity checks and ociocheck app should return an error if "reference" role is anything other the 1st colorspace. 
3. Maybe - hardcode the "reference" role to the first colorspace in the list when configs are read in. I.e.: don't allow custom assignments. I expect some backlash for this suggestion - please don't rake me over the coals :) This at least enforces the intended usage. 

-Chris

On Thursday, April 19, 2018 at 8:52:43 AM UTC-7, Dennis Adams wrote:
Yes, I completely agree with that definition. My assertion that 'reference' was related turned out to be something in our own code, not OCIO.

///d@


On Wed, Apr 18, 2018 at 11:25 PM, Haarm-Pieter Duiker <li...@...> wrote:
Cross posting for completeness

The document detailing ACES support in various applications, is here (read only):

If anyone is interested in updating the document for more current versions, let me know. I'd be happy to provide an editable link. Just message me.

For those interested in implementations, I think the Nuke nodes are supposed to be a reference. The OCIO Colorspace node creates the path from one colorspace to the next with this call
m_processor = config->getProcessor(context, inputName, outputName);

which leads to this call to create a color space conversion
processor->getImpl()->addColorSpaceConversion(*this, context, src, dst);

which eventually leads to this function
BuildColorSpaceOps
which takes two colorspaces and concatenates the source colorspace's to_reference (or inverse from_reference) transforms with the destination colorspace's from_reference (or inverse to_reference) transforms.

So... the code has it. The reference colorspace isn't the first colorspace. It isn't the space pointed to by the 'reference' role. It's the space that the config colorspace's various to_reference and from_reference transforms use as a target or as a source. Hopefully all the colorspace's in the config agree on that definition!



On Mon, Apr 16, 2018 at 12:38 AM, Abraham Schneider <abrah...@...> wrote:
Hi there!


It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.

Could you maybe have a look at this and shine some light on this topic? 


Thanks, Abraham

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Re: Which colorspace is used as the reference space for an OCIO config?

Dithermaster <dither...@...>
 

I've read the source. I didn't see anything special about the "first" colorspace. Unless someone can show me (either in the code or by an API call example) where it is somehow special, I won't believe it.
///d@


On Fri, Apr 20, 2018 at 5:58 PM, <chris....@...> wrote:
Hi folks-

H.P., I also agree with that definition. But - it's also true that if you are converting to or from the 1st colorspace in the config list (aka "Reference" colorspace) we should see the to_reference or from_reference transform (or inverse as-needed) applied alone. More specifically, we don't need to explicitly convert from colorspace A to Reference colorspace, then from Reference colorspace to colorspace B because the conversion from Reference to Reference is a non-op. So the OCIO ColorSpace isn't ignoring the reference colorspace in its conversion (as we can explicitly use it if desired), it's simply skipping the conversion from Reference<>Reference that is implied which seems to be standard OCIO behavior. Nevertheless I agree - it's up to the config author to accuratly define the to_reference and from_reference transforms. 

From my view, the relevant issues that crop up are symptoms of inconsistent implementations, esp. where Roles are used for implied conversions in the host application.

For example, I can see that Nuke OCIO CDLTransform uses the "reference" ROLE assignment for converting to/from the "working space" assigned in the OCIO CDLTransform node. This is inconsistent, because for other standard operations Nuke honors the reference colorspace that is implied by the first colorspace in the config file. A Read node transforms colors from the Read node colorspace to the Project Settings working space, as do other standard Nuke nodes with colorspace assignments. Of course, we can set the Project Settings working space to the reference/1st colorspace if we want to, and the conversions still happen as expected.

As for the Roles in the config - some of them are used to populate the color Project Settings assignments for "working space," "log files," etc. when a given config file is first loaded. But when some plugins like OCIO CDLTransform use OCIO Roles in its own way, ignoring the Nuke color Project Settings, things are getting overly complicated.

From the source code comments: 

    ColorSpace Roles are used so that plugins, in addition to this API can have
    abstract ways of asking for common colorspaces, without referring to them
    by hardcoded names.
All this considered, I conclude that the "reference" role should always be the "reference" (1st) colorspace in the config list. A few suggestions for improved behavior in the wild:

1. As users, get in the habit of setting the reference role to the 1st colorspace in the list. 
2. OCIO sanity checks and ociocheck app should return an error if "reference" role is anything other the 1st colorspace. 
3. Maybe - hardcode the "reference" role to the first colorspace in the list when configs are read in. I.e.: don't allow custom assignments. I expect some backlash for this suggestion - please don't rake me over the coals :) This at least enforces the intended usage. 

-Chris

On Thursday, April 19, 2018 at 8:52:43 AM UTC-7, Dennis Adams wrote:
Yes, I completely agree with that definition. My assertion that 'reference' was related turned out to be something in our own code, not OCIO.

///d@


On Wed, Apr 18, 2018 at 11:25 PM, Haarm-Pieter Duiker <li...@...> wrote:
Cross posting for completeness

The document detailing ACES support in various applications, is here (read only):

If anyone is interested in updating the document for more current versions, let me know. I'd be happy to provide an editable link. Just message me.

For those interested in implementations, I think the Nuke nodes are supposed to be a reference. The OCIO Colorspace node creates the path from one colorspace to the next with this call
m_processor = config->getProcessor(context, inputName, outputName);

which leads to this call to create a color space conversion
processor->getImpl()->addColorSpaceConversion(*this, context, src, dst);

which eventually leads to this function
BuildColorSpaceOps
which takes two colorspaces and concatenates the source colorspace's to_reference (or inverse from_reference) transforms with the destination colorspace's from_reference (or inverse to_reference) transforms.

So... the code has it. The reference colorspace isn't the first colorspace. It isn't the space pointed to by the 'reference' role. It's the space that the config colorspace's various to_reference and from_reference transforms use as a target or as a source. Hopefully all the colorspace's in the config agree on that definition!



On Mon, Apr 16, 2018 at 12:38 AM, Abraham Schneider <abrah...@...> wrote:
Hi there!


It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.

Could you maybe have a look at this and shine some light on this topic? 


Thanks, Abraham

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
501 - 520 of 2201