Date   

Re: New to OCIO, and viewer processes in Nuke

Hugh Macdonald <hugh.ma...@...>
 

Hi Jeremy and Ben,

I have no issue with removing the default Nuke "None". Right now, it's not being removed, due to this bit of code in share/nuke/ocionuke/viewer.py (lines 21-29)

I'm going to fork the repository, and I'll put in a pull request for removing this. I just wasn't sure what people's thoughts on this were already.

��� elif also_remove == "all":
��������# Unregister all processes, but retain the useful "None" option
��������f or curname in nuke.ViewerProcess.registeredNames():
������������nuke.ViewerProcess.unregister(curname)
��������nuke.ViewerProcess.register(
������������name = "None",
������������call = nuke.nodes.ViewerProcess_None,
������������args = ())

My other query, then, would be whether it's possible to re-add a single None viewerProcess in a situation where there are multiple displays and views. In spi-vfx/config.ocio, they are currently defined like this.

displays:
��DCIP3:
����- !<View> {name: Film, colorspace: p3dci8}
����- !<View> {name: Log, colorspace: lg10}
����- !<View> {name: Raw, colorspace: nc10}
��sRGB:
����- !<View> {name: Film, colorspace: srgb8}
����- !& lt;View> {name: Log, colorspace: lg10}
����- !<View> {name: Raw, colorspace: nc10}
active_displays: [sRGB, DCIP3]
active_views: [Film, Log, Raw]

This is then doubling up on the Log and Raw LUTs, which aren't actually any different between displays.


Hugh Macdonald
nvizible � VISUAL EFFECTS

hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com

On 03/08/11 18:09, Jeremy Selan wrote:

The other issue is that the nuke-default ocio config is intended to
work in other applications other than nuke.  And many of  these other
apps dont automatically include a 'none' option by default, the same
way Nuke does.

Do you have concerns about removing the default Nuke 'None' option?
As ben mentions, register_viewers() should be removing all of the
original options.

Alternatively, as a compromise we could place the None option at the
bottom of the list.  Thus, while it would be duplicated in your case
at least the second copy wouldn't be getting in the way of the real
options...

I should also note that at Imageworks, while we of course use
OCIODisplay for our viewer, we dont rely on the public
register_viewers() call to register the nodes.  I forget the exact
reason but it relates to splitting up the registration into two parts
(init.py vs. menu.py) so knob defaults can be appropriate set on
startup.  I'll ping our nuke guru to add further details.


-- Jeremy

On Wed, Aug 3, 2011 at 9:29 AM, dbr/Ben <db...@...> wrote:
The�ocionuke.viewer.register_viewers() should have an argument which will
removal all viewer processes, including the default "none" proc (it's no
different to any other, just applies a no op node)
Sent from my iPad
On 03/08/2011, at 11:32, Hugh Macdonald <hugh....@...> wrote:

Hi all,
New OCIO user here... Just playing around with it to see how it'll fit into
our colour pipeline. Primarily playing with the Nuke side of things so far.
One small thing that's cropped up is how, when using the nuke-default
config, there are two "None" items in the viewer process drop-down.
I'm thinking that None probably should still be left in the menu in
ocionuke.viewer.register_viewers(), and the config files should just not
re-define a None. I'm thinking that the nuke-default config file should
maybe reflect this

As I'm quite new to OCIO, I didn't want to start forking and making a pull
request for this kind of change, so I thought I'd bring it up on here first.
Hugh Macdonald
nvizible���VISUAL EFFECTS

hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708

www.nvizible.com


Re: New to OCIO, and viewer processes in Nuke

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

The other issue is that the nuke-default ocio config is intended to
work in other applications other than nuke. And many of these other
apps dont automatically include a 'none' option by default, the same
way Nuke does.

Do you have concerns about removing the default Nuke 'None' option?
As ben mentions, register_viewers() should be removing all of the
original options.

Alternatively, as a compromise we could place the None option at the
bottom of the list. Thus, while it would be duplicated in your case
at least the second copy wouldn't be getting in the way of the real
options...

I should also note that at Imageworks, while we of course use
OCIODisplay for our viewer, we dont rely on the public
register_viewers() call to register the nodes. I forget the exact
reason but it relates to splitting up the registration into two parts
(init.py vs. menu.py) so knob defaults can be appropriate set on
startup. I'll ping our nuke guru to add further details.


-- Jeremy

