Date   

Re: OCIO 1.0.9 released

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

https://github.com/imageworks/OpenColorIO/tree/v1.0.9

Will send a link from now on! :)

(Docs are in the process of rebuilding, the website will be updated
momentarily).

On Mon, Sep 23, 2013 at 1:03 PM, Richard Shaw <hobbe...@...> wrote:
Guess I got there too quick, don't see it yet on github...

Also, although it's not difficult to find a link would be handy :)

Thanks,
Richard

--
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: OpenColorIO FTBFS on GNU/kFreeBSD boxes

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

Hi again!

Il giorno 23/set/2013 21:59, "Jeremy Selan" <jeremy...@...> ha scritto:
>
> We've just put out the 1.0.9 tag. Please see if this fixes things?

Perfect.
Gonna check it tomorrow afternoon CET ;-)

Thanks a lot for the efforts.

Cheers.

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


Re: OCIO 1.0.9 released

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

Guess I got there too quick, don't see it yet on github...

Also, although it's not difficult to find a link would be handy :)

Thanks,
Richard


OCIO 1.0.9 released

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

I've just tagged the latest OCIO master as 1.0.9. There had been a
bunch of bugfixes in there, and it had been hurting our distros to not
have a tagged release with the lates.

-- Jeremy

**Version 1.0.9 (Sep 2 2013):**
* CDL cccid supports both named id and index lookups
* ociobakelut / ocioconvert updates
* FreeBSD compile dixes
* FileTransform disk cache allows concurrent disk lookups
* CSP windows fix
* Python 3 support (optional)
* Fix envvar abs/relative path testing
* Can explicitly declare config envvars
* gcc44 compile warning fixes


Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

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

We've just put out the 1.0.9 tag. Please see if this fixes things?

On Mon, Sep 23, 2013 at 12:42 PM, Jeremy Selan <jeremy...@...> wrote:
Oh - on further inspection I see you're compiling against yaml 0.5.1

This is a known issue, being tracked here:
https://github.com/imageworks/OpenColorIO/issues/318

-- Jeremy

On Mon, Sep 23, 2013 at 12:40 PM, Matteo F. Vescovi
<mfv.d...@...> wrote:
Hi!

On Mon, Sep 23, 2013 at 11:03:20AM -0700, Jeremy Selan wrote:
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.
Good to know ;-)

I dont have access to a box to test this unfortunately. Would anyone
have access to a compile machine which demonstrates this issue?
Well... I can test it, obviously ;-P
Gonna let you know the results of the build with that parameter set.

Thanks for your help.

Cheers.

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


Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

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

Oh - on further inspection I see you're compiling against yaml 0.5.1

This is a known issue, being tracked here:
https://github.com/imageworks/OpenColorIO/issues/318

-- Jeremy

On Mon, Sep 23, 2013 at 12:40 PM, Matteo F. Vescovi
<mfv.d...@...> wrote:
Hi!

On Mon, Sep 23, 2013 at 11:03:20AM -0700, Jeremy Selan wrote:
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.
Good to know ;-)

I dont have access to a box to test this unfortunately. Would anyone
have access to a compile machine which demonstrates this issue?
Well... I can test it, obviously ;-P
Gonna let you know the results of the build with that parameter set.

Thanks for your help.

Cheers.

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


Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

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

Hi!

On Mon, Sep 23, 2013 at 11:03:20AM -0700, Jeremy Selan wrote:
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.
Good to know ;-)

I dont have access to a box to test this unfortunately. Would anyone
have access to a compile machine which demonstrates this issue?
Well... I can test it, obviously ;-P
Gonna let you know the results of the build with that parameter set.

Thanks for your help.

Cheers.

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


Re: Review: Nuke: OCIODisplay now has an implemented GPU path

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

Awesome, thanks Sean!

Does anyone on this list have experience working with the Nuke GPU
path? This API is new to us, and we'd love to get some experienced
eyes on this code. :)

-- Jeremy

On Mon, Sep 16, 2013 at 11:37 AM, Sean Looper <sean....@...> wrote:
Modified CMake to only include this in the Linux builds. Contemplating
implementing the GPU path on the other plugins, as well.

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

Here's the specific commit:
https://github.com/slooper/OpenColorIO/commit/a4f9fa8e3183a430cf64b6f8e0b2193bfd71b022

-sean

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

1021 - 1040 of 2251