How well do you know the Image Sequence node?

Maybe I’m a bit slow, but it’s taken me a bit of figuring to get the hang of how frame sequences work in the Image Sequence node of the compositor, and I’m pretty sure I’m not the only one.
compblog1

In any case, I finally decided that what I really needed was a sequence of frames with visible frame numbers that I could play around with, and that helped a lot. If anybody is interested in testing their skills with this, you can download a simple little exercise I put together here.

compblog2The tricky part for me was to figure out what, exactly, the fields “Frames”, “Start Frame” and “Offset” refer to. What do you think? Is this ridiculously obvious, or did it take you a few tries to get the right values in those fields? Do you see more than one way to get the solution?

Once you know how these fields work, it’s pretty simple, and I admit I’m not sure offhand how I’d go about making the interface more intuitive. (Although I would definitely prefer that the node were able to suck up multiple frames automatically, as when importing strips into the sequence editor.) There does seem to be some redundant functionality, but maybe that serves a purpose I haven’t come across yet. Anyway, I found playing around with this sequence to be helpful.

If you want to generate  similar sequences with other frame numbers, here’s the .blend file I used to make them. It’s simple, but maybe it will save somebody a few minutes.

Advertisements

9 Responses to “How well do you know the Image Sequence node?”

  1. I always enter the start frame and frame numbers in the wrong fields. My ideal interface would be similar to when you’re opening image sequences in DJV–it just knows via names which images are chunked into a “movie” as it interprets.

    On top of that. Adding footage to the sequence editor. Why is neither frame 1 OR the cursor the default? Sadness.

  2. Yeah, that’s something that bothers me a bit about the sequence editor too. Getting the strip into place always takes just a little too much messing around.

    As fo the Image Sequence node, one way to do it might be to simply allow VSE strips in the node. You could pull in the images you want in the VSE, trim them or make metastrips, and then work with them through a node. Then you’d just need to set the global frame that the strip should start on. I guess that could get confusing too though, if you had both postprocessing boxes checked.

  3. It’s not ridiculously obvious at all, and just about every other app that deals with frame sequences does it better. Back in the day, I’d lost many hours of work due to ‘human error’ in this particular ui. Ton was never interested over the many years that I complained about this and came up with proposals for improvements, good luck if you do the same.

  4. I agree, Matt. I think there are a couple of problems with this UI. One, is that the fields ask for information that is already accessible to the node (or basically moot), and the other is that it’s asking for essentially the same information twice, in two different ways.

    The “Frames” field, it seems to me, basically is an arbitrary maximum. I could put 10,000 in both nodes’ Frames field and everything would work fine. Usually the right answer would be the last frame number of the global animation, I guess. (By “global animation” I mean what’s in the Start and End fields on the Timeline). But it’s not clear to me why you need an arbitrary global maximum here. You need a file as the first file, a length, and a global frame to start the clip on. For more power (clipping, meta-strips, etc) it’d be nice to access a VSE strip.

    The redundant part is the Start and Offset, which seem to me to be the same, in opposite directions. Both of them slide the sequence up and down the timeline. The “meaning” of the two numbers is different, but unless I’m mistaken there’s basically no difference between them in practice. I do think Start is a bit of a doozy to explain though. It’s basically “what frame of the global should the imaginary first frame of the clip be placed on, counting back from whatever frame the clip actually starts on, as judged by its filename.”

    As for battling Ton/developers over ui/workflow/user-oriented changes, well, let’s just say that if I wanted to wade into that melee I would start with the recent no-fake-user-for-actions development, which still sends me into shuddering fits of wordless rage.

  5. Lukas Tönne Says:

    Ah, the dreaded Image node ;P

    I have already spent quite a bit of time screaming at the code in agony … The big problem with changing things in nodes is that it breaks existing stuff so easily. That’s what happened when i tried adding better support for multilayer (EXR) formats, when i discovered the many bad assumptions in the render layer code that made compatibility a real nightmare. I don’t really want to touch this node again.

    The solution imho for this kind of problem would be to instead implement a completely new node type. That way we wouldn’t have to care about existing crap and could get the design right without having to deal with compatibility issues. But then again, this seems to be something Ton is reluctant about, to avoid feature creep (quote: “for every button you add you should remove a button somewhere else”).

    • Lukas, thanks for your comment. Funny you should mention multilayer exr issues :). It was actually trouble I was having with those that first prompted me to make this little sample sequence. I’ve been having mostly small issues with them. Just the other day Campbell fixed a crash I reported that I think was related to them. A few other things are sort of buggy, like the occasional disappearing vector socket on a node for no reason (not predictably enough to file a bug report). Other things are just functionality I wish were there to make it easier to work with those files, such as multilayer exr support for the sequence editor, to make it possible to do a little bit of sequencing (I recently had to extend a clip by writing a Python script to rename a bunch of files on the hard drive, which was not very straightforward, for example). All in all though, I haven’t run into too many showstoppers with multilayer files yet.

      Anyway, thanks for the better understanding of what you’re up against!

  6. In teaching beginners, I’ve also noticed that ALL the nodes that have subnodes cause problems. If you don’t understand layer mode transfers yet, let alone the entire catalog of Add/Screen/Multiply/Softlight/Etc, it causes a lot of hurt. You’ll say “make a multiply node” and they go into the menu, and there’s no such thing. You’ll say “select your old mix node” and because it’s set to Add (and labeled thusly), you don’t know what to click on. Same thing happens with Math nodes, where it’s actually a node containing various sub-nodes, and once it’s set to Cosine it no longer says “Math” in its title.

    • Lukas Tönne Says:

      Good point! I’m a bit ambivalent about making more “atomic” nodes (i.e. replace the math mode with individual nodes for add, subtract, etc.) While it would remove a button you usually click just once per node, it would also make it more difficult to change e.g. from Add to Subtract.

      A straightforward solution would be to change the “Add” menu to list such nodes as math or mix with all the different modes expanded in a submenu or so (similar to how group nodes display all the available groups). It just requires some careful redesign of that menu to avoid too much cluttering.

      I’m also looking into alternative ways of creating nodes. We already have the material nodes “tree view” created by Brecht for Cycles nodes, this could be made into a regular feature. Beside that i’ve been testing a toolbar system with a kind of “drag and drop” behavior: http://www.youtube.com/watch?v=VaXNzjtLI3s
      It needs some form of panel organization of course (just a huge list atm). The idea is to make panels customizable by the user eventually.

      Sorry for going OT 😉

    • Personally, I don’t think there should be more atomic nodes for different operations. I think this is more a reminder that if you teach compositing, you need to be sure to teach students what operations are and how they work (why a white pixel times a black pixel equals a black pixel, and why a white pixel plus a black pixel equals a white one, etc) before diving into node stuff. When I teach about compositing I almost always start with some simple examples in GIMP using the layer types.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: