Date   

Review: Added read/write support for Iridas .itx format

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


Review: Updated serialization code to log warnings when unknown variables are encountered

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

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

Updated much of the serialization code to log warnings when unknown
tokens are encountered. Also, updated MatrixTransform to expose
separate get/set accessors for matrix vs. offset. Suitable for 1.0 /
0.8 (this will ensure parsing code is identical between versions, as
is desired).

Addresses issues:
https://github.com/imageworks/OpenColorIO/issues/146
https://github.com/imageworks/OpenColorIO/issues/152

-- Jeremy


Review: 0.9/1.0 API Changes

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

These are the (proposed) API Changes between 0.8 -> 1.0
(A bit of an omnibus pull request)

Addresses issues: #36, #131, #130
(All other github API-tagged are not being considered for 1.0.)

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

--- Functions Removed ---
ColorSpace::getEditableTransform
ColorSpace::isTransformSpecified
Config::getEditableTransform
Config::setDisplayColorSpaceName
GroupTransform::getEditableTransform
DisplayTransform::setDisplayColorSpaceName
DisplayTransform::getDisplayColorSpaceName

--- Other Changes ---
PlanarImageDesc / PackedImageDesc now have simpler (non-virtual)
implementations, which is more consistent with the rest of OCIO.
Change should be source compatible in majority of cases.

-- Jeremy


Review: Minor OCIOFileTransform improvements and misc

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

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

Dynamically showing the cccid controls only when loading a .cc/.ccc file, dynamic tooltip listing supported formats, and enables including the Python UCS variant in the python module install path


Re: 0.9.X

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

On 03/09/2011, at 2:24 AM, Jeremy Selan wrote:

After further consideration, I think it's in the project's best
interest to take advantage of this major version bump (v0 -> v1) to
fix a few of the minor API issues prior to the 1.0 release.
Sounds like a great idea - starting 1.0 free of deprecated functions and so on sounds more than worth any minor inconveniences now!


0.9.X

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

After further consideration, I think it's in the project's best
interest to take advantage of this major version bump (v0 -> v1) to
fix a few of the minor API issues prior to the 1.0 release. We've
therefore created a 0.9 branch for this effort. The rationale is that
there's a relatively low number of users currently (a lot of people
are waiting for 1.0), so for a tiny bit of effort now, we can make
life simpler for a much larger number of people going forward.

Branch summary:
0.8.X - Stable branch, suitable for production deployment.
0.9.X - pre-1.0 API dev branch. For testing only.

- Note: the same .ocio configuration will continue to work identically
on both branches
- All bugfixes / additions not related to API will be patched to both branches
- The master branch will continue to point at 0.8 (stable) until 1.0
RC1 is ready
- There won't be an official 0.9.0 tagged release, that build will
become 1.0 RC1
- We're still on track to have 1.0 RC ready for Sep 16th, and 1.0.0 by Oct 1st.

All API changes were looking at are basically minor issues, such as
removing deprecated functions, etc. Porting from 0.8 -> 0.9/1.0 in
most cases will just be a recompile (source code compatible), and
otherwise should be 1 line changes. No 'conceptual' changes will be
attempted / allowed.

-- Jeremy


Review: Split ColorSpace.family into ColorSpace.family / ColorSpace.equalitygroup

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

https://github.com/imageworks/OpenColorIO/pull/147
https://github.com/imageworks/OpenColorIO/issues/113

Split ColorSpace.family into ColorSpace.family / ColorSpace.equalitygroup

This allows one to distinguish amongst ColorSpace grouping suitable for
user interfaces, vs. ColorSpace groupings suitable for equality comparisons.
Both are now optional, which should lead to less confusion amongst users
crafting profiles.

Addresses issue #113

This may be the last conceptual change before 1.0 RC1 (all that
remains is minor API cleanup / documentation / testing)

-- Jeremy


Siggraph and OpenColorIO 1.0

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

OCIO Folks,

First, thanks to all those who made it out to Siggraph (both the
OpenColorIO Meetup, and our Open-Source 'Beer of a Feather'). We've
had a lot of positive feedback, and couldn't have been happier with
the turnout at both events! We're already looking forward to hosting
repeat events next year in LA.


Second, to summarize the take away the take away message from
Siggraph... "We <major studio> are really interested in using
OpenColorIO. How soon until 1.0 is released?" Considering that we
(Imageworks) rely on OCIO daily, and that commercial software will
soon be shipping with the libraries built in (thanks, Foundry!) ,
there's a strong reason to lock off on 1.0 as soon as possible. Here's
the plan:

