Tuesday, February 16, 2010
Tuesday, January 19, 2010
Sunday, January 17, 2010
Sunday, January 10, 2010
CIAxialBlur : Adding Depth and Realism - Quartz Composer Tutorial

One great trick for adding depth is to have certain areas of a picture blurred while another area appears to be in focus. By being able to control what areas of an image are blurred, one can infer visual impressions that differ from the source imagery greatly.
In the example above I've selectively chosen to heavily blur the flowers above the main flower in the center of the image and have placed more weight to the left side than the right.
The great thing about an effect like this is that it simulates how we actually see, though I've amped up the effect a little bit more than I typically would in a real world scenario, to make it more obvious for the sake of demonstration.
In many ways, selectively blurring specific areas emulates the effect of our peripheral vision; the part of an image that is outside the focus of our gaze.
I'm including fully implemented image unit versions of CI Axial Blur, as well as CI Axial Motion blur in my Box account widget on the sidebar.
An interesting application of CI Axial Motion Blur is to blur a specific area in a picture, to make it look like it's going faster than it appears unfiltered. So, if you had a picture, you could take an object in the area that is the center of attention and blur it to make it appear as if it is moving by imitating the natural inability of the eye to catch every bit of detail in a fast moving object, unless the eye is actively following it. By doing the inverse, we would imitate the effect of the eye following the object of interest. Tthe background would be motion blurred to infer movement of either the background, or the eye.
Saturday, January 9, 2010
Credos
So much can change in a year, and so much can stay the same.
When New Year's comes, it seems like it's always natural to reflect on the past year, and wish for the future.
I can't remember exactly what I did for New Year's '09. Around Thanksgiving time, my father slipped and fell. He wound up in the hospital, and passed away there in April. For the Holiday season, I was drowning myself in going to the hospital, working on music, programming, and just making it day to day. I felt an intense sense of hope and positivity during all of that period.
As my father's health declined, it was surreal, real, shocking, and unsurprising, all at the same time.
Right after that, I was flying across the country to work on art programming for artists that I'd grown up listening to. When I say, right after that, I mean, a week or two weeks. Hard to remember exactly. It made a sort of line in the sand. It shook things up, and let me pour myself into my work.
My father lived a storied life. He was a professional race car driver, he was a professional artist, he worked in music management, he was a gourmet chef... and I'm just touching on a few things. He had a rich life, was intelligent, and on top of that, had the wisdom that comes with experience.
I remember that there were two points that he kept trying to make to me on his death bed.
In no particular ranking:
1: Don't waste a minute.
2: All you need is love, it's true.
The second, being an obvious Beatles paraphrase. No problem in that.
I would go to the hospital every day and spend hours. I would bring my iTunes, put the headphones on him, and let him listen to all of his favorite albums. Sometimes he was lucid, sometimes he was comatose.
That time was trying, because it challenged many of my internal philosophies about life. My credo eventually morphed into something very much like the AA credo.
My outlook is that in a given day, there are things you can control, and things you can't control. So for the things that you can control, you MAKE them what you want. That's it. You don't let the things you can't control break you off stride, but you take the things you can do, and do them to the hilt... and you don't waste a minute doing it.
When you love, love big.
Labels:
holidays,
life,
new year's,
philosophy
Friday, January 8, 2010
Flying Orca
orca from George Toledo on Vimeo.
Labels:
interactive media,
kineme3D,
motion graphics,
quartz composer,
video art
Thursday, January 7, 2010
Morphology



