1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
Re: Review: Visual Studio 2010 compile fix Edit

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

On Tue, Dec 18, 2012 at 8:20 AM, Richard Shaw <hobbe...@...> wrote:
I'm not sure if this is causing any issues:

diff --git a/src/core/PathUtils.cpp b/src/core/PathUtils.cpp
index a04ecee..4c944b1 100644
--- a/src/core/PathUtils.cpp
+++ b/src/core/PathUtils.cpp
@@ -49,10 +49,14 @@
#if defined(__APPLE__) && !defined(__IPHONE__)
#include <crt_externs.h> // _NSGetEnviron()
#elif !defined(WINDOWS)
-#include <unistd.h>
extern char **environ;
#endif

+#include <unistd.h>
+#if defined(__clang__)
+#include <unistd.h>
+#endif
I can confirm removing this commit fixes compilation on linux. I
haven't done any detailed analysis to see if there's any other
differences in the resultant package though.

Richard
Re: Review: Visual Studio 2010 compile fix Edit

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

I'm not sure if this is causing any issues:

diff --git a/src/core/PathUtils.cpp b/src/core/PathUtils.cpp
index a04ecee..4c944b1 100644
--- a/src/core/PathUtils.cpp
+++ b/src/core/PathUtils.cpp
@@ -49,10 +49,14 @@
#if defined(__APPLE__) && !defined(__IPHONE__)
#include <crt_externs.h> // _NSGetEnviron()
#elif !defined(WINDOWS)
-#include <unistd.h>
extern char **environ;
#endif

+#include <unistd.h>
+#if defined(__clang__)
+#include <unistd.h>
+#endif


Is it a problem to include the same header twice? I'm not sure what we
should be doing differently for clang.

Richard
Re: Review: Visual Studio 2010 compile fix Edit

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

On Fri, Dec 14, 2012 at 8:37 PM, Jeremy Selan <jeremy...@...> wrote:
http://github.com/imageworks/OpenColorIO/pull/300

Frederik has submitted a bunch of changes related to Visual Studio
2010 compatibility and STATIC linking.

As this touches CMake mojo as used on linux / osx, would those
familiar with package management please check this request out?
Ok, first problem. When I apply the patch to 1.0.8 I get the following
on my Linux build:

cd /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/build/docs/setuptools-prefix/src/setuptools
&& /usr/bin/cmake -E touch
/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/build/docs/setuptools-prefix/src/setuptools-stamp/setuptools-build
/usr/bin/cmake -E cmake_progress_report
/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/build/CMakeFiles
/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/src/core/PathUtils.cpp:52:15:
error: previous declaration of 'char** environ' with 'C++' linkage
In file included from
/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/src/core/PathUtils.cpp:55:0:
/usr/include/unistd.h:546:15: error: conflicts with new declaration
with 'C' linkage
/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/src/core/PathUtils.cpp:
In function 'std::string OpenColorIO::v1::pystring::os::getcwd()':
/home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-1.0.8/src/core/PathUtils.cpp:125:33:
warning: ignoring return value of 'char* getcwd(char*, size_t)',
declared with attribute warn_unused_result [-Wunused-result]
make[2]: *** [src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

Richard
Re: Review: Visual Studio 2010 compile fix Edit

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

On Tue, Dec 18, 2012 at 2:57 AM, dbr/Ben <dbr....@...> wrote:
On 18/12/2012, at 9:00 AM, Richard Shaw wrote:

My github-fu isn't good enough. How would I go about getting a patch
from the pull request so I can test it?


Add the pull-request-creator's repo as a remote, and fetch the changes

$ git remote add frederik
git://github.com/frederikaalund/OpenColorIO.git
$ git fetch frederik

Then either check out the branch temporarily (in "detatched HEAD mode"):

$ git checkout frederik/visual-studio-2010-compile-fix

Or as a tracking branch, which makes a new local branch connected to the
remote:

$ git checkout -t frederik/visual-studio-2010-compile-fix


Or, if you want an actual ye ol' patch, you can append ".patch" to the
Github URL:

https://github.com/imageworks/OpenColorIO/pull/300.patch
That's what I was looking for! I remembered you could do something
like that but I was trying .../pull/300/patch not .patch.

Thanks!

Richard
Re: Review: Visual Studio 2010 compile fix Edit

dbr/Ben <dbr....@...>
 

On 18/12/2012, at 9:00 AM, Richard Shaw wrote:
My github-fu isn't good enough. How would I go about getting a patch
from the pull request so I can test it?

Add the pull-request-creator's repo as a remote, and fetch the changes

    $ git remote add frederik git://github.com/frederikaalund/OpenColorIO.git
    $ git fetch frederik

Then either check out the branch temporarily (in "detatched HEAD mode"):

    $ git checkout frederik/visual-studio-2010-compile-fix

Or as a tracking branch, which makes a new local branch connected to the remote:

    $ git checkout -t frederik/visual-studio-2010-compile-fix


Or, if you want an actual ye ol' patch, you can append ".patch" to the Github URL:
Re: Review: Visual Studio 2010 compile fix Edit

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

On Fri, Dec 14, 2012 at 8:37 PM, Jeremy Selan <jeremy...@...> wrote:
http://github.com/imageworks/OpenColorIO/pull/300

Frederik has submitted a bunch of changes related to Visual Studio
2010 compatibility and STATIC linking.

As this touches CMake mojo as used on linux / osx, would those
familiar with package management please check this request out?
My github-fu isn't good enough. How would I go about getting a patch
from the pull request so I can test it?

Thanks,
Richard
Review: config-syntax documentation

dbr/Ben <b...@...>
 

https://github.com/imageworks/OpenColorIO/pull/296

Summary of the changes:

* Docs of the various sections within the config, and available transforms
* Basic guidelines for writing documentation (mainly I wanted somewhere to write the heading-underline convention)
* Layout tweak to add more padding on the right column, and better heading sizes
* Includes installation instructions using yum/Homebrew


You can view a combined version of the diffs in the "Files changed" tab, at the top of the page.
Main new file is:
Review: Visual Studio 2010 compile fix Edit

Jeremy Selan <jeremy...@...>
 

http://github.com/imageworks/OpenColorIO/pull/300

Frederik has submitted a bunch of changes related to Visual Studio
2010 compatibility and STATIC linking.

As this touches CMake mojo as used on linux / osx, would those
familiar with package management please check this request out?

Thanks!

-- Jeremy

--------------------------------------------------------------------------------------------------------------

I changed the CMake files to fix the compilation issues I (and
apparently others) had while trying to compile OpenColorIO on Windows
7 using Visual Studio 2010. This works for the STATIC version of
OpenColorIO. I have not tried the SHARED version. Also, I only built
the core OpenColorIO library and not any of the tools.

Notable changes:

Both tinyxml and yaml-cpp can now be found externally using the
USE_EXTERNAL_* options in CMake. This is useful when
ExternalProject_Add doesn't work as it should.
Removed the PkgConfig dependency for yaml-cpp by adding a very raw
FindYAML_CPP.cmake package. The latter has a lot of room for
improvement and is merely intended as a quick-fix. This is useful when
PkqConfig is not present which is rarely the case with Windows
Installations
The static build of OpenColorIO is no longer linked with external
libraries. Static libraries do not incorporate the binary objects of
its dependencies. It is up to the runtime binary that links against
OpenColorIO to link the entire hierarchy of dependencies. In other
words, the target_link_libraries has no effect on archive targets
(ceated with add_library(TARGET_NAME STATIC ...)). Sources:
http://stackoverflow.com/questions/1242820/can-a-c-static-library-link-to-shared-library
http://stackoverflow.com/questions/2157629/linking-static-libraries-to-other-static-libraries
Added the definition OCIO_BUILD_STATIC to static builds so the code
doesn't use __declspec(dllimport) when building statically. This fixes
a lot of linker errors.
Re: linux compile question

dbr/Ben <dbr....@...>
 


On 14/12/2012, at 5:02 PM, singha...@... wrote:
I want to try virtualbox -> windows (host) linux (guest) ( it takes only 32 bit ) -> ocio


If I'm not mistaken, VirtualBox supports 64-bit guests,
Re: photoshop icc profile

dbr/Ben <dbr....@...>
 

On 14/12/2012, at 5:14 PM, singha...@... wrote:


making a icc profile in linux will work for photoshop for windows. True or False

True. It does not matter where you generate the ICC profile, it is independent of both OCIO and operating system it was generated on.

compiling ocio on linux 32 ( guest ) on windows (host ) via virtual box will work. True or False

True. All checkins to OCIO are tested by Travis-CI,
..and travis-ci run all their builds on a 32-bit Ubuntu distro running in VirtualBox (I assume, since they use vagrant)
Re: linux compile question

Jeremy Selan <jeremy...@...>
 

OpenColorIO should compile cleanly on both 32bit and 64bit flavors of
linux. 64 bits is what we use in production every day, and to the best
of my knowledge 32-bits should work as well. Please let us know if
you see otherwise?

Regards,
Jeremy

On Thu, Dec 13, 2012 at 10:32 PM, <singha...@...> wrote:
will ocio compile in 64 bit version of linux or does it work only on 32 bit.
Re: Rendering per-shot grades with ocioconvert

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

Sorry for the delay -- when people who are not subscribers post to oiio-dev (or when subscribers post from a different mail account), it awaits moderator approval.  Sometimes there are delays either in delivering the approval alert, or in my ability to go to the web site and approve the message (though unless I'm traveling, it's rare that it gets delayed more than several hours).

I posted a follow-up to oiio-dev, but the bottom line is that -- at least according to your oiio-dev post -- you were specifying the arguments to oiiotool in the wrong order, attempting to write the output *before* stripping it down to 3 channels, which quite correctly complained that it wasn't allowed to write a 5-channel file to JPEG format.

-- lg


On Dec 12, 2012, at 11:52 AM, andre...@... wrote:

Hey Larry (nice to meet you!),

I sent something to oiio-dev this morning, it's waiting for moderator approval.  Is this the correct way to ask questions/submit bugs?


(the response I got was)
Your mail to 'Oiio-dev' with the subject
    oiiotool --ch problems
Is being held until the list moderator can review it for approval.
The reason it is being held:
    Post by non-member to a members-only list


I'll submit a pull request shortly.  The code is backwards compatible and fairly harmless, so might not hurt to have anyway.


On Wednesday, December 12, 2012 11:29:21 AM UTC-8, Larry Gritz wrote:
I'd appreciate a list of specifically which things are lacking in oiiotool to make this practical.

-- lg


On Dec 12, 2012, at 10:43 AM, bsloan wrote:

This is veering from the original thread a bit but for various reasons, oiiotool seems not to be able to do the proper combination of things that we require.

Our own Andrew Wood has made what he describes as a 20 line modification to ocioconvert that does the trick (by snarfing some DNA from oiiotool). I've added the help text below to give an idea of the added functionality.

What is your feeling about rolling this change into the next iteration of OCIO? We can provide the modified source file (or create a fork in GIT). Your answer will influence our decision whether to fork and rename ocioconvert as a new internal tool or to continue to regard it as a 3rd party tool.

Once again, big acknowledgement to the community of OCIO developers (and Jeremy). Sincere thanks.

these are the new options:

    --croptofull           name=Crop or pad to make pixel data region match the "full" region
    --keepchannels %d      name=keep first n channels

here's the new full help:
OpenImageIO options
    --float-attribute %L   name=float pair defining OIIO float attribute
    --int-attribute %L     name=int pair defining OIIO int attribute
    --string-attribute %L  name=string pair defining OIIO string attribute
    --croptofull           name=Crop or pad to make pixel data region match the "full" region
    --keepchannels %d      name=keep first n channels


On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine

--
 
 

--
Larry Gritz
l....@...


--
 
 

--
Larry Gritz
l...@...

Re: Upstreamable patches?

dbr/Ben <dbr....@...>
 

Done as part of https://github.com/imageworks/OpenColorIO/pull/296

On 13/12/2012, at 1:46 AM, Jeremy Selan wrote:

Please do add the pre-built installation guides in the docs (as you
mention).  Thanks!

-- Jeremy

On Wed, Dec 12, 2012 at 4:35 AM, dbr/Ben <dbr....@...> wrote:
On 12/12/2012, at 2:51 PM, Richard Shaw wrote:

Oh, it looks like someone already did this for me on 1.0.8, correct?


Think it was you (or your helpful evil-twin) :D

https://github.com/imageworks/OpenColorIO/commit/b7ac8ae8fc508a4ef96052e219953aebecb3f216
https://github.com/imageworks/OpenColorIO/commit/44c82c50d18fd23ca035de1272bd27a016511a7c

..which were both tagged in v1.0.7 if I'm not mistaken:

$ git describe b7ac8ae8fc508a4ef96052e219953aebecb3f216
v1.0.7-4-gb7ac8ae
$ git describe 44c82c50d18fd23ca035de1272bd27a016511a7c
v1.0.7-1-g44c82c5

a simple "yum install OpenColorIO" will work on F15 and up and also on
EL6 (but only if using the Fedora EPEL repository...)


This should definitely be mentioned in the installation guide - having a
nice easy install option before the "Building from source" instructions is a
great improvement!

It should also mention the "Homebrew" installation command for OS X ("brew
install opencolorio")

I'm happy to add this, as I'm working on other sections of the docs right
now

--



--



Re: icc profile for photoshop

dbr/Ben <dbr....@...>
 

As far as I was aware, the Photoshop ICC instructions were up-to-date.. then again it was written for the previous Photoshop version, and was written a while ago now. I'm curious to see what changes are required!

I'm working on other parts of the docs (see WIP pull request here: https://github.com/imageworks/OpenColorIO/pull/296 ), there should be no merge problems with your changes

On 13/12/2012, at 5:03 AM, Andrew Britton wrote:

@dbr,
Did you write in a post, here or on github, that you are working on updating the ICC usage in Photoshop documentation? I was going to write some of notes as well and update the OCIO documentation so it would be great to see what was going to be added.

On Tuesday, December 11, 2012 4:06:10 AM UTC-8, dbr/Ben wrote:
That's correct! This guide should hopefully explain everything:


If you have access to a Linux machine, you could run ociobakelut on that, then copy the ICC profile to the Windows machine.

It's definitely possible to build on Windows, but building on Linux (or OS X) can be easier - it's been documented, and more widely tested

On 11/12/2012, at 10:20 PM, sing...@... wrote:

I am to compile ocio for windows. Before i do that certain questions crop in my mind.

correct me if i am wrong. Going thru the notes. I understand that to view images in a color space in photoshop I need to make icc profile.
and that too using ociobakelut.

iow, after compiling ocio for windows, one of the products ociobakelut will help create this icc profile from command line.

Is that it to it or is there something more. How exactly does this process go.

--
 
 


--
 
 
Re: Rendering per-shot grades with ocioconvert

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

I'd appreciate a list of specifically which things are lacking in oiiotool to make this practical.

-- lg


On Dec 12, 2012, at 10:43 AM, bsloan wrote:

This is veering from the original thread a bit but for various reasons, oiiotool seems not to be able to do the proper combination of things that we require.

Our own Andrew Wood has made what he describes as a 20 line modification to ocioconvert that does the trick (by snarfing some DNA from oiiotool). I've added the help text below to give an idea of the added functionality.

What is your feeling about rolling this change into the next iteration of OCIO? We can provide the modified source file (or create a fork in GIT). Your answer will influence our decision whether to fork and rename ocioconvert as a new internal tool or to continue to regard it as a 3rd party tool.

Once again, big acknowledgement to the community of OCIO developers (and Jeremy). Sincere thanks.

these are the new options:

    --croptofull           name=Crop or pad to make pixel data region match the "full" region
    --keepchannels %d      name=keep first n channels

here's the new full help:
OpenImageIO options
    --float-attribute %L   name=float pair defining OIIO float attribute
    --int-attribute %L     name=int pair defining OIIO int attribute
    --string-attribute %L  name=string pair defining OIIO string attribute
    --croptofull           name=Crop or pad to make pixel data region match the "full" region
    --keepchannels %d      name=keep first n channels


On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine

--
 
 

--
Larry Gritz
l...@...

Re: Rendering per-shot grades with ocioconvert

Jeremy Selan <jeremy...@...>
 

I'm happy to roll your changes into public ocioconvert.

My only concern would be to confirm the new additions do not modify
any prior existing behaviors. (There are other facilities who have
rolled out pipelines based on ocioconvert, and I'd like to make it
compatible if possible).

This should be easy to confirm; by all means submit a pull request.

-- Jeremy

On Wed, Dec 12, 2012 at 10:43 AM, bsloan <bsl...@...> wrote:
This is veering from the original thread a bit but for various reasons,
oiiotool seems not to be able to do the proper combination of things that we
require.

Our own Andrew Wood has made what he describes as a 20 line modification to
ocioconvert that does the trick (by snarfing some DNA from oiiotool). I've
added the help text below to give an idea of the added functionality.

What is your feeling about rolling this change into the next iteration of
OCIO? We can provide the modified source file (or create a fork in GIT).
Your answer will influence our decision whether to fork and rename
ocioconvert as a new internal tool or to continue to regard it as a 3rd
party tool.

Once again, big acknowledgement to the community of OCIO developers (and
Jeremy). Sincere thanks.

these are the new options:

--croptofull name=Crop or pad to make pixel data region match
the "full" region
--keepchannels %d name=keep first n channels

here's the new full help:
OpenImageIO options
--float-attribute %L name=float pair defining OIIO float attribute
--int-attribute %L name=int pair defining OIIO int attribute
--string-attribute %L name=string pair defining OIIO string attribute
--croptofull name=Crop or pad to make pixel data region match
the "full" region
--keepchannels %d name=keep first n channels


On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:

Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current
ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a
colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented.

Nag, nag nag.

Thanks again,

-blake

--
--transcribed from fMRI data using Google Thought Engine
--
Re: Rendering per-shot grades with ocioconvert

bsloan <bsl...@...>
 

This is veering from the original thread a bit but for various reasons, oiiotool seems not to be able to do the proper combination of things that we require.

Our own Andrew Wood has made what he describes as a 20 line modification to ocioconvert that does the trick (by snarfing some DNA from oiiotool). I've added the help text below to give an idea of the added functionality.

What is your feeling about rolling this change into the next iteration of OCIO? We can provide the modified source file (or create a fork in GIT). Your answer will influence our decision whether to fork and rename ocioconvert as a new internal tool or to continue to regard it as a 3rd party tool.

Once again, big acknowledgement to the community of OCIO developers (and Jeremy). Sincere thanks.

these are the new options:

    --croptofull           name=Crop or pad to make pixel data region match the "full" region
    --keepchannels %d      name=keep first n channels

here's the new full help:
OpenImageIO options
    --float-attribute %L   name=float pair defining OIIO float attribute
    --int-attribute %L     name=int pair defining OIIO int attribute
    --string-attribute %L  name=string pair defining OIIO string attribute
    --croptofull           name=Crop or pad to make pixel data region match the "full" region
    --keepchannels %d      name=keep first n channels


On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine
Re: icc profile for photoshop

Andrew Britton <cbsd....@...>
 

@dbr,
Did you write in a post, here or on github, that you are working on updating the ICC usage in Photoshop documentation? I was going to write some of notes as well and update the OCIO documentation so it would be great to see what was going to be added.


On Tuesday, December 11, 2012 4:06:10 AM UTC-8, dbr/Ben wrote:
That's correct! This guide should hopefully explain everything:


If you have access to a Linux machine, you could run ociobakelut on that, then copy the ICC profile to the Windows machine.

It's definitely possible to build on Windows, but building on Linux (or OS X) can be easier - it's been documented, and more widely tested

On 11/12/2012, at 10:20 PM, sing...@... wrote:

I am to compile ocio for windows. Before i do that certain questions crop in my mind.

correct me if i am wrong. Going thru the notes. I understand that to view images in a color space in photoshop I need to make icc profile.
and that too using ociobakelut.

iow, after compiling ocio for windows, one of the products ociobakelut will help create this icc profile from command line.

Is that it to it or is there something more. How exactly does this process go.

--
 
 
Pull Request: updates to ociobakelut

Andrew Britton <andrew.d...@...>
 

In reference to Issue #291, I've posted a pull request as a fix. Here's the link:
http://github.com/imageworks/OpenColorIO/pull/298
Re: Upstreamable patches?

Jeremy Selan <jeremy...@...>
 

Please do add the pre-built installation guides in the docs (as you
mention). Thanks!

-- Jeremy

On Wed, Dec 12, 2012 at 4:35 AM, dbr/Ben <dbr....@...> wrote:
On 12/12/2012, at 2:51 PM, Richard Shaw wrote:

Oh, it looks like someone already did this for me on 1.0.8, correct?


Think it was you (or your helpful evil-twin) :D

https://github.com/imageworks/OpenColorIO/commit/b7ac8ae8fc508a4ef96052e219953aebecb3f216
https://github.com/imageworks/OpenColorIO/commit/44c82c50d18fd23ca035de1272bd27a016511a7c

..which were both tagged in v1.0.7 if I'm not mistaken:

$ git describe b7ac8ae8fc508a4ef96052e219953aebecb3f216
v1.0.7-4-gb7ac8ae
$ git describe 44c82c50d18fd23ca035de1272bd27a016511a7c
v1.0.7-1-g44c82c5

a simple "yum install OpenColorIO" will work on F15 and up and also on
EL6 (but only if using the Fedora EPEL repository...)


This should definitely be mentioned in the installation guide - having a
nice easy install option before the "Building from source" instructions is a
great improvement!

It should also mention the "Homebrew" installation command for OS X ("brew
install opencolorio")

I'm happy to add this, as I'm working on other sections of the docs right
now

--
1061 - 1080 of 2209