OCIO 1.0 Release Candidate by Sept 9 (10 days from now)
OCIO 1.0 Official Release by Oct 1st (hopefully sooner).

For those of you already using OCIO, the changes from 0.8 to 1.0 will
be minimal. Essentially, there's only one modification that's
required before the 1.0 release, and that's to clarify the use of
ColorSpace families.
http://github.com/imageworks/OpenColorIO/issues/113).

Furthermore, if this is the only feature we add before 1.0, 0.8 and
1.0 will be ABI compatible! Which means the new library will 'just
work', even for those who already have rolled it out in production.


Finally, we've gotten some wonderful press coverage from the fx-guide
site recently. Just thought I'd pass it along:
http://www.fxguide.com/featured/the-art-of-digital-color/
http://www.fxguide.com/fxguidetv/fxguidetv-116-adobe-alembic-and-opencolorio/


Cheers,
Jeremy


Re: Minor issue with /software/ocio/share/ocio/setup_ocio.sh

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

Yep, oops, that was a copy-and-paste error..

On 13/08/2011, at 9:27 AM, Jeremy Selan wrote:

Thanks. DYLD_LIBRARY_PATH is for mac, that line is definitely inconsistent.

Should I tidy it up or would you prefer to submit the pull request?
(Then you get credit in git).

-- Jeremy

On Thu, Aug 11, 2011 at 10:45 AM, vfxGer <ger...@...> wrote:
Minor issue in the /software/ocio/share/ocio/setup_ocio.sh
export LD_LIBRARY_PATH="${OCIO_EXECROOT}/lib:${DYLD_LIBRARY_PATH}"
should be
export LD_LIBRARY_PATH="${OCIO_EXECROOT}/lib:${LD_LIBRARY_PATH}"


Re: Minor issue with /software/ocio/share/ocio/setup_ocio.sh

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

Thanks. DYLD_LIBRARY_PATH is for mac, that line is definitely inconsistent.

Should I tidy it up or would you prefer to submit the pull request?
(Then you get credit in git).

-- Jeremy

On Thu, Aug 11, 2011 at 10:45 AM, vfxGer <ger...@...> wrote:
Minor issue in the /software/ocio/share/ocio/setup_ocio.sh
export LD_LIBRARY_PATH="${OCIO_EXECROOT}/lib:${DYLD_LIBRARY_PATH}"
should be
export LD_LIBRARY_PATH="${OCIO_EXECROOT}/lib:${LD_LIBRARY_PATH}"


Minor issue with /software/ocio/share/ocio/setup_ocio.sh

vfxGer <ger...@...>
 

Minor issue in the /software/ocio/share/ocio/setup_ocio.sh
export LD_LIBRARY_PATH="${OCIO_EXECROOT}/lib:${DYLD_LIBRARY_PATH}"
should be
export LD_LIBRARY_PATH="${OCIO_EXECROOT}/lib:${LD_LIBRARY_PATH}"


Re: Reminder: Siggraph Festivities

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

Thanks for all those who showed up at yesterday's OCIO BOF! It was
wonderful to see so many of you in person.

A correction regarding today's 'beer of a feather' event:

We will now be meeting in the adjacent "Irish Heather Pub" due to a
double booking. If you go to the Whiskey room, they will redirect you
(they are connected).

Sorry for the confusion!

-- Jeremy

On Fri, Aug 5, 2011 at 9:38 AM, Jeremy Selan <jeremy...@...> wrote:
* Open Source VFX "Beer of a Feather"
Wednesday, August 10, 2011, 6:00 pm
Shebeen Whiskey House, 212 Carrall Street, Vancouver, BC V6B 2J1, Canada
Located right next to Irish Heather GastroPub
about a 15 minute walk from the convention center
http://maps.google.com/maps/place?cid=9727058349750443765

