Date   

Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

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

Thanks for this report.

It looks to be a symbol visibility issue related to our use of
yaml-cpp, so this is probably fixable by editing the top-level
CMakeLists file's "USE_EXTERNAL_YAML" section.

I dont have access to a box to test this unfortunately. Would anyone
have access to a compile machine which demonstrates this issue?

-- Jeremy

On Thu, Sep 12, 2013 at 7:39 AM, Matteo F. Vescovi <mfv.d...@...> wrote:
On Wed, Sep 11, 2013 at 05:07:37PM +0200, Matteo F. Vescovi wrote:
Now, Debian using kFreeBSD amd64/i386 kernel fails building, as you can
see at [1] (Hurd is another story ;-) ).
UPDATE: a test build on a Debian GNU/kFreeBSD64 porterbox now gives the
results attached in the buildlog file, where fail is probably related to
the recent upgrade to boost 1.54 in Debian.

Hope it could help fixing the issue.

--
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A

--
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/groups/opt_out.


Re: Thoughts on layering of multiple config files

Mark Boorer <mark...@...>
 

Hi,

Apologies for bumping an old discussion, but I'm in looking for a similar set of features to the ones Nathan described, and as the discussion seemed to have fizzled out, I wanted to show my interest.

I would also like to have the OCIO env var behave like the $PATH variable, and be able to override parts of the resolved OCIO::Config in further, subsequent config.ocio files.

As long as each config file was also able to stand alone, the only real roadblock seems to be that the Config object currently holds a context, which looks like it's only used by the FileTransform.

Is it possible to have the FileTransformation instances contain their own context? So if they are overridden later when the next config is loaded, then the new ones will work with the new paths, and the old ones would continue to work with their old paths.

I'm quite interested in getting this functionality, specifically to override roles on a show / shot level, and would be happy to implement the required changes.

Cheers,
Mark



Re: ExpressionTransformation for OCIO?

Mark Boorer <mark...@...>
 

Hi,

I've finished my proof of concept, and it seems to be working quite nicely.

I ended up needing to provide 3 strings for 3d transformations (which isn't too terrible) and I was able to implement GLSL shader support too (I don't know enough Cg script, but it should be trivial to add in).

Here's a link to the pull request:
https://github.com/imageworks/OpenColorIO/pull/329

Would be great to hear any feedback :)

Thanks,
Mark


Review: Nuke: OCIODisplay now has an implemented GPU path

Sean Looper <sean....@...>
 

Modified CMake to only include this in the Linux builds. Contemplating implementing the GPU path on the other plugins, as well.


Here's the specific commit:

-sean


Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

"Matteo F. Vescovi" <mfv.d...@...>
 

On Wed, Sep 11, 2013 at 05:07:37PM +0200, Matteo F. Vescovi wrote:
Now, Debian using kFreeBSD amd64/i386 kernel fails building, as you can
see at [1] (Hurd is another story ;-) ).
UPDATE: a test build on a Debian GNU/kFreeBSD64 porterbox now gives the
results attached in the buildlog file, where fail is probably related to
the recent upgrade to boost 1.54 in Debian.

Hope it could help fixing the issue.

--
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A


OpenColorIO FTBFS on GNU/kFreeBSD boxes

"Matteo F. Vescovi" <mfv.d...@...>
 

Hi!

The aim of a Debian Maintainer/Developer is to have a package building
fine on all the supported archictures (actually, Debian supports 14
architectures officially, plus the unofficial ports).

Now, Debian using kFreeBSD amd64/i386 kernel fails building, as you can
see at [1] (Hurd is another story ;-) ).

Any chance to get any help in solving this issue upstream?

Thanks in advance.


[1] https://buildd.debian.org/status/package.php?p=opencolorio

--
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A


Re: ExpressionTransformation for OCIO?

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




On Fri, Aug 30, 2013 at 9:11 AM, Mark Boorer <mark...@...> wrote:
Hi Ben,



* I'm surprised your lin-log transform cannot be nicely applied as a 1D LUT.  Even with a large 2**16 or 2**32 line LUT? Would a different interpolation help (e.g cubic)?

My example where a 1D lut would be insufficient is where the source image is already in float linear, and a grading operation is to be applied in log (like saturation). Here negative values are acceptable, and we would expect them to be preserved when converted back to lin. When using a 1D lut, negative values (and positive values greater than 1) would be clamped off.



You may be interested in experimenting with the .spi1d lut format, it's actually rather general.

The spi1d format is unique in allowing LDR on an input axis, and HDR on the output axis. So if you wanted to have a log to linear lut, which supports HDR linear, but also maps negative values into a reasonable range in log space such a lut could be formulated.  And it supports both inverse / forward operations at full fidelity, so as long as both of your axes are not HDR it works great.

Mocking up a small demonstration of your use case...

The input domain for the LUT below is log space.  But rather than defining only the range of 0-1, I've extended it to -0.25,1.25 to allow for 'negative' log values as you mentioned.  So for the samples you see, they represent uniform steps in log space from of [-0.25, 0.0, 0.25, 0.5, 1.0, 1.25] The output domain is scene-linear.

> mylogtolin.spi1d

Version 1
From -0.25 1.25
Length 7
Components 1
{
    -0.05
     0.0
     0.05
     0.18
     1.5
     13.0
     55.0
}

You will be able to use such a LUT, at full fidelity, in programs such as nuke in either the forward (log->lin) or inverse (lin->log) directions.  Obviously a real lut would have much higher number of samples.



Re: ExpressionTransformation for OCIO?

Mark Boorer <mark...@...>
 

Hi Ben,


* I'm surprised your lin-log transform cannot be nicely applied as a 1D LUT.  Even with a large 2**16 or 2**32 line LUT? Would a different interpolation help (e.g cubic)?

My example where a 1D lut would be insufficient is where the source image is already in float linear, and a grading operation is to be applied in log (like saturation). Here negative values are acceptable, and we would expect them to be preserved when converted back to lin. When using a 1D lut, negative values (and positive values greater than 1) would be clamped off.


The GPU code path for this expression-transform would be difficult. Not sure how big a deal this is, as I have little experience with such things, but: Compiling the expression to shader code sounds doable but difficult. Baking the expressions to a LUT for the GPU seems might be more practical (using the AllocationOps to define the range the expression applies over)

I had a quick search for the current GPU shader code, but only found a process that generates a 3D lut as a texture, then does a simple lookup to generate output frag colors. Is there a mode complex model that accurately follows the CPU computation? Because that was another point I was hoping to raise :D

* OCIO's Transforms have a "hasChannelCrosstalk" method - since deterring this from an arbitrary expression might be impractical, so I guess when defining the transform you would have to specify if it's a 1D transform (e.g !<ExprTransform> {expr: "v**2"}) or 3D expression (e.g !<ExprTransform> {expr: "r+g+b/3", is3d:true})
 
I imagined either providing a single expression for 1D transforms, or 3 expressions for 3D, but I like the idea of the expression engine pre-setting the variables "x" or "r,g,b" when toggled via a bool.

Could you let me know where to look for the current GPU implementations? Obviously duplicating the effort of expression compilation on the GPU would be insane, but I don't have any other immediate ideas. Personally I'm happy with just a CPU based solution.



On Friday, August 30, 2013 4:25:51 PM UTC+1, dbr/Ben wrote:
There was discussion of a CTLTransform (Color Transform Language) in the past, although it would probably require OCIO to have a plugin interface for transforms, because having the OCIO core depend on CTL which depends on IlmBase is.. not ideal..



exprtk seems interesting, and looks "small enough" to be included in the core, as done with md5/pystring (Jeremy could say more authoritatively). The SeExpr project also seems suitable. Would definitely be interesting to see a prototype of the transform..


Some other random thoughts:

* I'm surprised your lin-log transform cannot be nicely applied as a 1D LUT.  Even with a large 2**16 or 2**32 line LUT? Would a different interpolation help (e.g cubic)?

* The GPU code path for this expression-transform would be difficult. Not sure how big a deal this is, as I have little experience with such things, but: Compiling the expression to shader code sounds doable but difficult. Baking the expressions to a LUT for the GPU seems might be more practical (using the AllocationOps to define the range the expression applies over)

Baking the expression to a LUT defeats the purpose you mention, but it would be useful in other cases (e.g we have a several colourspaces which are defined by simple expressions, but we currently have to bake these out as LUTs - would be much tidier as an expression-transform)

* OCIO's Transforms have a "hasChannelCrosstalk" method - since deterring this from an arbitrary expression might be impractical, so I guess when defining the transform you would have to specify if it's a 1D transform (e.g !<ExprTransform> {expr: "v**2"}) or 3D expression (e.g !<ExprTransform> {expr: "r+g+b/3", is3d:true})

On 31/08/2013, at 12:05 AM, Mark Boorer wrote:

Hi,

I'm currently looking at moving our existing color pipeline tools over to OCIO, and I'm wondering if anyone can see a place for such a feature.

In our current setup, some of our log to lin conversions cannot be adequately expressed via a 1D lut, and for grading operations the changes caused by interpolation are too great.

I'm proposing to write an Expression Transformation, which would allow us to express these transformation operations via a string, and evaluate them using exprtk or a similar library.

Has anything like this been proposed before? Does anyone have any thoughts? I'm hoping to knock up a proof of concept over the next few weeks.

Cheers,
Mark


--
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/groups/opt_out.


Re: ExpressionTransformation for OCIO?

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

There was discussion of a CTLTransform (Color Transform Language) in the past, although it would probably require OCIO to have a plugin interface for transforms, because having the OCIO core depend on CTL which depends on IlmBase is.. not ideal..



exprtk seems interesting, and looks "small enough" to be included in the core, as done with md5/pystring (Jeremy could say more authoritatively). The SeExpr project also seems suitable. Would definitely be interesting to see a prototype of the transform..


Some other random thoughts:

* I'm surprised your lin-log transform cannot be nicely applied as a 1D LUT.  Even with a large 2**16 or 2**32 line LUT? Would a different interpolation help (e.g cubic)?

* The GPU code path for this expression-transform would be difficult. Not sure how big a deal this is, as I have little experience with such things, but: Compiling the expression to shader code sounds doable but difficult. Baking the expressions to a LUT for the GPU seems might be more practical (using the AllocationOps to define the range the expression applies over)

Baking the expression to a LUT defeats the purpose you mention, but it would be useful in other cases (e.g we have a several colourspaces which are defined by simple expressions, but we currently have to bake these out as LUTs - would be much tidier as an expression-transform)

* OCIO's Transforms have a "hasChannelCrosstalk" method - since deterring this from an arbitrary expression might be impractical, so I guess when defining the transform you would have to specify if it's a 1D transform (e.g !<ExprTransform> {expr: "v**2"}) or 3D expression (e.g !<ExprTransform> {expr: "r+g+b/3", is3d:true})

On 31/08/2013, at 12:05 AM, Mark Boorer wrote:

Hi,

I'm currently looking at moving our existing color pipeline tools over to OCIO, and I'm wondering if anyone can see a place for such a feature.

In our current setup, some of our log to lin conversions cannot be adequately expressed via a 1D lut, and for grading operations the changes caused by interpolation are too great.

I'm proposing to write an Expression Transformation, which would allow us to express these transformation operations via a string, and evaluate them using exprtk or a similar library.

Has anything like this been proposed before? Does anyone have any thoughts? I'm hoping to knock up a proof of concept over the next few weeks.

Cheers,
Mark


--
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/groups/opt_out.


ExpressionTransformation for OCIO?

Mark Boorer <mark...@...>
 

Hi,

I'm currently looking at moving our existing color pipeline tools over to OCIO, and I'm wondering if anyone can see a place for such a feature.

In our current setup, some of our log to lin conversions cannot be adequately expressed via a 1D lut, and for grading operations the changes caused by interpolation are too great.

I'm proposing to write an Expression Transformation, which would allow us to express these transformation operations via a string, and evaluate them using exprtk or a similar library.

Has anything like this been proposed before? Does anyone have any thoughts? I'm hoping to knock up a proof of concept over the next few weeks.

Cheers,
Mark


Re: Regular Expression LUT matching

nhatpho...@...
 

It should pick the latest filename of all matches in alphabetical/numerical order so that in case we have

./001/0001/fromJeremy_v001_cin_srgb.cube
./001/0001/fromJeremy_v002_cin_srgb.cube
./001/0002/fromEditorial_v001_cin_srgb.cube

it would default to the latest version of each shot.

Now looking into FNMatch I think it's even more suitable than regex because it's simple and keeps the config easy to maintain.




Am Donnerstag, 29. August 2013 10:24:34 UTC-7 schrieb Jeremy Selan:

Interesting idea.  Not currently possible, very do-able.

What if multiple luts match the specified pattern?  Which would be selected? Or would this be an error?

What are your thoughts on full regex vs just fnmatch?  (fnmatch would get you wildcards and seq match).

FNMATCH
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq


 The only challenge is that we'd have to make sure it works on windows too (I've never tried regex or posix fnmatch on win).

-- Jeremy




On Wed, Aug 28, 2013 at 11:36 PM, <nhatp...@...> wrote:
Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat



--
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/groups/opt_out.


Re: Regular Expression LUT matching

Malcolm Humphreys <malcolmh...@...>
 

Is there a specific use case for this, it just feels dangerous.. Could we not just support ordered multiple luts? Eg. "/foobar/blah.lut:/cheese/foo.csp".

Jeremy Selan <jere...@...> wrote:

Interesting idea.  Not currently possible, very do-able.

What if multiple luts match the specified pattern?  Which would be selected? Or would this be an error?

What are your thoughts on full regex vs just fnmatch?  (fnmatch would get you wildcards and seq match).

FNMATCH
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq


 The only challenge is that we'd have to make sure it works on windows too (I've never tried regex or posix fnmatch on win).

-- Jeremy




On Wed, Aug 28, 2013 at 11:36 PM, <nhatpho...@...> wrote:
Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat



--
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/groups/opt_out.

--
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/groups/opt_out.


Re: Regular Expression LUT matching

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

Interesting idea.  Not currently possible, very do-able.

What if multiple luts match the specified pattern?  Which would be selected? Or would this be an error?

What are your thoughts on full regex vs just fnmatch?  (fnmatch would get you wildcards and seq match).

FNMATCH
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq


 The only challenge is that we'd have to make sure it works on windows too (I've never tried regex or posix fnmatch on win).

-- Jeremy




On Wed, Aug 28, 2013 at 11:36 PM, <nhatpho...@...> wrote:
Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat



--
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/groups/opt_out.


Regular Expression LUT matching

nhatpho...@...
 

Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat




Re: RV integration WIP

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

It's our understanding that RV 4.0 ships with OCIO built-in so you shouldn't need to compile it yourself.


Give that a shot, and let us know what you find?

-- Jeremy


On Tue, Aug 27, 2013 at 10:37 AM, <nhatpho...@...> wrote:
Any news on this?

We'd be highly interested in RV support for OCIO as all our bigger shows are using OCIO as the default colorpipeline.

Last time we tried to compile OCIO for Windows it wasn't that easy and we haven't picked that up ever since, but I'd offer to continue and help.

Thanks,


Nhat

--
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/groups/opt_out.


Re: RV integration WIP

nhatpho...@...
 

Any news on this?

We'd be highly interested in RV support for OCIO as all our bigger shows are using OCIO as the default colorpipeline.

Last time we tried to compile OCIO for Windows it wasn't that easy and we haven't picked that up ever since, but I'd offer to continue and help.

Thanks,


Nhat


Re: [pyOpenColorIO] get LUT type ?

Marie Fétiveau <m...@...>
 

Thanks, that did the trick !

++
Marie


On Wed, Aug 21, 2013 at 8:03 PM, Jeremy Selan <jeremy...@...> wrote:
Not directly.

