Date
1 - 11 of 11
rv integration
|
Jim Hourihan <jimho...@...>
Hi all, I'm looking into full OCIO integration into an upcoming version of rv. I was wondering if people could describe some of their workflows and/or how they might want to use OCIO in rv ideally.
* Specifically for facilities that use OCIO with nuke or other software, how is file colorspace communicated to the application? Are you using sony's method of incorporating that meta data into the file name? Right now its looking like rv's source_setup would need to handle this but I'm probably missing something. * Beyond file data linearization and display correction what would the priority be of using OCIO for e.g. multiple looks, per-shot CDL, changing the context, etc. I also have a few questions for developers: * On the GPU path how is a prelut (aka shaper lut) generated and used? In the ociodisplay example's main it looks like there was an intention to have one but the example doesn't use it. * Is the GPU path fully functional compared to the CPU path? -Jim |
|
|
|
Jordan Soles <jor...@...>
Hi Jim,
toggle quoted message
Show quoted text
In our case, it's not embedded in the meta data of the filename but tied more generally to either the shot/sequence/show...we then modify the source_setup (as you had suspected) based on the filetype.
Jordan On Fri, Jun 22, 2012 at 2:43 PM, Jim Hourihan <jimho...@...> wrote:
JORDAN SOLES Chief Technology Officer | Producer Office: 514 397 9999 x 400 Cell: 514 699 0414 Skype: jordansoles  |
|
|
|
Tzuen Wu <tzue...@...>
Hi Jim,
toggle quoted message
Show quoted text
Really excited you're looking into this. Our main priorities with using OCIO in RV would definitely being able to combine several transformations into 'Looks' that work for per-shot CDLs and LUTs, as well as being able to use the OCIO definition to set the context in which a LUT is applied (Which we've been using the prelut for lin2log as an example) For Nuke and 3D apps, we're using show definitions to communicate colorspace, although for the most part we are keeping to a complete linear workflow on the artist side. Best, Tzuen On Jun 22, 2012, at 11:43 AM, Jim Hourihan wrote:
|
|
|
|
Alex - <ale...@...>
We are using a modified version of source_setup.
toggle quoted message
Show quoted text
On that note, are there any plans to rewrite source_setup in Python rather than MU? Per shot looks are a priority for us. Ideally we would like to point RV and Nuke at the same config and have it just work. Regards Alex On Sat, Jun 23, 2012 at 5:48 AM, Tzuen Wu <tzue...@...> wrote: Hi Jim, |
|
|
|
Hugh Macdonald <hugh.ma...@...>
Hi Jim,
That's great to hear - I was actually planning on asking someone at your end about this some time this week, but no longer! We have yet to properly get into OCIO here, but so many of the tools we use support it (Nuke, Mari, Silhouette, OIIO (for command-line)) that having RV do the same thing would be perfect in terms of keeping a nice consistent colour pipeline across the board.
I can't help you out with specific examples of how we'd want to use it, as we don't necessarily use it properly yet, but I just wanted to chuck out another vote of "yes please" from here.
Cheers Hugh Macdonald On 25 June 2012 00:32, Alex - <ale...@...> wrote: We are using a modified version of source_setup. D I S C L A I M E R : This email and any files transmitted with it are intended solely for the intended addressee,
and may contain confidential information or material protected by law,
copyright or other legislation. If you have received this message in
error, please return it to the sender or notify the sender by calling
+44 (0)20 3167 3860, and immediately and permanently delete it. You
should not copy it or use it for any purpose, nor disclose its contents
to any other person. Only the intended recipient may place any reliance
upon it. Nvizible Limited accepts no responsibility or liability for
emails sent by its employees or personnel which are not sent in the
course of its business or that of its clients. Nvizible
Limited, 3 Richfield Avenue, Richfield Place, Reading, Berkshire, RG1
8EQ . Registered in England & Wales with Company Number: 6900121 |
|
|
|
Ciaran <c.j....@...>
+1 for per shot looks; we use them extensively. Right now we do this by baking all the looks out and having a package load the appropriate one into the Look LUT.
We pull metadata from shotgun, so a nice pythony place to set up sources would be nice (I didn't write our code for this but I understand it was annoying to integrate) |
|
|
|
Jim Hourihan <jimho...@...>
Thanks for the info everybody. Sounds like:
* source_setup -> python (which is already in the queue) * per-shot looks (CDL, etc) So right now I'm thinking that anywhere rv currently has a LUT pipeline (pre-cache, file, look, display) there is an optional OCIO node instead -- you either use rv's LUT pipeline *or* OCIO. This would not include most of the color correction which currently happens after the file -> linear conversion so you can still use that with OCIO if you want to. The intention would be to use GPU for file, look, and display and CPU for pre-cache. This seems like it would give you the most flexibility for OCIO combined with existing rv features. The source_setup in python would be the starting point for you to hack the "rules" by which files are matched with OCIO color spaces. This would include importing the python OCIO module if you need to. Sounds good? -Jim |
|
|
|
Jeremy Selan <jeremy...@...>
Super excited about getting RV support. Can't wait!
Allow me to take a stab at some of your questions. This will probably be a lengthy reply... On Fri, Jun 22, 2012 at 11:43 AM, Jim Hourihan <jimho...@...> wrote: * Beyond file data linearization and display correction what would the priority be of using OCIO for e.g. multiple looks, per-shot CDL, changing the context, etc.Per-shot CDLs / OCIO::Contexts are two sides of the same coin. Per-shot corrections, (whether they're 3d luts, CDLs, or something else) is something we use internally at Imageworks quite liberally, and would be wonderful to have. (I know many of our client's workflows live or die on per-shot 3d lut support...) From the perspective of an image playback tool, this all comes down to providing a custom OCIO::Context to the getProcessor(...) query. API users can think of the Context as representing all environment variable set at launch time, which can then be overridden. In applications which are re-launched between shots (such a compositing apps or lighting apps), the Context -- defaulting to the current launch envvars -- will "just work". I.e., per-shot luts will be supported without the user worrying about the Context. But in an image playback utility, where per-shot luts are changing from moment to moment, using the OCIO::Context is likely a necessity. I would expect that a facility-neutral implementation of per-shot luts in RV would provide some sort of callback (similar to source_setup), which would be given the new media/clip object (or list of properties about it), and then do facility specific parsing, and in return provide a list of 'context' overrides. For example, in one implementation a studio may choose (when the shot changes in the image playback tool), to parse the image metadata, look for a 'SHOT' field, and the set (SHOT, SHOT_VALUE) in the context. Anther studio may choose to parse the filenames instead and set "SEQUENCE". But the uniformity of the approach is to have the user script get access to the clip/media properties as input, and as output generate a series of key/value string pairs that are passed to OCIO::Config::GetProcessor(...) call. Does this make sense? Note that OCIO will abstract the actual lookup of the per-shot luts. (Resolving the context envvars into filenames). The client application should not worry about what files were actually used, it merely has to setup the Context appropriately. You can introspect and see what luts were actually used using the getMetadata() call. But note that the return value is an unordered set of all the LUTs used, and is not intended to circumvent OCIO's internal processing engine. * On the GPU path how is a prelut (aka shaper lut) generated and used? In the ociodisplay example's main it looks like there was an intention to have one but the example doesn't use it.OCIO doesnt explicitly use shaper luts, but instead relies on a similar 'allocation' mechanism to make sure all 3d lut lattice samplings are well behaved. This provides a bit more info: http://opencolorio.org/configurations/allocation_vars.html The reason shaper luts are insufficient within OCIO is that a shaperlut is tightly coupled to the image's input color space (such as a single lin -> 3d lut transform). But... in OCIO the actually color processing is an NxN problem, with a custom transform for each input color space and each output color space combination. It gets even more complicated when one considers that a canonical DisplayTransform includes slots for per-shot luts, scene-linear fstop offset controls, post display-transform ccs, etc. So rather than overwhelm the user with requirements for a million shaper luts, the allocation 'metadata' essentially allows a prelut to be computed analytically on the fly, as needed. Note: A recent facility just found a minor issue in the internal allocation handling, which is exacerbated in specific (up until now) rare conditions. We intended on fixing this in an upcoming dot release, and it will not impact the public API. The GPU path is fully functional, in that any configuration you create can be used on the GPU, independent of the number of luts applied, etc. But... the GPU codepath currently is an approximation of the CPU path, and as such is not suitable for baking into final deliverables. The reason it's an approximation is that the GPU assumes the existence of a single 3D lut sampling point, and many color processing chains require multiple 3D luts. So in these cases the data will be baked on the fly into a similar, but not exactly indentical, representation. However, in our experience, the quality of the existing GPU pathway when properly configured is more than sufficient, even for live client reviews, and the increase in performance from the GPU 3D lut code makes this definitely worth it in viewer/playback applications. Examples of applications that use the GPU codepath in their viewers include Katana, Mari, and Silhouette. Examples of apps that use the CPU codepath in their viewer is Nuke. -- Jeremy |
|
|
|
Jim Hourihan <jimho...@...>
On Jun 29, 2012, at 11:25 AM, Jeremy Selan wrote:
Super excited about getting RV support. Can't wait!Excellent! I have OCIO in our build system and integrated into our (new) renderer so things are going well. I have some questions (below) On Fri, Jun 22, 2012 at 11:43 AM, Jim Hourihan <jimho...@...> wrote:Yes it makes sense. The one thing I'm missing here is how you create the proper context per-shot. It seems pretty clear that the facility will modify the source_setup in rv to figure out per-shot what to do (choosing contexts). But how do they communicate that to rv? The usual mechanism in rv is to set a property in rv's graph which is read by a node during evaluation. In this case that implies supplying the name (or list of names) of a context, but it looks like the contexts are not named so we can't fetch one internally like that (or are they filenames of configs?). Is the expectation that the context pointer is passed directly? I'm probably missing something. I read the docs, but am unclear as to whether a context is another config file, created programmatically, or something else.* Beyond file data linearization and display correction what would the priority be of using OCIO for e.g. multiple looks, per-shot CDL, changing the context, etc.From the perspective of an image playback tool, this all comes down to Note that OCIO will abstract the actual lookup of the per-shot luts.I don't think we'll need to do that. So no problem there. The generated shader + LUT is called directly. Once its working I may need to get information about whether or not the 3D LUT was actually used or not to prevent running out of samplers, but that can wait. I was thrown off by the declaration of another sampler (tex1) in ociodisplay's GLSL main() shader text. I realized later it was not being used.* On the GPU path how is a prelut (aka shaper lut) generated and used? In the ociodisplay example's main it looks like there was an intention to have one but the example doesn't use it.OCIO doesnt explicitly use shaper luts, but instead relies on a There are four places in rv's graph that are roughly analogous to OCIO: a CPU-only LUT pipeline before the main memory cache (per-shot), file->working space (per-shot), look (per-shot), and working space->display (only one slot for whole session -- or perhaps per output device in the future). I'm thinking we allow OCIO to take over any or all of those positions if desired. I think that would cover all bases. For better or worse, we'll have to use the GPU path for all but the pre-cache position. So if the user goes directly to the final display pixels before caching that's fine, but all subsequent operations will be in the display color space.The GPU path is fully functional, in that any configuration you create rvio would be the same. So when using rvio + OCIO for baking people may want to do the entire OCIO pipeline in one go in the pre-cache slot so its all done on the CPU. The current integrated code allows the user to specify the in and out color spaces for each of the four slots above. I assume the context should also be specified for each; is that right? One of our guys just rewrote the source_setup in python so we'll be able to import the OCIO module directly -- I think its safe to say that takes care of source_setup integration; at least for querying OCIO from the user level. (BTW, when we [tweak] say "color space" we mean *all* of the degrees of freedom associated with a color transform not just the linear ones -- so that includes the YUV weights, non-linear transfer function + parameters, as well as the chromaticities or any other linear transform. I realize people don't all agree with that use of the noun phrase "colou?r space" so bear with me on that. I'll try and qualify it when appropriate. It looks like the OCIO "colorspace" is used in the similar way. ) Reiterating my questions for clarity: 1) What *is* a context (an ocio config file? programmatically defined only?) 2) How should the user (or rv developer) specify which context to use? 3) Am I missing a use case if OCIO is swapped in for any/all of the existing pre-cache, file, look, and display LUT pipelines? Thanks for the help. -Jim
|
|
|
|
dbr/Ben <dbr....@...>
On 29/06/2012, at 7:25 PM, Jeremy Selan wrote:
As far as I'm aware, the only interesting difference between the CPU and GPU paths is the GPU doesn't currently do tetrahedral 3D LUT interpolation (it'll fall back to trilinear), On 02/07/2012, at 6:33 PM, Jim Hourihan wrote:
A context in OCIO-usage terms is basically a bunch of key/value pairs, which can be referenced in a config to construct paths (for LUT files), or a cccid (to select a grade from a ASC CDL ColorCorrectionCollection) In the case of "one application instance per shot" tool (like Nuke), the context variables inherited from environment-variables ($SEQ $SHOT and such), and can be overridden in some way by the user (e.g in Nuke nodes, there are "context" parameters, where you can use expressions to set $SHOT dynamically) For RV, each source would have it's own OCIO::Context. The values in this context would be pulled from properties on the current source somewhere (maybe something like "source0001.ocio.SEQ" etc?) The context would be the same for each colour-node attached to that source (FileLUT, LookLUT etc, and maybe the displayLUT, if it can be altered dynamically?)
As a user of RV (well, more as a pipeline-developer integrating RV), I'd expect the default context to be filled with environment variables - so if I do: $ export JOB=myjob $ rv /myjob/ab/ab-123/v001/ ..then any references to "${JOB}.csp" in my OCIO config will resolve to "myjob.csp". If I wanted per-shot values, I'd write an RV module. In a source-setup event handler, I'd call something like: cur_job = os.getenv("JOB") cur_seq = source_path.split("/")[4] cur_shot = source_path.split("/")[5] rv.commands.setStringProperty("source0001.ocio.JOB", cur_job) rv.commands.setStringProperty("source0001.ocio.SEQ", cur_seq) rv.commands.setStringProperty("source0001.ocio.SHOT", cur_shot) The JOB/SEQ/SHOT names could be anything (but those would be common examples), and the cur_{job,seq,shot} values might be parsed from the source's path, pulled from Shotgun, made up randomly, or.. anything Mu or Python can do A useful thing would be to use the values shotgun_mode grabs, then setStringProperty'ify them into a "source0001.ocio.blah" property (might be slightly difficult as the shotgun properties are set after source-setup, if I recall right.. but that can be worked around I'm sure) Err, in short - each facility might write a bit of code to set some properties on the current source. These source properties would be used to create the OCIO::Context for that source.
Being able to specify an input/output colourspace for each of those nodes would likely cover most use-cases. It might also be useful to set a LUT file for any step, for people who don't want to create an OCIO config rv.commands.setStringProperty("source0001.LookLUT.ocio_lut_file", "/path/to/my3dlut.csp") This is similar to how Mari can either work with a config, or simply loading a viewer LUT file (or like the OCIOFileTransform). Would be very similar to RV's current readLUT command, but would use OCIO's parsing instead (for consistency)
Minor thing, and I'm not sure how practical it is, but... it would be nice to split the source-setup stuff into two parts - one for colour related setup, and the second for image-geo setup/fixes. Currently to override the colour setup, you also have to carry along stuff like the fix for the stupid image-aspect value in Maya JPEG's, or respecting the image-rotation EXIF header. It'd be nice if I could override just the colour stuff, without worrying about overriding the image-geo-fix code fix an old copy of it Oh, I think I mentioned it ages ago in a support ticket, but I have a half-completed OCIO RV module written. Not sure how helpful a reference it'll be, but: I've not had a chance to work on it in months - only bits stopping it from being usable are the two "FIXME" comments, and creating the per-source contexts (easily done, just call a user-defined function that returns a dict, use this to create a OCIO.Context, and pass it to the getProcessor calls) Anyway, can't wait for RV to have proper OCIO integration! - Ben Dickson |
|
|
|
Jim Hourihan <jimho...@...>
Thanks for the explanation Ben.
toggle quoted message
Show quoted text
I've made it so a component called "ocio_context" appearing in the node will cause a context to be used and initialized with string props that appear in there. -Jim On Jul 4, 2012, at 3:01 PM, dbr/Ben wrote:
On 29/06/2012, at 7:25 PM, Jeremy Selan wrote:As far as I'm aware, the only interesting difference between the CPU and GPU paths is the GPU doesn't currently do tetrahedral 3D LUT interpolation (it'll fall back to trilinear),* Is the GPU path fully functional compared to the CPU path?The GPU path is fully functional, in that any configuration you create |
|
|