On Wed, Aug 3, 2011 at 9:29 AM, dbr/Ben <dbr....@...> wrote:
The ocionuke.viewer.register_viewers() should have an argument which will
removal all viewer processes, including the default "none" proc (it's no
different to any other, just applies a no op node)
Sent from my iPad
On 03/08/2011, at 11:32, Hugh Macdonald <hugh.ma...@...> wrote:

Hi all,
New OCIO user here... Just playing around with it to see how it'll fit into
our colour pipeline. Primarily playing with the Nuke side of things so far.
One small thing that's cropped up is how, when using the nuke-default
config, there are two "None" items in the viewer process drop-down.
I'm thinking that None probably should still be left in the menu in
ocionuke.viewer.register_viewers(), and the config files should just not
re-define a None. I'm thinking that the nuke-default config file should
maybe reflect this

As I'm quite new to OCIO, I didn't want to start forking and making a pull
request for this kind of change, so I thought I'd bring it up on here first.
Hugh Macdonald
nvizible – VISUAL EFFECTS

hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708

www.nvizible.com


Re: New to OCIO, and viewer processes in Nuke

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

The ocionuke.viewer.register_viewers() should have an argument which will removal all viewer processes, including the default "none" proc (it's no different to any other, just applies a no op node)


On 03/08/2011, at 11:32, Hugh Macdonald <hugh.ma...@...> wrote:

Hi all,

New OCIO user here... Just playing around with it to see how it'll fit into our colour pipeline. Primarily playing with the Nuke side of things so far.

One small thing that's cropped up is how, when using the nuke-default config, there are two "None" items in the viewer process drop-down.

I'm thinking that None probably should still be left in the menu in ocionuke.viewer.register_viewers(), and the config files should just not re-define a None. I'm thinking that the nuke-default config file should maybe reflect this


As I'm quite new to OCIO, I didn't want to start forking and making a pull request for this kind of change, so I thought I'd bring it up on here first.

Hugh Macdonald
nvizible – VISUAL EFFECTS

hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708

www.nvizible.com


New to OCIO, and viewer processes in Nuke

Hugh Macdonald <hugh.ma...@...>
 

Hi all,

New OCIO user here... Just playing around with it to see how it'll fit into our colour pipeline. Primarily playing with the Nuke side of things so far.

One small thing that's cropped up is how, when using the nuke-default config, there are two "None" items in the viewer process drop-down.

I'm thinking that None probably should still be left in the menu in ocionuke.viewer.register_viewers(), and the config files should just not re-define a None. I'm thinking that the nuke-default config file should maybe reflect this


As I'm quite new to OCIO, I didn't want to start forking and making a pull request for this kind of change, so I thought I'd bring it up on here first.

Hugh Macdonald
nvizible – VISUAL EFFECTS

hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708

www.nvizible.com


Updated OCIO Profile posted

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

Hello!

We've updated the example OCIO Configurations.

Zips / Tarballs can be downloaded from the following links:
http://github.com/imageworks/OpenColorIO-Configs/zipball/master
http://github.com/imageworks/OpenColorIO-Configs/tarball/master

(Also, from the opencolorio.org website).

The spi-vfx, spi-anim profiles have been cleaned up to work with OCIO
0.8, and the nuke-default profile now matches Nuke 6.3.
The IIF profile is not changed, but will be updated post siggraph to
match recent IIF RRT development efforts.

Enjoy!

-- Jeremy


OCIO 0.8.5 released

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

Contains a critical bugfix for those using the Nuke OCIODisplay node.

(0.8.4 introduced a regression where images with alpha accidentally
had the display transform applied twice).

Thanks to Sean Looper for catching and fixing this regression.

-- Jeremy


Review: Robuster HDL loading

DBR - Ben <dbr....@...>
 

More flexible Houdini LUT parsing, along with a couple of unrelated minor changes

https://github.com/imageworks/OpenColorIO/pull/140


Review: nuke: Fixed bug in OCIODisplay where luts were applied twice

Sean Looper <sean....@...>
 

Please review...

https://github.com/imageworks/OpenColorIO/pull/141

Thanks!

Sean Looper


OCIO 0.8.4 released

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

OpenColorIO 0.8.4 has been released. Enjoy!

-- Jeremy

------------------------------------------------

Version 0.8.4 (July 25 2011):
* Native Look Support
* Core / Nuke OCIODisplay supports alpha viewing
* Added Houdini (.lut) writing
* Added Pandora (.mga,.m3d) reading
* Additional internal bug fixes


Thoughts on Alpha

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

An anonymous user asked...

Just wondering your thoughts on premultiplication and how it fits into a color managed pipeline. How does OCIO deal with premultiplication?
First off, I'm 'pro' premultiplication. To the best of my
understanding, premultiplication is the natural representation of
pixels with alpha; the big confusing thing about it is the name I
feel the simplest understanding of premultiplication is looking at it
from a rendering perspective. If you're writing a renderer, you ask
yourself "how much energy is being emitted from within the bounds of
this pixel"? Call that rgb. "and, how much of the background does
this pixel occlude?" That's alpha. This is how all renderers work
(prman, arnold, etc) , and its called 'premultiplied'. Note that at no
time does prman have an explicit step that multiplies rgb by alpha,
it's implicit in our definition of 'total pixel energy'. And it's
the right way to do things. A nice article on this topic is Alvy Ray
Smith's 1995 Tech Memo 4, 'Image Compositing Fundamentals':
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.5956

This definition also leads to a nice intuition for what would
otherwise be corner cases. Consider a pixel where rgb > alpha, such as
2.0, 2.0, 2.0, 1.0. Nothing special about this - it just represents a
'specular' pixel where it's emitting 2.0 units of light, and is fully
opaque. A pixel value of (2.0, 2.0, 2.0, 0.0)? Nothing special
about this either, it represents a pixels that's contributing 2.0
units of light energy, and happens to not occlude objects behind it.
Both of these cases can cause trouble with unpremultiplied
representations.

OCIO currently doesnt make any distinction between the two states, it
leaves that to the user. You can hand OCIO either premult or unpremult
pixels, it just applies the color math to rgb. What do I recommend?
There is no standard, and both ways can be useful in practice. This is
why nuke, for example, gives you a checkbox for which order to apply
the lut / premultiplication.

But my perspective from a Sony perspective is to avoid the issue to
the greatest extent possible. If you want to do a non-linear color
encoding, and also transmit alpha information you're pretty much hosed
anyways. There is just no good way to send log data, with alpha, in
such a way where the log comp will produce a result equivalent to the
linear comp. (I've actually done experiments where you munge the
output alphas to minimize alpha errors knowing what the destination
(bg layer) colors will be, and trust me - that's not a battle I ever
want to fight again)).

