AcademySoftwareFoundation
Channel swizzling in Nuke's OCIO Display is done before the color transform
This is mentioned in #341. This behavior is not intuitive in Nuke - when an artist presses "R", they expect to see the red channel shuffled into rgb, not the result of feeding only the red channel through the viewer process.
The current approach is inconsistent with Nuke's root LUTs and other software (e.g. RV) and has caused enough confusion here that I'm going to build a custom OCIODisplay.so to fix it.
FYI, here's how to fix it:
- check out the same number version of OpenColorIO as used by Nuke (you'll see the version on the lib in the nuke directory, e.g. on Nuke 9 you'll see libOpenColorIO.so.1.0.9).
- edit src/nuke/OCIODisplay/OCIODisplay.{cpp,h} and remove all references to m_channel, including the entire block labeled "Add Channel swizzling"
- build with the appropriate version of gcc (currently 4.1.2 for Nuke 8 and Nuke 9) and override OCIO_NAMESPACE to be FnOpenColorIO (otherwise you will get an error complaining about missing symbols)
Nuke already does the channel swizzling after the display process, so there's no need for the channel_selector knob.
I just wanted to add my voice to this. Regardless of the original justification mentioned in https://github.com/imageworks/OpenColorIO/issues/341, the fact that the channel-swizzling is done before the display transform is not acceptable behavior in Nuke.
When using display transforms that involve channel cross-talk (e.g. anything in ACES), Nuke's viewer suddenly becomes unreliable when isolating channels, which can be a real problem for certain channel-wise corrections operations like grain-matching.
Say we have an image like this (image with some red/green/blue text overlayed to make cross talk really obvious):
set cut_paste_input [stack 0]
version 10.0 v4
push $cut_paste_input
Text {
output {rgba.red -rgba.green -rgba.blue rgba.alpha}
message red
font /usr/share/fonts/bitstream-vera/Vera.ttf
size 500
xjustify center
yjustify center
box {0 389 2044 1167}
center {1024 778}
}
Text {
output {-rgba.red rgba.green -rgba.blue rgba.alpha}
message green
font /usr/share/fonts/bitstream-vera/Vera.ttf
size 500
xjustify center
yjustify center
box {0 389 2044 1167}
center {1024 778}
}
Text {
output {-rgba.red -rgba.green rgba.blue rgba.alpha}
message blue
font /usr/share/fonts/bitstream-vera/Vera.ttf
size 500
xjustify center
yjustify center
box {0 389 2044 1167}
center {1024 778}
}
Even if I have a LUT with cross-talk: when I press "r" I expect to only see text saying "red". In other words, channel swizzling fills r/g/b with the contents of r, then displays it via the display transform (the ordering described in #341)
We have had RV and Nuke setup like this for a long and have never had any artist find this confusing.
Accidentally we did briefly have RV configured to do channel isolation post-LUT and people asked me why they had "detail appearing from other channels when viewing one channel" or something like that.
So I very much disagree that this is unacceptable behaviour
inconsistent with Nuke's root LUTs
Hm, how are you comparing these? None of the root LUT's have cross-talk as far as I'm aware
and other software (e.g. RV)
I could be mistaken, but RV appears to do "channel isolation" before the display LUT - the The "RGBA or Y Isolate" step is before the "Display LUT" step under the display section of the "How a Pixel Gets from a File to the Screen" section of the RV manual
I can see the argument for the pre-LUT isolation in some scenarios, but let me elaborate a bit more on a couple of things.
First, saying the OCIODisplay node is "inconsistent with Nuke's root LUTs" was poor wording on my part (end-of-day brain perhaps), and totally missed the mark. What I was getting at is that, if you create your own viewer process that uses the OCIODisplay node to apply a display transform that includes channel cross-talk, except you put it inside a Group node (so that Nuke can't find the channel_selector knob), you will get post-LUT swizzling in the viewer. In other words, Nuke's default viewer pipeline (with gain and gamma elided) is Source -> Display Transform -> Channel Isolation.
Now, I'm certainly open to the idea that Nuke has been doing this "wrong" for a couple of decades (it wouldn't be the first thing...), but right now, OCIODisplay is the black sheep.
Second, RV is not really a clear-cut A-or-B scenario, since the pipeline groups allow operations to be ordered pretty arbitrarily. You are correct that the out-of-the-box behavior is to apply pre-LUT swizzling, but that is not a guarantee of the software, and becomes a moot point when viewing imagery with baked color transforms (often the case during reviews).
RV's channel isolation behavior is hardcoded to only work with an RVDisplayColor node, so depending on the order in which the nodes in the display pipeline are arranged (assuming you leave an RVDisplayColor node in there), you could get either behavior. Combine that with the fact that the (RV) OCIODisplay node actually causes behavioral problems when used in a display pipeline, and the waters get even more murky.
In our case, we are applying OCIO displays in the source groups' look pipelines to avoid the aforementioned problems, so swizzling is implicitly post-LUT at all times (which, conveniently, matches Nuke's application behavior). The unique behavior of the Nuke OCIODisplay node becomes problematic when a reviewer (using RV) starts seeing things in individual channels that the Nuke artist literally cannot see in Nuke unless they manually create a color setup through which to view the image.
We are doing the same thing as Nathan describes - OCIODisplay in RV's look pipeline, and a wrapped OCIODisplay in nuke to hide channel_selector. Both cases apply the a channel swizzle post-LUT. We had a fair number of confused artists raise their hand when OCIODisplay was first introduced as the viewer process, and every now and then it comes back to bite us when it finds itself unwrapped for whatever reason. Early on, we used OCIODisplay as part of a VIEWER_INPUT gizmo, and channel_selector was always safely tucked away.
I definitely can see the reason behind a pre-LUT swizzle. This does, however, produce a fair amount of chaos when folks A/B between baked media and the originals they came from, with the display transform applied. post-LUT delivers more consistent results between different types of media with different display transform configurations.
How about other applications - even those with no OCIO support at all? Has anybody spun though other software packages to see how they stack up?
