On Dec 15, 2008, at 11:55 PM, Chris Wood wrote:
Ron,
The iterator is a pink patch - these patches generally render
something, and you're not allowed to pass any values back out of
them. It seems annoying, but it's actually essential - if you passed
an image back out of an iterator, you'd be passing perhaps 10
different images down one wire in one frame, and the next patch down
the line will only be able to process one of them.
Hmm - the fact that you said "if you passed an image..." indicates to
me that the restriction isn't actually essential. Clearly there are
some types of information that would be perfectly fine for an iterator
to return, if the restriction wasn't there. I can certainly
understand though, that Apple might not have wanted to deal with all
of the boundary conditions that allowing outputs on iterators would
have caused.
I think the only ways to handle a changing list of images properly
are with javascript , or with a custom plugin. I've done it with
javascript before, it can be tricky but it's certainly possible. The
only performance limit really is that the javascript will only run
once per frame, so if you're only loading one image each time it
runs and you have 100 images, it will take 100 frames. You can get
around that by having say 10 image loaders feeding it, so you can
load 10 images per frame, but for me at least the image loading
speed was the limiting factor anyway.
Actually, my performance factor is that the processing I wanted to do
on each image is fairly complex, and I want to make sure that it only
gets done once, when the image first appears in the composition. I
don't want to redo every image whenever the list changes, and I
certainly don't want to be continually reprocessing the images.
My solution was to separate the processing of the images from the
display composition, and let the application handle optimizations.
That's why this became somewhat of a science project.
Chris
On 16 Dec 2008, at 04:52, Ron Aldrich wrote:
On Dec 14, 2008, at 4:23 PM, Christopher Wright wrote:
I've been running into what seems like a basic problem - I need
to take an input list of images, modify them, and output the
result as a new list.
Everything I've seen so far uses a rather hackish chunk of
JavaScript to perform that function when reading images from a
directory, but I can't seem to make it work without the image
downloader.
I then tied "outputCurrentImage" to "inputPreviousImage" through
a "Image Transform" patch.
Unfortunately, It doesn't seem to work, and I don't understand why.
To understand why it doesn't work: The image transform will only
operate on one image per frame (unless inside an iterator, then
it'll operate on as many images as there are iterations). You
don't have any iterators, so we'll ignore that case for now.
I tried doing this with an iterator first - but for some reason,
QuartzComposer wouldn't let me publish any outputs from within the
iterator. I guess I don't really understand that limitation either.
You're expecting the JavaScript patch to pass each image through
the transform, and then rebuild the list, outputting a nice
modified structure. But it works a bit differently:
The javascript patch will execute exactly once per frame, and only
when inputs change -- if you add an outputIndex to your JS patch,
(and set it to _index), you'll see that it's not doing anything --
that's the beginning of the problem. You can add a __number
doStuff input, and attach an LFO, and that'll force it to execute
each frame, but it still won't do what you're wanting -- this is
because the Image transform patch is set to scale the X dimension
by 0 -- that means the image is gone. You'll want to change that
to 1.
I had expected that changing outputCurrentImage would cause a
change on inputPreviousImage - this doesn't seem to be the case,
and is at the root of what I'm trying to understand.
Here's a cooked version that gives output:<Doesn't Work.qtz>
Currently, this will do basically what you're wanting -- however,
it actually takes 1 frame per image, so if you're working on large
groups of images, there will be a noticeable delay between
starting the composition and having all the processed images
available.
Note that this will endlessly rebuild the structure, which
probably isn't what you want (add a check if index is at the end,
and if so, do nothing), and since you're moving images through the
javascript patch, it might start leaking memory like a sieve (or
maybe that bug's been fixed recently ... no idea).
--
[ christopher wright ]
[email protected]
http://kineme.net/
This is all kind of a science project for me now - I've decided for
performance reasons that I need to build my modified image list
outside of the quartz composition - Unless I'm missing something,
it just doesn't seem that Quartz compositions have the kind of
tools I need for this particular problem.
Best Regards,
Ron Aldrich
Software Architects, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/psonice%40gmail.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