In our pipeline, we try to only keep alphas around when dealing with
imagery in the original rendered (linear) colorspace. If you want a
log representation, or any device output, we drop the alpha.

For the few outputs where we need to preserve alpha, we fake the best
job we can and just accept the limitations of an LDR comp. The most
common example of this processes is for marketing deliveries, where
they want a display referred tif / png to do a 'desktop publishing'
comp (i.e., photoshop). For these, we do linear exr -> unpremult ->
color conversion from linear to display referred -> store raw
unpremult data in supported 'unassociated' format (tif/png). This
process will allow for nice comps on elements such as hair edges, but
would not be sufficient for large semi-transparent elements such as fx
renders. (OCIO is handed unpremult data).

For implementing image displays, we do not do any special treatment
for alphas. For example, in Katana's image display we take the
premultiplied HDR linear rendered images, and apply the output display
transform to the premultiplied imagery. (OCIO is handed premult data).
This is conceptually equivalent to showing the image comp'd in
linear over black, and in my experience is typically what artists
expect in a compositing / lighting package.

(Hopefully this doesnt start a flame war). ;)

-- Jeremy


Re: OpenColorIO @ Siggraph

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

And to clarify, both of these events are totally open to everyone who
is interested. Full Conference passes are *not* required to attend
BOF events.

-- Jeremy

On Tue, Jul 19, 2011 at 5:34 PM, Jeremy Selan <jeremy...@...> wrote:
We will be hosting two OpenColorIO (OCIO) events at Siggraph, and we'd
love to see you there!

* OpenColorIO Meetup (BOF)
   Tues, 2:30-3:30 PM
   Convention Center 102, West Building

This upcoming year is shaping up to be an incredible one. The
OpenColorIO 1.0 release is just around the corner, and we're weeks
away from popular commercial apps shipping with built-in OCIO support.
 At this meetup, we'll discuss upcoming software / hardware vendor
support, the upcoming development roadmap, as well as discussions
about future project goals.  Even if your facility is currently not
relying on OCIO, if you're responsible for color management at a VFX /
Animation facility (or are an artist interested in such), we'd love to
have your input on these topics!  Who knows, you may find it
preferable to use OCIO someday... ;)

