A Core-Image-less Image Unit

2007-01-17 01:34:45 UTC

Can you imagine an Image Unit that didn’t actually use Core Image?

I just wrote one.

Well, OK, so I did use CIFilter and CIImage — you can’t get away without those. But I did not use a CIKernel. That’s right: This simple filter does its work without a kernel.

For the uninitiated, a kernel is what QuartzCore compiles to either a pixel shader or a series of vector (AltiVec or SSE) instructions. All Image Units (as far as I know) use one — not only because it’s faster than any other way, but because that’s all you see in the documentation.

But I was curious. Could an Image Unit be written that didn’t use a kernel? I saw nothing to prevent it, and indeed, it does work just fine.

The image unit that I wrote simply scales the image by a multiplier, using AppKit. I call it the AppKit-scaling Image Unit. Feel free to try it out or peek at the source code; my usual BSD license applies.

Obviously, this Image Unit shouldn’t require a Core Image-capable GPU.

4 Responses to “A Core-Image-less Image Unit”

  1. Jonathan Wight Says:

    Yeah this is definitely possible and actually of good value. CIFilters are just classes. I’ve got a CIFilter subclass that is actually a list of CIFilters and inputs (specified via a .plist). This allows you to produce a complex chain of filters and provide a simple interface to them: see http://svn.toxicsoftware.com/public/trunk/Frameworks/ToxicMedia/Framework/Source/CoreImageMacro/

    I’ve also got another CIFilter subclass that takes the kernel program as a parameter. That way you could dynamically generate kernels on the fly (also very useful for debugging/prototyping): http://svn.toxicsoftware.com/public/trunk/Frameworks/ToxicMedia/Framework/Source/CoreImage/CGenericCIFilter.h

    You could also emulate QuartzComposer by creating filters that don’t produce an image – but instead output other values – perhaps a random number generator CIFilter or a sine wave producing filter.

  2. Peter Hosey Says:

    I thought of doing the generic-CIFilter thing while writing the kernelless-CIFilter. Glad to see it’s been done already. :)

  3. Petteri Kamppuri Says:

    This is a nice demonstration. There’s one minor thing. It seems that creating a sequence of Core Image filters doesn’t take a lot of time. Computational power is needed only at the time the image is rendered. Your filter breaks that. It needs to do its operations at the time the output image is requested, not when the image is actually used for rendering. That may or may not be a problem for a particular application. Something to keep in mind, but your filter is a great demonstration of the flexibility of Core Image.

  4. Peter Hosey Says:

    [quote][With a CIKernel, c]omputational power is needed only at the time the image is rendered. Your filter breaks that. It needs to do its operations at the time the output image is requested, not when the image is actually used for rendering.[/quote]

    You are correct. If you want maximum laziness, you have to use a CIKernel; this is not as lazy as a CIKernel-based filter would be.

    I just did it on a whim, mainly. ☺ The only reason why you would do this for real is if either you have a filter that can’t be represented with a CIKernel (for one reason or another), or you want to use some other library (e.g. 2xsai) to do the operation.

Leave a Reply

Do not delete the second sentence.