Informal meet-up for developers, contributors, and users of
VFX-related open source projects, including Alembic, Coretex, Field3D,
OpenColorIO, OpenEXR, OpenImageIO, Partio, Ptex, SeExpr, and more.
Relax in Vancouver, enjoy a beer, match faces to the names from your
favorite open source mail lists.  Beer/wine/appetizers provided (until
our tab fills up -- don't come too late!)

Sponsors:
   Sony Pictures Imageworks
   Peregrine Labs
   Walt Disney Animation Studios
   Image Engine
   Weta Digital
   OpenImageIO


Re: Nested config files...?

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

Hugh,

Nested config files are an interesting idea, and I'm all for ideas
that make it easier to maintain a bunch of shows in the long term. Let
me think about it over siggraph week, and see if I have any further
thoughts.

One counter argument though... at Imageworks, we have custom profiles
for each show, and in ~7 years of using a color pipeline essentially
equivalent to what you see with OCIO, we've never yet needed to add
this functionality. One of the reasons is that often our shows use
very different color pipelines, and the linear connection spaces arent
always suitable for the approach you specify. (I.e. a colorspace
definition created for the spi-vfx profile wouldnt typically be
appropriate for inclusion in the spi-cg profile). Another reason is
that at SPI we tend to work on very large productions and thus have
the luxury of color customization per show. Perhaps at smaller
facilities, with shorter schedule, a master color config approach
would be more helpful though? Also, we tend to want to lock shows off
in terms of color, and having a single file with all color definitions
makes this very easy to guarantee.

What color management approach are you currently using? Does it
support this type of workflow?

If you're interested in prototyping such a workflow in OCIO, you can
probably mock it up using the existing public python API. Remember
that the API can be used to dynamically load / edit / and save ocio
profiles as needed.

Example:

makeocioshowprofile <master.ocio> <show.ocio> <output.ocio>

This script could load master.ocio. Add any additional colorspaces as
defined in show.ocio, and save it to output.ocio. (which would then
be referenced in the client apps). I'm happy to help with the python
configuration manipulation, if you think this approach is interesting.

My gut reaction says that this may be a can of worms, though.
Configurations are already rather complicated, and only thinly
documented. I'd much rather devote our limited development efforts
(pre 1.0) to making what we have bullet-proof (in both code, user
manuals, and documentation), as opposed to adding new features. As
something like this could always be added in a binary compatible
manner in the future, there's really no harm in taking it slow.

Will you be at Siggraph? I'd be happy to discuss in person if you're interested.

Cheers,
Jeremy

On Thu, Aug 4, 2011 at 3:46 PM, DBR - Ben <dbr....@...> wrote:
Hm, I quite like the idea, but equally like how simple the configs are..
There are a few technical reasons that nested configs might be a bit
confusing:
- The most obvious issue is LUT search paths - if the parent profile
contains "luts: parents_lut_dir/" and the child contains "luts:
childs_lut_dir/", where would you search for a LUT? Only the child (as its'
lut: overrides the parent)? Both? The parent's path only for colorspaces
defined in the parent etc..?
- Would the parent profile need to be a valid (working) config? If so, it
would need to define at least one display and a view.. In which case, would
the child profile be capable of removing display devices?
Seems like the main benefit to nested-configs would be tidying the standard
colourspaces into a separate file (e.g defining the various common log
transforms in one space, rather than copying-and-pasting them everywhere)
Not sure exactly how it would work, but what about a way of bundling one or
more colorspace definitions into a file (including LUT's and such)? Then you
could include this file by doing something like:
colorspaces:
    - !<IncludeFile>
      filepath: /path/to/various_logs.ociospaces
    - !<ColorSpace>
        name : etc
This would circumvent inheriting of displays/search-paths, but somewhat
treads on the toes of https://github.com/imageworks/OpenColorIO/issues/30
On 4 August 2011 18:23, Hugh Macdonald <hugh.ma...@...> wrote:

Nothing like rocking the boat after only just getting on...

I'm still very new when it comes to OpenColorIO, so I have no idea if this
has been discussed already and discounted, or whether people have
philosophical issues with doing something like this...


What do people think of the ability to have nested config files?

So you would have a base level config, which would have to have everything
that the current one has.

You could then have other config files that would supersede, or append to,
values in the base. Defined by setting $OCIO to
"/path/to/config.ocio:/path/to/another/config.ocio"

So you might have a company-wide one, but then a show-specific one that
just contains the following.

============================================
ocio_profile_version: 1

displays:
  default:
    - !<View> {name: sRGB, colorspace: sRGB}
    - !<View> {name: rec709, colorspace: rec709}
    - !<View> {name: Film, colorspace: proj_film}

active_views: [sRGB, rec709, Film]

colorspaces:
  - !<ColorSpace>
    name: proj_film
    family: proj_film
    bitdepth: 8ui
    description: |
      Display space for film emulation for this specific project
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: raw, dst: lg10}
        - !<FileTransform> {src: lg10_to_film_project.csp, interpolation:
linear}
============================================

