Date   

Re: Siggraph Events

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

After feedback from the community, I think its probably simplest to
NOT have an OpenColorIO BOF this year. Given that we wont have the
opportunity to prepare a rockin' BOF presentation, and that people's
time Siggraph week is really precious, I think it makes the most sense
to meet instead at the already scheduled color events:

Tuesday 9 AM, 408A: "Cinematic Color", (with an informal hangout /
discussion immediately following)
Wednesday 7PM, Cork Bar. "Open Source VFX Beer of a Feather".

Next year I promise to put together an awesome OCIO BOF, something at
least twice as good as usual. ;)

And stay tuned for some really exciting announcements post-siggraph,
concerning commercial apps which will soon have native OCIO support.

Cheers,
Jeremy


Re: 2nd annual Open Source VFX Beer of a Feather

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

A revised sponsor list:

Sony Pictures Imageworks (they also found and booked the venue, yay!)
Weta Digital
Peregrine Labs
Lucasfilm
Pixar Animation Studios
Walt Disney Animation Studios
Digital Domain Media Group
Luma Pictures

If you forward the announcement to other people or mail lists, please
use the revised names.


2nd annual Open Source VFX Beer of a Feather

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

For those of you attending SIGGRAPH 2012 in Los Angeles in August, we
are throwing a get-together for developers and users of VFX-specific
open source projects. This was a big hit last year, and a great way
to put faces to the names you see on the developer mail lists in a
relaxing venue.

When: Wed. August 8, 2012, starting at 6:00pm