* Imageworks Open-Source "Beer of a Feather"
   Wed evening
   Pub near hotels / convention center (location TBA)

The admins of several of the SPI-sponsored and -related open source
projects (OSL, Field3D, OpenColorIO, OIIO, Alembic, maybe more, we'll
see) have decided to hold a joint BOF / beer-related event at
SIGGRAPH.   We're planning on Wednesday evening (August 10), after the
sessions end but before the usual evening festivities start.  So mark
your calendars, it'll be a time to relax, enjoy a beer in lovely
Vancouver, and match names and faces from your favorite open source
projects.  Exact location and time will be announced as we get closer
(but definitely Wednesday evening).

-- Jeremy


OpenColorIO @ Siggraph

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

We will be hosting two OpenColorIO (OCIO) events at Siggraph, and we'd
love to see you there!

* OpenColorIO Meetup (BOF)
Tues, 2:30-3:30 PM
Convention Center 102, West Building

This upcoming year is shaping up to be an incredible one. The
OpenColorIO 1.0 release is just around the corner, and we're weeks
away from popular commercial apps shipping with built-in OCIO support.
At this meetup, we'll discuss upcoming software / hardware vendor
support, the upcoming development roadmap, as well as discussions
about future project goals. Even if your facility is currently not
relying on OCIO, if you're responsible for color management at a VFX /
Animation facility (or are an artist interested in such), we'd love to
have your input on these topics! Who knows, you may find it
preferable to use OCIO someday... ;)

* Imageworks Open-Source "Beer of a Feather"
Wed evening
Pub near hotels / convention center (location TBA)

The admins of several of the SPI-sponsored and -related open source
projects (OSL, Field3D, OpenColorIO, OIIO, Alembic, maybe more, we'll
see) have decided to hold a joint BOF / beer-related event at
SIGGRAPH. We're planning on Wednesday evening (August 10), after the
sessions end but before the usual evening festivities start. So mark
your calendars, it'll be a time to relax, enjoy a beer in lovely
Vancouver, and match names and faces from your favorite open source
projects. Exact location and time will be announced as we get closer
(but definitely Wednesday evening).

-- Jeremy


Review: OCIO Alpha Handling

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

https://github.com/imageworks/OpenColorIO/pull/135
https://github.com/imageworks/OpenColorIO/issues/85

As OCIO is used to implement image displays, it was inconvenient that
the software processing path was unable to handle alpha channels.
This meant channel swizzling *almost* worked (it could handle viewing
all channels other than alpha).

This check-in adds an optional alpha interface to OCIO::ImageDesc, in
a manner that does not impact ABI compatibility. Also, the Nuke
ociodisplay node has been updated to now support channel swizzling
(including alpha, and alpha overlay mode).

-- Jeremy


Review: Resurrect baking of Houdini HDL LUT's

DBR - Ben <dbr....@...>
 


Review: Native Per-Shot Looks

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

https://github.com/imageworks/OpenColorIO/pull/133
https://github.com/imageworks/OpenColorIO/issues/49

This adds a new config-level class, OCIO::Look. It's intent is to make
the re-use of Looks (such as per-shot looks), more convenient and
explicit. A new Nuke node (LookTransform) is also added. This
functionality mirrors the intent of the IIF's
LookModificationTransform (LMT).

The user defines a series of color transforms, assigns them a name
(such as 'CC_Red, DI_Look', 'Onset look', etc), and also specifies
what ColorSpace the processing should be applied in. Both forward and
inverse transforms can be specified, if needed. The DisplayTransform
has also been extended so that a look can be specified (and obeyed)
automatically. (example below). The use of Looks is purely optional.

Example Config look syntax:

# Defining the look

looks:
- !
name: CC_Red
process_space: lg10
transform: ! {offset: [0.05, 0, 0, 0]}
- !
name: CC_Cyan
process_space: lg10
inverse_transform: ! {offset: [0.05, 0, 0, 0]}


# Using it in a Display


displays:
sRGB:
- ! {name: Raw, colorspace: nc10}
- ! {name: Log, colorspace: lg10}
- ! {name: Film, colorspace: srgb8}
- ! {name: Film Red, colorspace: srgb8, look: CC_Red}
- ! {name: Film Cyan, colorspace: srgb8, look: CC_Cyan}

Within the Look blocks, all Context (per-shot) envvar support is fully obeyed.

This also makes it simpler to re-use looks across multiple display
devices (such as srgb + dlp). Previously, the look specification would
be in multiple places in the color configuration (for each device).