This would enable a core facility colour spec to be defined, with tweaks
as needed on a per-project basis (based, maybe, on LUTs defined by a DI
facility)


Another alternative would be to have one config file pointed at by $OCIO
something like:

============================================
ocio_profile_version: 1

parent_config: /path/to/a/config/file/to/load/first/config.ocio

displays:
  default:
    - !<View> {name: sRGB, colorspace: sRGB}
    - !<View> {name: rec709, colorspace: rec709}
    - !<View> {name: Film, colorspace: proj_film}

active_views: [sRGB, rec709, Film]

colorspaces:
  - !<ColorSpace>
    name: proj_film
    family: proj_film
    bitdepth: 8ui
    description: |
      Display space for film emulation for this specific project
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: raw, dst: lg10}
        - !<FileTransform> {src: lg10_to_film_project.csp, interpolation:
linear}
============================================


Thoughts?


--
Hugh Macdonald
nvizible – VISUAL EFFECTS

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

www.nvizible.com


Re: New to OCIO, and viewer processes in Nuke

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

Addressing Jeremy's comment, at Imageworks, we've split up the share/nuke/ocionuke/viewer.py contents such that the registering of ViewerProcess nodes happens during the init.py evaluation and the Viewer lut default value is set during the menu.py evaluation.  This was done to prevent the error that occurs during batch mode when opening a script that has a Viewer lut set to an unregistered value.  The nuke.knobDefault function must run within the menu.py evaluation for it to work successfully, hence the split.

-sean


On Wed, Aug 3, 2011 at 10:09 AM, Jeremy Selan <jeremy...@...> 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 <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
>


Reminder: Siggraph Festivities

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

* Open Source VFX "Beer of a Feather"
Wednesday, August 10, 2011, 6:00 pm
Shebeen Whiskey House, 212 Carrall Street, Vancouver, BC V6B 2J1, Canada
Located right next to Irish Heather GastroPub
about a 15 minute walk from the convention center
http://maps.google.com/maps/place?cid=9727058349750443765