Some of my favorite Core Image Filters are the Morphology filters; morphology, morphology gradient, and morphology laplacian.
I've uploaded some image unit versions of them, that crop to the reference image and also include insert splitters, to keep them from getting "reigned in" where higher values than the defaults might be desirable. These can be used as is, or installed in your Graphics/Quartz Composer Patches folder.
Object Explode...
This is a picture of the K3D explode force working on a single object; a textured plane.
Instead of pushing apart object members, it breaks the single mesh apart:
Object Explode from George Toledo on Vimeo.
Tuesday, January 5, 2010
Kineme 3D Structure Render and Explode Force
One of the coolest updates to the world of Quartz Composer, and especially Kineme3D users is going to be the new update to K3D, free to current license holders. To people that program with QC that don't have it... what, are you nuts?
One of the limitations of rendering multi-obj 3D objects with K3D in the past was the fact that if you wanted to render every piece of an object structure, one had to employ an iterator and iterator the structure, or break away every piece of the structure and use a separate render. For objects with structure of hundreds or even a couple thousand elements it could get a little absurd.
Enter the structure render. Connect the "objects" output into a structure range, set the length to your object count, plug the output into your Kineme3D Structure Render patch, and everything automatically renders in one piece. Really sweet for the large library of free multi-obj style, fbx, obj, and 3ds files out there. This is a tremendous time saver.
Now there is also a new "explode force" that works on single meshes or on multi-obj files. On multi object files one will see each element blast apart from one another. On single mesh files one gets a cool kind of cracking. Below is an example of the explode force, coupled with the structure render.
Labels:
explode force,
interactive media,
kineme3D,
quartz composer,
skanky,
structure
Repackaging Core Image Filters To Gain More Juice - Quartz Composer Tutorial
One of the quirks of working with Quartz Composer is that a significant amount of function comes from Apple made Core Image Filters.
While Core Image Filters are called on by Quartz Composer, and load into the app, they aren't actually "part" of the Quartz Composer app bundle. Furthermore, when you adjust your app's hidden preferences, by holding down the option key when you choose preferences, and then checking off the option to see private patches (or by using Kinemecore, and selecting "Show Private Patches"), one gains access to quite a few more CI filters, as well as other useful patches. However, that does not mean that they were designed with QC in mind; far from it. Quartz Composer checks for all available CI Filters at that point, and loads them into the Patch Creator (or Patch Library, if you're using 10.6). That's kind of a recipe for a clusterf... uhm, hodge podge.
While Core Image Filters are called on by Quartz Composer, and load into the app, they aren't actually "part" of the Quartz Composer app bundle. Furthermore, when you adjust your app's hidden preferences, by holding down the option key when you choose preferences, and then checking off the option to see private patches (or by using Kinemecore, and selecting "Show Private Patches"), one gains access to quite a few more CI filters, as well as other useful patches. However, that does not mean that they were designed with QC in mind; far from it. Quartz Composer checks for all available CI Filters at that point, and loads them into the Patch Creator (or Patch Library, if you're using 10.6). That's kind of a recipe for a clusterf... uhm, hodge podge.
These filters, especially the private/hidden filters, can be quirky in the way that they handle their maximum and minimum values. In fact, it can seem quite arbitrary and due to the nature of the code, it may have well been impossible for them to set one consistent "throw" to every filter (eg., every port having consistent available maximum and minimum values).
When choosing the Gamma filter, one can typically enter any high value right into the Power input port. Witness the picture below. (Double Click on it to see a larger view.)

The Gamma patch actually changes it's visual output even at a value as high as 30, and far past. It is still doing something to the visual output. The Gamma patch has processing "oomph" at high Power values, but it's been seemingly arbitrarily lopped off at 3.
If you're "looking" at that value in your Inspector, the second you touch the slider (or if one was to publish the value), this happens:

Maximum value reigns itself in to "3" automatically! Does adjusting the gamma value past 3 still change the visual output? Again, yes. This kind of behavior is typical of many CI filters; many times hidden ones, but public ones like Gamma as well.
Interestingly, this rarely happens to me in the context of editing compositions in this way, since I write directly in the input ports, and don't use inspectors for input. I happened to discover this behavior when publishing to root, and looking at the parameters at that level. Many patches reign themselves in to established values.
All the same, there is an extremely easy workaround; the insert splitter!
Simply create and input splitter from the patch that has irritatingly reigned itself in without asking.

As you can see, since the input is no longer a "slider type", one can put ANY minimum or maximum value in.
By default, when one creates an insert splitter off of a number port, one gets and insert splitter with "nan" as maximum and minimum values. This effectively allows you to do whatever you choose; you aren't reigned in to any limits.

So, on first inspection, with considering the value resetting quirk, one may be inclined to chain duplicate CI filters together to get "more" of the same effect. However, as long as one makes an insert splitter off of that number input, one doesn't have to worry about their values resetting. Many CI filters have throws much further than what Apple has set as the maximum or minimum. A few seconds of time checking out the filter in question will usually show if it has a throw far beyond the accepted maximum, or minimum.
If one desired, one can package the filter in a way that will allow you to always have maximum range available and then reign it in as you see fit. The first step is taking the Gamma with the insert coming off of the Power value, and publishing every input to root. Go ahead and rename the "input" off of the input splitter "Power", to reflect what one typically sees when looking at a Gamma Patch.

Next, one can install it as a new patch into Quartz Composer by installing it in one of your "Library/Graphics/Quartz Composer Patches" folders. Through placing the qtz in a "Quartz Composer Patches" folder, QC will see it, and load it, since by definition, the root of a .qtz file is a QCPatch. One will see it populate Quartz Composer on restart as a Virtual Patch. Don't install it in System/Library/Graphics/Quartz Composer Patches, unless you want it to be available to the whole system (slight chance this could cause problems, and isn't recommended).

Now you have a modded Gamma patch that appears as a single patch without the extra insert splitter; instead of quirkily shifting your maximum value around, the patch has an input that will "stick" to what you give it. If you want to give something a Gamma value of 5, instead of say, the maximum allowable of 3, you don't have chain multiple filters, which often brings down performance.
It seems like I may have written it a million times already in the past few paragraphs, but this definitely applies to other filters. Even without going so far as inserting something like this as a virtual patch, it's handy to note that simply making an insert splitter, at the very least, will lock in your desired value and not let it get reset from grabbing sliders on your Inspectors, or from publishing your values to root, unless you purposely set your own desired maximums and minimum in the Settings panel of one of the insert splitters.
When choosing the Gamma filter, one can typically enter any high value right into the Power input port. Witness the picture below. (Double Click on it to see a larger view.)

The Gamma patch actually changes it's visual output even at a value as high as 30, and far past. It is still doing something to the visual output. The Gamma patch has processing "oomph" at high Power values, but it's been seemingly arbitrarily lopped off at 3.
If you're "looking" at that value in your Inspector, the second you touch the slider (or if one was to publish the value), this happens:

Maximum value reigns itself in to "3" automatically! Does adjusting the gamma value past 3 still change the visual output? Again, yes. This kind of behavior is typical of many CI filters; many times hidden ones, but public ones like Gamma as well.
Interestingly, this rarely happens to me in the context of editing compositions in this way, since I write directly in the input ports, and don't use inspectors for input. I happened to discover this behavior when publishing to root, and looking at the parameters at that level. Many patches reign themselves in to established values.
All the same, there is an extremely easy workaround; the insert splitter!
Simply create and input splitter from the patch that has irritatingly reigned itself in without asking.

As you can see, since the input is no longer a "slider type", one can put ANY minimum or maximum value in.
By default, when one creates an insert splitter off of a number port, one gets and insert splitter with "nan" as maximum and minimum values. This effectively allows you to do whatever you choose; you aren't reigned in to any limits.

So, on first inspection, with considering the value resetting quirk, one may be inclined to chain duplicate CI filters together to get "more" of the same effect. However, as long as one makes an insert splitter off of that number input, one doesn't have to worry about their values resetting. Many CI filters have throws much further than what Apple has set as the maximum or minimum. A few seconds of time checking out the filter in question will usually show if it has a throw far beyond the accepted maximum, or minimum.
If one desired, one can package the filter in a way that will allow you to always have maximum range available and then reign it in as you see fit. The first step is taking the Gamma with the insert coming off of the Power value, and publishing every input to root. Go ahead and rename the "input" off of the input splitter "Power", to reflect what one typically sees when looking at a Gamma Patch.

Next, one can install it as a new patch into Quartz Composer by installing it in one of your "Library/Graphics/Quartz Composer Patches" folders. Through placing the qtz in a "Quartz Composer Patches" folder, QC will see it, and load it, since by definition, the root of a .qtz file is a QCPatch. One will see it populate Quartz Composer on restart as a Virtual Patch. Don't install it in System/Library/Graphics/Quartz Composer Patches, unless you want it to be available to the whole system (slight chance this could cause problems, and isn't recommended).

