After Effects plug-in
Brendan Bolles
called beta. You can see it in the "aftereffects" branch of my Github
fork:
https://github.com/fnordware/OpenColorIO/tree/aftereffects
And you can download compiled versions here:
http://www.fnordware.com/OpenColorIO/
It's one plug-in that has most of the functionality found in the Nuke
plug-ins plus ocio2icc and ociobakelut.
I'm sure many things I've done do not adhere to OCIO coding standards,
including:
1. Building things with Xcode and Visual Studio, not CMake. That's how
the Adobe SDK is set up and I'm too lazy to figure out how to switch
to something else.
2. Using a hard-coded OpenColorABI.h file because I don't have CMake
making me one.
3. Not self-configuring using an $OCIO environment variable. You have
to pick an .ocio file (or LUT) yourself. AE users don't generally
launch from the command line.
4. Not using shared libraries, because I hate them. Static linking
4ever!
Let me know what you think.
Brendan
Jeremy Selan
Brendan Bolles
> I'd love to be able to roll portions of your work into the main fork, even
> if you'd consider the plugin to be in an alpha state.
> files (amongst others) added to your OCIO fork, and I'd prefer to exclude
Great! Yeah, I think we can leave the .xcodeproj and .vcproj files out
of the main distribution, but I'll keep them in my fork. I'm sure it's
possible to reverse engineer the projects into CMake, but I've never
used it.
In that case, there are a few files in xcode/aftereffects and vc/vc9/
aftereffects that I should move into src/aftereffects. I also just
read the coding guidelines, so I should probably make a pass through
and attempt to adhere to them.
>
> Looking at your screenshot, I'm a tiny bit confused:http://www.fnordware.com/OpenColorIO/screenshot.png
>
> Have you rolled all the OCIO nodes into a single 'node' in AE? Is that what
> the Display / Convert knob does? Is this appropriate? (It may be, I'm not
> familiar with AE).
Yes, that's what I've done. I saw that Nuke uses several different
nodes, which is definitely the way to do it for Nuke. But I have this
feeling that the monolithic approach makes more sense for After
Effects. Any other AE users on this list want to chime in?
BTW, what you are seeing are not knobs, but a custom interface I had
to make because AE doesn't support text/path knobs and doesn't do
menus that might dynamically change based on which OCIO configuration
is being used. So I have to draw the UI and handle events myself. This
is one reason the monolithic version can work: the interface changes
depending on which mode it's in. If you want to try it out, you can
download the 30-day After Effects trial.
I don't have access to a Nuke license at the moment (the Personal
Learning Edition doesn't read plug-ins, not that I was able to build
them), so I haven't actually seen the plug-ins working. I looked
through the code and used my imagination, but would love to see some
screenshots. I think it would be really great to post a video demo to
give other people an idea of how this all works to further the
adoption of OCIO. For me to get an idea, I had to spend two days
building ociodisplay.
Brendan
Brendan Bolles
an option to process on the GPU.
http://www.fnordware.com/OpenColorIO/
One thing I've noticed is that if you do a conversion like Cineon to
Linear, the results are clipped to 1.0 if I use the GPU. Is that
expected? I *think* I'm creating a floating point context properly,
although I'm an OpenGL newbie so who knows. (Feel free to look at my
"aftereffects" branch.)
Fortunately, log2lin operations are already pretty fast on the CPU.
The slower operations that do film previews are intended to produce
clipped output anyway, so it's still very useful.
OK, one other question: as you know there is no
Config::getDefaultInput() function, so I use
"scene_linear" (OCIO::ROLE_SCENE_LINEAR). But then it's a little weird
to have an option selected initially that doesn't appear in the list
for that config. I notice that the first item in the list is usually
linear, but is that enforced? Or even if it isn't, is there an issue
if I just used the first item in the list as my default?
Brendan
Jeremy Selan
One thing I've noticed is that if you do a conversion like Cineon to
Linear, the results are clipped to 1.0 if I use the GPU. Is that
expected? I *think* I'm creating a floating point context properly,
although I'm an OpenGL newbie so who knows. (Feel free to look at my
"aftereffects" branch.)
That's not expected, I'll check it out. Which config were you testing with? Nuke default?
Fortunately, log2lin operations are already pretty fast on the CPU.
The slower operations that do film previews are intended to produce
clipped output anyway, so it's still very useful.
OK, one other question: as you know there is no
Config::getDefaultInput() function, so I use
"scene_linear" (OCIO::ROLE_SCENE_LINEAR). But then it's a little weird
to have an option selected initially that doesn't appear in the list
for that config. I notice that the first item in the list is usually
linear, but is that enforced? Or even if it isn't, is there an issue
if I just used the first item in the list as my default?
ROLE_SCENE_LINEAR is an alias to one of the regular color spaces, which 'getColorSpace' resolves.
So you can query the real name of SCENE_LINEAR doing something like,
cs = config.getColorSpace(ROLE_SCENE_LINEAR)
if cs: default = cs.getName()
else: default = ''
-- Jeremy
Brendan Bolles
On Dec 12, 1:56 pm, Jeremy Selan <jeremy.se...@gmail.com> wrote:
> That's not expected, I'll check it out. Which config were you testing
> with? Nuke default?
I see it with Nuke default, or any other one.
(BTW, I've only tested the GPU on Mac because I'm running Windows in
VMware. Will rectify that soon.)
> cs = config.getColorSpace(ROLE_SCENE_LINEAR)
> if cs: default = cs.getName()
> else: default = ''
Just what the doctor ordered. Thanks!
Brendan