Re: OCIO 1.0.9 released
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/tree/v1.0.9
toggle quoted messageShow quoted text
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...
|
|
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. Thanks a lot for the efforts. Cheers. --
|
|
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?
toggle quoted messageShow quoted text
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
|
|
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!
|
|
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.Good to know ;-) I dont have access to a box to test this unfortunately. Would anyoneWell... 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!
toggle quoted messageShow quoted text
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
|
|
Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes
Jeremy Selan <jeremy...@...>
Thanks for this report.
toggle quoted messageShow quoted text
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 canUPDATE: a test build on a Debian GNU/kFreeBSD64 porterbox now gives the
|
|
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 canUPDATE: 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:
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,
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
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:
|
|
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:
|
|
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_ ./001/0001/fromJeremy_v002_cin_ ./001/0002/fromEditorial_v001_cin_ 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:
|
|
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".
toggle quoted messageShow quoted text
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:
-- 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.
|
|