Informal meet-up for developers, contributors, and users of
VFX-related open source projects, including Alembic, Coretex, Field3D,
OpenColorIO, OpenEXR, OpenImageIO, Partio, Ptex, SeExpr, and more.
Relax in Vancouver, enjoy a beer, match faces to the names from your
favorite open source mail lists. Beer/wine/appetizers provided (until
our tab fills up -- don't come too late!)

Sponsors:
Sony Pictures Imageworks
Peregrine Labs
Walt Disney Animation Studios
Image Engine
Weta Digital
OpenImageIO


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

We'll be discussing 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... ;)


Re: Nested config files...?

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

Hm, I quite like the idea, but equally like how simple the configs are..

There are a few technical reasons that nested configs might be a bit confusing:

- The most obvious issue is LUT search paths - if the parent profile contains "luts: parents_lut_dir/" and the child contains "luts: childs_lut_dir/", where would you search for a LUT? Only the child (as its' lut: overrides the parent)? Both? The parent's path only for colorspaces defined in the parent etc..?

- Would the parent profile need to be a valid (working) config? If so, it would need to define at least one display and a view.. In which case, would the child profile be capable of removing display devices?

Seems like the main benefit to nested-configs would be tidying the standard colourspaces into a separate file (e.g defining the various common log transforms in one space, rather than copying-and-pasting them everywhere)

Not sure exactly how it would work, but what about a way of bundling one or more colorspace definitions into a file (including LUT's and such)? Then you could include this file by doing something like:

colorspaces:
    - !<IncludeFile>
      filepath: /path/to/various_logs.ociospaces

    - !<ColorSpace>
        name : etc

This would circumvent inheriting of displays/search-paths, but somewhat treads on the toes of https://github.com/imageworks/OpenColorIO/issues/30

On 4 August 2011 18:23, Hugh Macdonald <hugh.ma...@...> wrote:
Nothing like rocking the boat after only just getting on...

I'm still very new when it comes to OpenColorIO, so I have no idea if this has been discussed already and discounted, or whether people have philosophical issues with doing something like this...


What do people think of the ability to have nested config files?

So you would have a base level config, which would have to have everything that the current one has.

You could then have other config files that would supersede, or append to, values in the base. Defined by setting $OCIO to "/path/to/config.ocio:/path/to/another/config.ocio"

So you might have a company-wide one, but then a show-specific one that just contains the following.

============================================
ocio_profile_version: 1

displays:
  default:
    - !<View> {name: sRGB, colorspace: sRGB}
    - !<View> {name: rec709, colorspace: rec709}
    - !<View> {name: Film, colorspace: proj_film}

active_views: [sRGB, rec709, Film]

colorspaces:
  - !<ColorSpace>
    name: proj_film
    family: proj_film
    bitdepth: 8ui
    description: |
      Display space for film emulation for this specific project
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: raw, dst: lg10}
        - !<FileTransform> {src: lg10_to_film_project.csp, interpolation: linear}
============================================

This would enable a core facility colour spec to be defined, with tweaks as needed on a per-project basis (based, maybe, on LUTs defined by a DI facility)


Another alternative would be to have one config file pointed at by $OCIO something like:

============================================
ocio_profile_version: 1

parent_config: /path/to/a/config/file/to/load/first/config.ocio

displays:
  default:
    - !<View> {name: sRGB, colorspace: sRGB}
    - !<View> {name: rec709, colorspace: rec709}
    - !<View> {name: Film, colorspace: proj_film}

active_views: [sRGB, rec709, Film]

colorspaces:
  - !<ColorSpace>
    name: proj_film
    family: proj_film
    bitdepth: 8ui
    description: |
      Display space for film emulation for this specific project
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: raw, dst: lg10}
        - !<FileTransform> {src: lg10_to_film_project.csp, interpolation: linear}
============================================


Thoughts?


--
Hugh Macdonald
nvizibleVISUAL EFFECTS

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

www.nvizible.com


Nested config files...?

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

Nothing like rocking the boat after only just getting on...

I'm still very new when it comes to OpenColorIO, so I have no idea if this has been discussed already and discounted, or whether people have philosophical issues with doing something like this...


What do people think of the ability to have nested config files?

So you would have a base level config, which would have to have everything that the current one has.

You could then have other config files that would supersede, or append to, values in the base. Defined by setting $OCIO to "/path/to/config.ocio:/path/to/another/config.ocio"

So you might have a company-wide one, but then a show-specific one that just contains the following.

============================================
ocio_profile_version: 1

displays:
  default:
    - !<View> {name: sRGB, colorspace: sRGB}
    - !<View> {name: rec709, colorspace: rec709}
    - !<View> {name: Film, colorspace: proj_film}

active_views: [sRGB, rec709, Film]

colorspaces:
  - !<ColorSpace>
    name: proj_film
    family: proj_film
    bitdepth: 8ui
    description: |
      Display space for film emulation for this specific project
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: raw, dst: lg10}
        - !<FileTransform> {src: lg10_to_film_project.csp, interpolation: linear}
============================================

This would enable a core facility colour spec to be defined, with tweaks as needed on a per-project basis (based, maybe, on LUTs defined by a DI facility)


Another alternative would be to have one config file pointed at by $OCIO something like:

============================================
ocio_profile_version: 1

parent_config: /path/to/a/config/file/to/load/first/config.ocio

displays:
  default:
    - !<View> {name: sRGB, colorspace: sRGB}
    - !<View> {name: rec709, colorspace: rec709}
    - !<View> {name: Film, colorspace: proj_film}

active_views: [sRGB, rec709, Film]

colorspaces:
  - !<ColorSpace>
    name: proj_film
    family: proj_film
    bitdepth: 8ui
    description: |
      Display space for film emulation for this specific project
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: raw, dst: lg10}
        - !<FileTransform> {src: lg10_to_film_project.csp, interpolation: linear}
============================================


Thoughts?


--
Hugh Macdonald
nvizibleVISUAL EFFECTS

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

www.nvizible.com


Review: Nuke OCIOCDLTransform

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

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

Nuke's OCIOCDLTransform gains an option to load from a source .cc/.ccc
file. Also, OCIOCDLTransform will display the source file contents in
the interface. This makes it easier to develop shot cc pipelines where
the artists can see what values are being used for plate equalization.

-- Jeremy


Re: New to OCIO, and viewer processes in Nuke

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

Oh, agreed, re-registering the None process is wrong - I didn't put too much thought into this when writing the function, as I didn't need it at the time. Fork away \o/


On 3 August 2011 18:37, Hugh Macdonald <hugh.ma...@...> wrote:
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
nvizibleVISUAL 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

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

1641 - 1660 of 2242