Re: rv integration


Jim Hourihan <jimho...@...>
 

Thanks for the explanation Ben.

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:
* Is the GPU path fully functional compared to the CPU path?
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.
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),

https://github.com/imageworks/OpenColorIO/issues/240


On 02/07/2012, at 6:33 PM, Jim Hourihan wrote:
1) What *is* a context (an ocio config file? programmatically defined only?)
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?)


2) How should the user (or rv developer) specify which context to use?
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.


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?
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)


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

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

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

Join ocio-dev@lists.aswf.io to automatically receive all group messages.