The issue that makes this complex is that some lut files (such as csp) can contain both 1D and 3D luts together.  So the distinction between what should be considered 1-D, vs 3-D isn't always clear.  From OCIO's perspective even a CDL transform (.cc) is considered a 'LUT'.  Which would that be?

One alternative idea that may suffice for your needs would be to get the processor object (specific to the LUT file), and then call:

> processor.hasChannelCrosstalk()

I believe this is appropriately answered for all the lut types, and would let you accurately determine whether a 1-D plot is sufficient to graph the color transform.  It would also 'just work' then for all the underlying transform types, even those that use CDLs, log allocations, etc.

-- Jeremy




On Wed, Aug 21, 2013 at 7:38 AM, Marie Fétiveau <m...@...> wrote:
Hello !

I wrote a python script to plot 1D and 3D LUTs.
It uses pyOpenColorIO to read and process LUTs and matplotlib to plot them.

For the moment, I have to specify manually if the LUT is 1D or 3D to plot a curve or a cube.

So the question is : is there a way to get this information from OpenColorIO and through the binding ?

Thanks !

Marie
  



--
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/groups/opt_out.

--
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/groups/opt_out.


Re: [pyOpenColorIO] get LUT type ?

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

Not directly.

The issue that makes this complex is that some lut files (such as csp) can contain both 1D and 3D luts together.  So the distinction between what should be considered 1-D, vs 3-D isn't always clear.  From OCIO's perspective even a CDL transform (.cc) is considered a 'LUT'.  Which would that be?

One alternative idea that may suffice for your needs would be to get the processor object (specific to the LUT file), and then call:

> processor.hasChannelCrosstalk()

I believe this is appropriately answered for all the lut types, and would let you accurately determine whether a 1-D plot is sufficient to graph the color transform.  It would also 'just work' then for all the underlying transform types, even those that use CDLs, log allocations, etc.

-- Jeremy




On Wed, Aug 21, 2013 at 7:38 AM, Marie Fétiveau <m...@...> wrote:
Hello !

I wrote a python script to plot 1D and 3D LUTs.
It uses pyOpenColorIO to read and process LUTs and matplotlib to plot them.

For the moment, I have to specify manually if the LUT is 1D or 3D to plot a curve or a cube.

So the question is : is there a way to get this information from OpenColorIO and through the binding ?

Thanks !

Marie
  



--
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/groups/opt_out.


Sci-Tech Request

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

Folks,

As you may have noticed, ASC-CDL was selected for Sci-Tech consideration this year under the category of "Digital workflow specifications for managing color".


We are interested in providing the Academy with additional information on OpenColorIO as a potential example of related technology.

Our Request:
If you have used OpenColorIO on a motion-picture production, and are comfortable sharing this information with the Academy, please let us know.  Specifically, a listing of the motion-picture titles which used OCIO, and the facility associated with the work, are most helpful at this time.

Example:
Sony Imageworks
    - Oz The Great and Powerful
    - The Amazing Spider-Man
    - Cloudy With A Chance of Meatballs 2

If you'd prefer to not post publicly, feel free to email me directly.

Also, by no means are we only interested in large titles, or those produced in the US.  We would love to hear about *all* uses, both big and small!  You also don't have to be a VFX facility. We are equally interested in uses at post-houses, on-set, mastering facilities, etc. The only requirement is that it was used in motion-picture production.

The Academy deadline for submitting this information is this Tuesday, Aug 27th.  So realistically, we'd need to get all responses by this Monday, Aug 26th to be of help.

Regards,
Jeremy


[pyOpenColorIO] get LUT type ?

Marie Fétiveau <m...@...>
 

Hello !

I wrote a python script to plot 1D and 3D LUTs.
It uses pyOpenColorIO to read and process LUTs and matplotlib to plot them.

For the moment, I have to specify manually if the LUT is 1D or 3D to plot a curve or a cube.

So the question is : is there a way to get this information from OpenColorIO and through the binding ?

Thanks !

Marie
  



1021 - 1040 of 2243