|
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 message
Show 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. |
|
|
|
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:
|
|
|
|
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? |
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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 |
|
|
|
Patch for the getActiveViews env issue
Ashley Retallack <ashl...@...>
Hi guys, I noticed there is an issue with getting the active Views list when it has been overridden in the environment using OCIO_ACTIVE_VIEWS. I've attached a patch that will fix this.
Also I noticed that getDisplays always returns only the active ones and not all the displays, where as getActiveDisplays returns all of them. Is there a reason for this? I have not changed this functionality as I don't know what other applications (hiero , Nuke Mari etc) this might affect.
Great project cheers ASh Ashley Retallack | Pipeline Engineer
BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |
|
|
|
|
3rd annual Open Source "Beer of a Feather"
Larry Gritz <l...@...>
For those of you attending SIGGRAPH 2013 in Anaheim next week, we will be once again holding an event for developers and users of VFX-specific open source projects. It's a great chance to meet in person with people on the other end of the mail lists.
When: Wed. July 24, 2013, 5:00pm - 7:00pm Where: Tangerine Grill and Patio 1030 West Katella Avenue, (at the Anabella Hotel) http://tangerinegrillandpatio.com How it works: Our kind sponsors will charge up a tab, and we'll be able to get drinks and appetizers until the funding pool runs out or we lose the reserved room at 7pm (after which I think we're still able to retreat to the main bar). With proper lubrication in hand, relax and enjoy the company of your fellow open source developers. Your generous sponsors: Digital Domain Double Negative DreamWorks Animation Industrial Light and Magic Luma Pictures Method Studios Peregrine Labs Pixar Animation Studios Sony Pictures Imageworks Walt Disney Animation Studios Weta Digital *Special thanks to Erik Strauss and Andrew Watkins of SPI, and Colin Doncaster of Peregrine Labs, for going above and beyond the call of duty to secure a venue under shockingly difficult circumstances. Feel free to echo this to other VFX open source mail lists that I may have missed. -- Larry Gritz l...@... |
|
|
|
Re: converting LUTs
Sean Looper <sean....@...>
On Wed, Jul 3, 2013 at 11:52 PM, Paul Damstadt <paul.d...@...> wrote: Hi, |
|
|
|
converting LUTs
Paul Damstadt <paul.d...@...>
Hi,
The convert utility seems to only convert a given image from one color space to another. How can I convert the LUT itself? Specifically, I am trying to convert Iridas .CUBE to Lustre .3dl Plz help. Thanks, Paul |
|
|
|
Re: Thoughts on layering of multiple config files
Nathan Rusch <natha...@...>
Hi Ben,
toggle quoted message
Show quoted text
I did see your responses to Hugh's thread after he pointed me to it. However, once again, the discussion seems to be centered around the idea of nesting or referencing config files, whereas I'm mainly interested in being able to layer config files together for very specific overrides. I'll try to sketch my thoughts out a little more clearly:
In this example, the file `/path/to/sparse/override.config` would be able to, say, replace a single ColorSpace definition with a more complex set of transforms or add a Look by *only* containing the desired additional or override definitions (and, say, the ocio_profile_version key). If the sparse file defined a ColorSpace with a name that matched the name of a ColorSpace in the "base config," the sparse file's definition would replace it purely based on the order in which the config files appear on the $OCIO variable. This would allow for overrides without requiring any preprocessing of the YAML data (to, say, resolve includes), any syntactical changes to the configuration files, or any alterations to any *existing* configurations. We use this same kind of thing to manage stored preferences/recent settings for pipeline operators at different contextual levels (show, shot, element, action, user). It allows each type of preference to be as sparse as possible to avoid writing out the same data many times, and for a given application or scenario, the order in which these contextual preferences "squash" each other can change (in the case that duplicate preference keys are possible). The main scenario I can see for deploying this type of config "patching" is when the crazy requests start rolling in from production near the end of a show, when it is often critical to be nimble. You are correct that even this type of extension would give anyone more wiggle room to break things, and that it wouldn't provide a way to remove things from the final Config. However, I don't really see this layering idea being the standard way of doing things, but simply an added dimension of flexibility. There is currently nothing stopping anyone from manually breaking an existing configuration with a text editor, or writing a malformed definition from scratch, and it isn't OCIO's responsibility to prevent them from doing this. In that same spirit, it wouldn't be OCIO's responsibility to prevent someone from trying to combine two configuration files that don't result in a valid Config object. Hope this helps clarify my thoughts a little more, and how they differ from the idea of referencing or including configuration files between each other. -Nathan On Thursday, June 27, 2013 8:09:13 AM UTC-7, dbr/Ben wrote:
|
|
|