(apologies for conflicts; it is not possible to have ANY event during
SIGGRAPH that doesn't conflict with 6 other interesting things)

Where: Cork Bar, 403 W. 12th St, Los Angeles (about 3 blocks from the LACC)
http://www.corkbar.com

How it works:

Our kind sponsors will charge up a tab, and we'll be able to get drinks
until the funding pool runs out (after which you're welcome to
stay and buy your own drinks). We'll also have some appetizers
ordered up front.

With proper lubrication in hand, relax and enjoy the company
of your fellow open source developers.

Your sponsors:

Sony Pictures Imageworks (they also found and booked the venue, yay!)
Weta
Peregrine Labs
Lucasfilm
Pixar
Disney Feature Animation
Digital Domain
Luma Pictures

<This is actually an email from lg on oiio-dev, reposting to ocio-dev>

-- Jeremy


Re: [ocio-users] Siggraph Events

Aaron Weintraub <aaw...@...>
 

I would definitely go if there was one, and probably drag a couple colleagues with me. I don't have that much to present, as we're only just on the verge of rolling it into the new cycle of projects, but we've been actively following the development and are using some of the standalone tools, so would be happy to listen to the war stories and cautionary tales of others.

I'm planning on coming to your course as well.

-A

On 07/17/2012 02:29 PM, Jeremy Selan wrote:
Team OpenColorIO,

Is there interest in having an OCIO Birds of a Feather this year?
Would you attend?

I am not inclined to prepare a presentation (like the last two years),
but if there is interest in having a BOF session I am happy to set one
up. I can arrange a projector too.

Is anyone interested in presenting at an OCIO BOF? It doesn't have to
be a formal presentation. Perhaps a discussion of how they used OCIO
in production, what went well, what didn't, etc. And then we can all
nod in agreement, and discuss the future roadmap. We have some
exciting things coming up for OCIO (namely native integration in even
more VFX apps!).


If we are not interested in a formal OCIO get together this year,
there are still two opportunities to meet as a community:

- Tuesday @ 9 AM. I will be teaching a course, "Cinematic Color"

http://s2012.siggraph.org/attendees/sessions/cinematic-color-your-monitor-big-screen

For those active on this list, this will probably be a bit on the
introductory side, but I hope to throw enough details in there to make
it worthwhile for everyone. I have also written up rather extensive
course notes; I will post a link on this forum once they are posted
online. As always, immediately following the course there will likely
be a hangout in the hall for everyone to say hi and grab a drink.

- Wednesday @ 7PM. "Beer of a Feather". Continuing the success of
last year, we will be hosting a pub event for all open-source projects
in VFX and animation. This will be your chance to spell out what you
really think of our projects. Inebriated API discussions will be
fine, though there won't be a projector. :) Location to be
announced.

Cheers,
Jeremy


Siggraph Events

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

Team OpenColorIO,

Is there interest in having an OCIO Birds of a Feather this year?
Would you attend?

I am not inclined to prepare a presentation (like the last two years),
but if there is interest in having a BOF session I am happy to set one
up. I can arrange a projector too.

Is anyone interested in presenting at an OCIO BOF? It doesn't have to
be a formal presentation. Perhaps a discussion of how they used OCIO
in production, what went well, what didn't, etc. And then we can all
nod in agreement, and discuss the future roadmap. We have some
exciting things coming up for OCIO (namely native integration in even
more VFX apps!).


If we are not interested in a formal OCIO get together this year,
there are still two opportunities to meet as a community:

- Tuesday @ 9 AM. I will be teaching a course, "Cinematic Color"

http://s2012.siggraph.org/attendees/sessions/cinematic-color-your-monitor-big-screen

For those active on this list, this will probably be a bit on the
introductory side, but I hope to throw enough details in there to make
it worthwhile for everyone. I have also written up rather extensive
course notes; I will post a link on this forum once they are posted
online. As always, immediately following the course there will likely
be a hangout in the hall for everyone to say hi and grab a drink.

- Wednesday @ 7PM. "Beer of a Feather". Continuing the success of
last year, we will be hosting a pub event for all open-source projects
in VFX and animation. This will be your chance to spell out what you
really think of our projects. Inebriated API discussions will be
fine, though there won't be a projector. :) Location to be
announced.

Cheers,
Jeremy


Review: OpenGL ES 2.0 gpu support and iOS example app

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

Re-sending this review request (code by Brian Hall)
https://github.com/imageworks/OpenColorIO/pull/278

- Enables GPU accelerated OCIO on iOS devices, including ipad.

One interesting implementation detail is that iOS mobile devices do
not support 3D textures. This code work around this issue by allowing
3D texture to be stored in a 2D "lut image". Trilinear interpolation
is then manually implemented using bilinear lookups.

-- Jeremy


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


Re: rv integration

dbr/Ben <dbr....@...>
 

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



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:


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


Re: rv integration

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

On Jun 29, 2012, at 11:25 AM, Jeremy Selan wrote:

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

* 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
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?
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.

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

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


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

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

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


-- Jeremy


Re: rv integration

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.


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

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


Re: New CentOS5.8 64 bit build of Krita (with lut docker)

Boudewijn Rempt <bo...@...>
 

On Thursday 28 June 2012 Jun, Barry Zubel wrote:
Hi Boudewijn,

I've hooked a copy of this and will get it set up here so we can test it
off.

I assume the OCIO bits rely on the OCIO env var to find the correct
profile(s)?
That's up to the user: krita can use the env var, or you can manually select a config file.

Is OCIO rolled in, or do I need to compile that seperately as a dependency?
yeah, it's part of the package. On centos5, the krita tarbal contains everything -- it's practically a complete linux distro :P

--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: New CentOS5.8 64 bit build of Krita (with lut docker)

Barry Zubel <barry...@...>
 

Hi Boudewijn,

I've hooked a copy of this and will get it set up here so we can test it off.

I assume the OCIO bits rely on the OCIO env var to find the correct profile(s)?

Is OCIO rolled in, or do I need to compile that seperately as a dependency?

Cheers

B.



On 28/06/12 09:36, Boudewijn Rempt wrote:
This is up to date with git master of yesterday and includes
the ocio-based lut docker. I tested on a clean centos5 64 bit vm and
everything worked.

To make the lut docker work, you need to have an OpenColorIO configuration
available. See http://opencolorio.org/configurations/index.html for
downloads.

http://www.valdyas.org/~boud/krita-lut-2012-06-28-centos5-64.tgz

Please report any issues you have with it: as I've said before, it hasn't
been used for real yet, so I am sure there are bugs and oversights.

Boudewijn
_______________________________________________
kimageshop mailing list
kimag...@...
https://mail.kde.org/mailman/listinfo/kimageshop


The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.


New CentOS5.8 64 bit build of Krita (with lut docker)

Boudewijn Rempt <bo...@...>
 

This is up to date with git master of yesterday and includes
the ocio-based lut docker. I tested on a clean centos5 64 bit vm and everything worked.

To make the lut docker work, you need to have an OpenColorIO configuration
available. See http://opencolorio.org/configurations/index.html for
downloads.

http://www.valdyas.org/~boud/krita-lut-2012-06-28-centos5-64.tgz

Please report any issues you have with it: as I've said before, it hasn't
been used for real yet, so I am sure there are bugs and oversights.

Boudewijn


Re: rv integration

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


Re: rv integration

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)


Re: rv integration

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
nvizible – VISUAL EFFECTS

+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com




On 25 June 2012 00:32, Alex - <ale...@...> wrote:
We are using a modified version of source_setup.
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,

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:

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




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


Re: rv integration

Alex - <ale...@...>
 

We are using a modified version of source_setup.
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,

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:

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



Re: rv integration

Tzuen Wu <tzue...@...>
 

Hi Jim,

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:


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


Re: rv integration

Jordan Soles <jor...@...>
 

Hi Jim,

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:

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
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles






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

1181 - 1200 of 2243