Now you have a modded Gamma patch that appears as a single patch without the extra insert splitter; instead of quirkily shifting your maximum value around, the patch has an input that will "stick" to what you give it. If you want to give something a Gamma value of 5, instead of say, the maximum allowable of 3, you don't have chain multiple filters, which often brings down performance.
It seems like I may have written it a million times already in the past few paragraphs, but this definitely applies to other filters. Even without going so far as inserting something like this as a virtual patch, it's handy to note that simply making an insert splitter, at the very least, will lock in your desired value and not let it get reset from grabbing sliders on your Inspectors, or from publishing your values to root, unless you purposely set your own desired maximums and minimum in the Settings panel of one of the insert splitters.
I'm uploading the .qtz for the sake of example. Go ahead and install it as described above to gain access to it in your Patch List/Creator. Better yet, use this principle to save yourself time with your own favorite CI filters, if you find them exhibiting this kind of behavior, instead of driving yourself up a wall wondering what the heck is going on.
Labels:
Core Image,
developer tools,
interactive media,
quartz composer,
sample,
tutorial
Monday, January 4, 2010
Attack of the Jaggies- QC's Crappy Aliasing, and Mitigating it, Part 1 of a Million - Quartz Composer and Core Image Tutorial

You know what KILLS me?
The fact that multisampling in the QC app is a line of code, and that they couldn't figure it out for 10.5. Meanwhile, 10.6, is such a *&^*^&^%$, as is, that as much as I love the hidden multisampling option, it's not really worth using just to enjoy ONE working new function. The way that multisampling has to be implemented makes it unlikely to be able to add into the QC3/10.5 environment. (Though it IS successfully implemented and easily available in the Quartz Builder runtime, so any apps compiled with the latest version can gain the benefit of smoooooothness).
When dealing with Sprites (and some other render patches) that have image input, one of the easiest ways to smooth the edges, is to run the input image through a SoftRec style core image filter, and then to set the render blend mode to "over". On the picture above, one can see the rough edges on the angled rectangle on the left, whereas with the rectangle on the right, the edges are nice and SMOOTH. It's not multi-sampling, but it can produce a similar end result.
The caveat is that one has to have an image input for this to work. So, in the case of having a simple render, where one wants to have a solid color, what may occur to someone to do is to use the constant color patch and a crop patch to generate a solid color to feed the edge smoothing CI.
Don't do that. Constant Color sucks. If you give it a color value of 0,0,0,0 (alpha black), it shuts off and stops delivering output.
Instead, use a clear inside of a render in image. Some may argue this point, but I don't find that the render in image patch depreciates performance (I'm gauging framerate) in this scenario. As always, results may vary from system to system. If you know that alpha black will never get chosen by a user, then constant color might make sense, but the clear/render in image combo is totally functional, and not broken in any way, so I feel better about using it.
So, in essence, this filter is taking the edge, and then "smoothing/blurring" the pixels and creating alpha black in the edge, which is eliminated by flipping blend mode to over. Sweet.
The code for the core image filter is:
kernel vec4 softRect(sampler image, float radius)
{
vec4 sf;
vec2 v = samplerCoord(image);
vec2 s = samplerSize(image);
vec4 pixel = sample(image, v);
sf = vec4(v, s - v); // left bottom right top
sf *= 1.0 / radius; // recip will be hoisted out of the code by CI, since radius is a constant parameter to this kernel
sf = smoothstep(0.0, 1.0, clamp(sf, 0.0, 1.0)); // make all 4 functions rounded
pixel.a = sf.x * sf.y * sf.z * sf.w; // product of the 4 functions will produce a nice alpha
return pixel;
}
An example qtz is posted in the Box widget.
Labels:
anti-aliasing,
Core Image,
edge smoothing,
quartz composer,
tutorial
Sunday, January 3, 2010
Queue Control 2 - Image Queue Structures - Quartz Composer Tutorial



