1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
Re: 1.1.0 Release

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

Using newer gcc version (i.e. 7.2.1), you are facing new warnings.

Please have a look to PR 488 where most of your problems should have been fixed:
https://github.com/imageworks/OpenColorIO/pull/488/commits/598f11d995a73d950ab85abeef1f6c2d1a15a6d9

Patrick.


On Sunday, January 7, 2018 at 9:29:37 PM UTC-5, Richard wrote:
Ok, so I changed to yaml-cpp 0.5.x (was still using 0.3.x) and got past cmake, now:

/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/src/core/Lut1DOp.cpp:192:14: error: 'void OpenColorIO::v1::{anonymous}::Lut1D_Nearest(float*, long int, const OpenColorIO::v1::Lut1D&)' defined but not used [-Werror=unused-function]
         void Lut1D_Nearest(float* rgbaBuffer, long numPixels, const Lut1D & lut)
              ^~~~~~~~~~~~~
cc1plus: all warnings being treated as errors


Thanks,
Richard
Re: 1.1.0 Release

Richard Shaw <hobbe...@...>
 

Ok, so I changed to yaml-cpp 0.5.x (was still using 0.3.x) and got past cmake, now:

/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/src/core/Lut1DOp.cpp:192:14: error: 'void OpenColorIO::v1::{anonymous}::Lut1D_Nearest(float*, long int, const OpenColorIO::v1::Lut1D&)' defined but not used [-Werror=unused-function]
         void Lut1D_Nearest(float* rgbaBuffer, long numPixels, const Lut1D & lut)
              ^~~~~~~~~~~~~
cc1plus: all warnings being treated as errors


Thanks,
Richard
Re: 1.1.0 Release

Richard Shaw <hobbe...@...>
 

Trying to do a test build on Fedora Rawhide but I'm getting an error:

+ /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DOCIO_BUILD_STATIC=OFF -DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON -DOCIO_PYGLUE_SONAME=OFF -DUSE_EXTERNAL_YAML=TRUE -DUSE_EXTERNAL_TINYXML=TRUE -DUSE_EXTERNAL_LCMS=TRUE ../
-- The C compiler identification is GNU 7.2.1
-- The CXX compiler identification is GNU 7.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Setting Build Type to: RelWithDebInfo
-- Setting Namespace to: OpenColorIO
-- Exec prefix not specified, defaulting to /usr
-- Use Boost Ptr: OFF
-- Setting python bin to: python
Python library: /usr/lib64/python2.7/config/libpython2.7.so
-- Setting EXTDIST_BINPATH: /builddir/build/BUILD/OpenColorIO-RB-1.1/build/ext/dist/bin
-- Setting EXTDIST_PYTHONPATH: /builddir/build/BUILD/OpenColorIO-RB-1.1/build/ext/dist/lib64/python2.7/site-packages
-- Found TinyXML: /usr/lib64/libtinyxml.so  
-- TinyXML version: 2.6.2
-- External TinyXML will be used.
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.4.0") 
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:415 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPkgConfig.cmake:593 (_pkg_check_modules_internal)
  CMakeLists.txt:255 (pkg_check_modules)
-- Configuring incomplete, errors occurred!

Am I missing something? I can't see what's actually wrong...

Thanks,
Richard
1.1.0 Release

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

Hello all,

With the help of our lovely contributors, we have just set up the 1.1.0 release branch. This is currently regarded as a Release Candidate since the official 1.1.0 tag has not been assigned yet. We are looking to the community to take a look at this release candidate and provide feedback before the version is officially locked off.

We will be looking to have input before the following Friday (Jan 12 2018). Pending feedback, we will look to lock off the version after this date. All input and opinions are welcomed and appreciated.

Thanks!
SC
Re: OCIO 1.0.10

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

Happy New Year everyone!

After some time we finally have some good news. With the help of our lovely contributors over many years, we have just set up the Release Candidate branch for OCIO 1.1.0 here.

Some notes to carry over from the various Slack channel conversations. Between Larry, Patrick and myself we have decided to adopt the OIIO method of maintaining release branches for a given Major+Minor release version. This will allow for continued maintenance of the given release without holding back active development on Master.

Why 1.1.0 instead of 1.0.10? After a bit of deliberation, it seemed more appropriate to assign this a Minor version for a few reasons. First and foremost, its been almost 5 years since the last release and a good amount of changes have accumulated over that time. Additionally, there are backward compatible API changes which require a Minor version change based on SemVer 2.0. Lastly, it allows for a clean beginning to the release branch structure.

I will create another post specific to the 1.1.0 Release Candidate, so please carry your comments and concerns to that thread.

Thanks everyone,
SC


On Wednesday, 26 April 2017 18:31:50 UTC+1, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean
Re: Slack invite

Espen Nordahl <espen....@...>
 

I'd love to join too.

On Mon, Dec 18, 2017 at 9:13 AM, Simon Björk <bjork...@...> wrote:
I'd like to join as well, thanks



-------------------------------
Simon Björk
Compositor/TD


2017-12-16 16:39 GMT+01:00 Chris Offner <chriso...@...>:
May I also request an invite?
chriso...@...

Thank you! :)

--
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.

--
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.
Re: Slack invite

Simon Björk <bjork...@...>
 

I'd like to join as well, thanks



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503

2017-12-16 16:39 GMT+01:00 Chris Offner <chriso...@...>:

May I also request an invite?
chriso...@...

Thank you! :)

--
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.
Re: Slack invite

Sean Wallitsch <shid...@...>
 

Shid...@... too if you don't mind :)

Thanks!

On Sat, Dec 16, 2017 at 6:49 PM Chris Offner <chriso...@...> wrote:
May I also request an invite?
chriso...@...

Thank you! :)

--
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: Slack invite

Chris Offner <chriso...@...>
 

May I also request an invite?
chriso...@...

Thank you! :)
Re: Slack invite

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

Added :)

On Tue, Dec 5, 2017 at 5:38 AM, Jacob Danell <ja...@...> wrote:
Hi! I wish to be invited to the ocio slack channel. I'm working with OCIO on all my projects in After Effects and currently porting some profiles over to OCIO.
Cheers!
//Jacob

--
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.
Slack invite

"Jacob Danell" <ja...@...>
 

Hi! I wish to be invited to the ocio slack channel. I'm working with OCIO on all my projects in After Effects and currently porting some profiles over to OCIO.
Cheers!
//Jacob
Re: .CDL in addition to .CC and .CCC?

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


On Fri, Nov 24, 2017 at 7:39 AM, Abraham Schneider <abraham....@...> wrote:
I would really like to see OCIO support .cdl files in addition to .cc and .ccc as an direct input for the FileTransform and CDLTransform.

Of course there are ways and tools like cdl_convert to convert files between the different CDL formats, so you could batch convert them before using. But if a pipeline/tool is already using .cdl, it would be so helpful to be able to use these files directly in Nuke etc., or for example in a custom .ocio config where you want to use contexts with separate CDL values per shot that already exist as .cdl files.

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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
.CDL in addition to .CC and .CCC?

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

I would really like to see OCIO support .cdl files in addition to .cc and .ccc as an direct input for the FileTransform and CDLTransform.

Of course there are ways and tools like cdl_convert to convert files between the different CDL formats, so you could batch convert them before using. But if a pipeline/tool is already using .cdl, it would be so helpful to be able to use these files directly in Nuke etc., or for example in a custom .ocio config where you want to use contexts with separate CDL values per shot that already exist as .cdl files.

Thanks, Abraham
Re: OCIO 1.0.10

Jeremie Gerhardt <jeremie....@...>
 

hi all, 

I like to join the Slack conversation as well.

Thank you, 

Jeremie

On Wednesday, April 26, 2017 at 1:31:50 PM UTC-4, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean
Re: Review: FileTransform will try all lut formats (if the initial read fails)

Matt Plec <mp...@...>
 

I've also gotten away with putting no extension on them. It felt a little ropey, but not quite as misleading or prone to creating further problems if someone picked up the file and tried to use it otherwise. At least if there's no extension you have to look in the file and see what it is instead of just assuming.


On Mon, Nov 13, 2017 at 5:58 AM, <er...@...> wrote:
Figured out i could rename the cube to cc and ocio identified it correctly anyways.


On Monday, November 13, 2017 at 2:56:51 PM UTC+1, Erik Johansson wrote:
Digging this up

I have a config setup looking for $SHOT.cc but client decided to start sending .cube files instead

How would the config file need to look for this fallback to work?

On Monday, November 15, 2010 at 7:12:57 PM UTC+1, Jeremy Selan wrote:
In the absence of any objections, I will check this into master.

-- Jeremy

--
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.
Re: Review: FileTransform will try all lut formats (if the initial read fails)

er...@...
 

Figured out i could rename the cube to cc and ocio identified it correctly anyways.


On Monday, November 13, 2017 at 2:56:51 PM UTC+1, Erik Johansson wrote:
Digging this up

I have a config setup looking for $SHOT.cc but client decided to start sending .cube files instead

How would the config file need to look for this fallback to work?

On Monday, November 15, 2010 at 7:12:57 PM UTC+1, Jeremy Selan wrote:
In the absence of any objections, I will check this into master.

-- Jeremy
Re: Review: FileTransform will try all lut formats (if the initial read fails)

er...@...
 

Digging this up

I have a config setup looking for $SHOT.cc but client decided to start sending .cube files instead

How would the config file need to look for this fallback to work?


On Monday, November 15, 2010 at 7:12:57 PM UTC+1, Jeremy Selan wrote:
In the absence of any objections, I will check this into master.

-- Jeremy
Re: Using environment variables/context to point to a colorspace

Jonas Lindfors <jonas.l...@...>
 

Awesome!

On Mon, Nov 6, 2017 at 9:48 PM, Patrick Hodoul <patric...@...> wrote:
Please refer to pull request #477


On Thursday, November 2, 2017 at 12:12:47 PM UTC-4, jonas...@... wrote:
Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?

On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen

--
You received this message because you are subscribed to a topic in the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ocio-dev/Pj3SJs-hW6U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
CHIMNEY
Jonas Lindfors
VFX Artist

CHIMNEY
Skeppsbron 38
111 30 Stockholm
Mobile: +46 706 530 538
www.chimneygroup.com

Constantly challenging ourselves and our clients
to engage the audience through innovation and creation

Re: Using environment variables/context to point to a colorspace

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

Please refer to pull request #477


On Thursday, November 2, 2017 at 12:12:47 PM UTC-4, jonas...@... wrote:
Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?

On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen
Re: Using environment variables/context to point to a colorspace

jonas.l...@...
 

Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?


On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen
561 - 580 of 2201