This is backwards compatible (both the binary ABI and the .ocio file
format). However, OCIO::DisplayTransform::setDisplayColorSpace is now
deprecated in favor of setDisplay/setView. The old interface is fully
supported, but the new Look functionality requires using the new API.
All internal nodes and examples have been updated to use the new API.

-- Jeremy


Review: Lut3d: Refactor to vector implementation

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

https://github.com/imageworks/OpenColorIO/pull/132
https://github.com/imageworks/OpenColorIO/issues/68

This is a refactor of the software trilinear 3d interpolation.

It was originally done as part of an SSE optimization, (and the SSE
code is left as an intermediate commit), but after performance testing
it was determined the SSE implementation offered no improvements so
it's been removed. But the newer vectorized 3d lut implementation is
much simpler code, and includes unit tests, so it's worth getting in
the codebase.

-- Jeremy


Re: mari 1.3v2 and ocio

Oliver Farkas <oliver...@...>
 

ok, thanks Jeremy.


On Tue, Jul 5, 2011 at 6:29 PM, Jeremy Selan <jeremy...@...> wrote:
It's probably likely that createPostFilter didn't make it into the
final rev of Mari 1.3v2. (thats definitely the API call that's needed,
not sure what createPostFilterCollection does).  I will check out mari
version capabilities when I get into work tomorrow, and add more
explicit error messages.

-- Jeremy

On Tue, Jul 5, 2011 at 12:20 AM, Oliver Farkas <oliver...@...> wrote:
> sorry, I forgot to mention, ocio version is 0.8.3.
>
> On Tue, Jul 5, 2011 at 5:19 PM, Oliver Farkas <oliver...@...>
> wrote:
>>
>> Hey Jeremy,
>> i'm trying to get ocio support in Mari (running 1.3v2 now). When I try to
>> run the ociodisplay.py script it throws me this error:
>> "Error: This version of Mari does not support the
>> mari.gl_render.createPostFilter API"
>> I checked the documentation and I could find
>> gl_render.createPostFilterCollection, but no createPostFilter.
>> Is this a version mismatch, or what do you reckon the problem might be?
>> Thanks,
>> Oliver
>


Re: mari 1.3v2 and ocio

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

It's probably likely that createPostFilter didn't make it into the
final rev of Mari 1.3v2. (thats definitely the API call that's needed,
not sure what createPostFilterCollection does). I will check out mari
version capabilities when I get into work tomorrow, and add more
explicit error messages.

-- Jeremy

On Tue, Jul 5, 2011 at 12:20 AM, Oliver Farkas <oliver...@...> wrote:
sorry, I forgot to mention, ocio version is 0.8.3.

On Tue, Jul 5, 2011 at 5:19 PM, Oliver Farkas <oliver...@...>
wrote:

Hey Jeremy,
i'm trying to get ocio support in Mari (running 1.3v2 now). When I try to
run the ociodisplay.py script it throws me this error:
"Error: This version of Mari does not support the
mari.gl_render.createPostFilter API"
I checked the documentation and I could find
gl_render.createPostFilterCollection, but no createPostFilter.
Is this a version mismatch, or what do you reckon the problem might be?
Thanks,
Oliver


Re: mari 1.3v2 and ocio

Oliver Farkas <oliver...@...>
 

sorry, I forgot to mention, ocio version is 0.8.3.


On Tue, Jul 5, 2011 at 5:19 PM, Oliver Farkas <oliver...@...> wrote:
Hey Jeremy, 

i'm trying to get ocio support in Mari (running 1.3v2 now). When I try to run the ociodisplay.py script it throws me this error:

"Error: This version of Mari does not support the mari.gl_render.createPostFilter API"

I checked the documentation and I could find gl_render.createPostFilterCollection, but no createPostFilter.

Is this a version mismatch, or what do you reckon the problem might be?

Thanks,
Oliver


mari 1.3v2 and ocio

Oliver Farkas <oliver...@...>
 

Hey Jeremy, 

i'm trying to get ocio support in Mari (running 1.3v2 now). When I try to run the ociodisplay.py script it throws me this error:

"Error: This version of Mari does not support the mari.gl_render.createPostFilter API"

I checked the documentation and I could find gl_render.createPostFilterCollection, but no createPostFilter.

Is this a version mismatch, or what do you reckon the problem might be?

Thanks,
Oliver

1661 - 1680 of 2243