The Queue patch that is provided by Apple in the Quartz Composer app, included in the Developer Tools, is nifty for a variety of reasons. The queue is basically a value store, that allows you to store a given amount of incoming values. It comes in handy for building structures to feed to rendering objects or for grabbing incoming images. Line drawing, time blurs and acid trails, my compadres!
The limitation of the Queue patch, as is, is that it only grabs one incoming feed. In the same way that I talked about a 3D value Queue in my last post, it's not too hard to make a Queue grabs images instead of values, and that has multiple input ports. This is useful, because one can take an image and feed it through different effects, and then sort through the result via iteration, or even build up separate image feeds (multiple movies, video feeds), and then sort via iteration, without having a bunch of redundant queue patches hanging around.
The code is just this easy:
_Queue = []
function (__structure Queue) main (__image Value[3], __index Size)
{
var result = new Object();
_Queue.push([Value[0], Value[1], Value[2]]);
if (_Queue.length > Size) _Queue.splice(0,_Queue.length-Size); result.Queue = _Queue;
return result;
}
If you want to add in more sources, change "(_image Value[3]" to a higher value, like "(_image Value[5]" and then add in a port for the increased value on the line "_Queue.push([Value[0], Value[1], Value[2]]);"... so it would read something like " _Queue.push([Value[0], Value[1], Value[2], Value[3], Value[4]]);" and so on.
So, literally, the only thing one has to do to change a javascript value queue, to an image queue, is to change the main function line from "value" to "image".
What will result is a two tiered structure; for each initial structure member, there will be three separate images in this case, one for each image input. So, two structure index patches will give access to the actual image. One can also use the old "interpolate in an iterator" trick to splay out the image sources across multiple sprites automagically instead of manually sorting to different rows. I'm uploading an example that displays both methods to the Box widget on the sidebar.
Labels:
apple,
Core Image,
iterator,
javascript,
macintosh,
quartz composer,
queue,
tutorial
Subscribe to:
Posts (Atom)

