After Effects plug-in


Brendan Bolles <bre...@...>
 

Hey everyone, I've got an OCIO After Effects plug-in ready to be
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 <jeremy...@...>
 

That's awesome, Brendan!  Thanks so much for your effort!

For those who haven't checked this out, I'd like to point out that the installer even comes with a nicely done pdf manual.  Very slick. :)

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. (While the main OCIO library is in a stable 1.0 state, I see no reason not to add beta plugins to the tree as they become available).   I see you have lots of .xcodeproj files (amongst others) added to your OCIO fork, and I'd prefer to exclude those. But adding src/aftereffects looks great, and would at the very least let people see what you've done.   Are you familiar with OpenColorIO's license agreement?  After you submit that (privately to me + opensource at imageworks.com), I'm happy to roll it in.

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

Have you used the Nuke OCIO plugins?  I'd probably like to keep the naming / UIs as similar as possible between different compositing applications. If you'd like me to post equivalent screen shots for the nuke nodes, I'd be happy to.   At the least, in Nuke we have separate nodes for colorspace conversions, vs the display transform.  The reason is these have different interfaces, so it makes sense to keep them separate for clarity.

Any long term chance to get this compiled in cmake?  Is it a requirement for after effects plugins to be compiled in xcode/visual studio?

Kudos on posting installers.

Cheers,
Jeremy

On Mon, Nov 28, 2011 at 2:18 PM, Brendan Bolles <bre...@...> wrote:
Hey everyone, I've got an OCIO After Effects plug-in ready to be
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


Brendan Bolles <bre...@...>
 

On Nov 30, 10:47 am, Jeremy Selan <jeremy...@...> wrote:
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.
I see you have lots of .xcodeproj
files (amongst others) added to your OCIO fork, and I'd prefer to exclude
those. But adding src/aftereffects looks great.
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 <bre...@...>
 

I've posted another beta of the After Effects plug-in, this time with
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 <jeremy...@...>
 


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

On Dec 12, 1:56 pm, Jeremy Selan <jeremy...@...> 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