CIFilter infinite Extent problems

I am going to post this here in hopes that others who have had this issue can find it easily. I spent many many hours today fiddling with custom image units (ie CIFilters) and this one stumped me for quite some time.

OK, here is the thing. If you follow apple’s (generally very good) tutorial on creating custom filters, you g through this rough timeline:

1) total confusion.. what the hell is this kernal thing?
2) general understanding .. ahh haa!
3) coding .. this is so EASY! it is great!
4) validating .. WTF?
5) fiddling and finding all the syntax errors by hand in your kernal
6) validating: PASS! yay!
7) loading into QC for testing.. this is soo exciting!!!
8) Cannot Render: Bounds: Infinite (must crop to render).. WTF?!?!
9) spiral into deep deep dark place because after many hours of scouring the docs you still cannot figure out how in the name of Zues’s BUTTHOLE do you get a nice filter like ALL THE REST that render without cropping!!

so, here is the solution:

After many hours of looking for clues (and spending an inordinate amount of time trying to figure out how the ROI had to do with the output extent (hint, it doesnt) i stumbled across the fact that you can pass extra info to the kernel via three special kernel keys:
kCIApplyOptionExtent, kCIApplyOptionDefinition, and kCIApplyOptionUserInfo.

the one that we care about for today is kCIApplyOptionExtent. and you use it like so:

in your – (CIImage *)outputImage method:

NSArray * outputExtent = [NSArray arrayWithObjects:
    [NSNumber numberWithInt:0],
    [NSNumber numberWithInt:0],
    [NSNumber numberWithFloat:[inputImage extent].size.width],
    [NSNumber numberWithFloat:[inputImage extent].size.height],nil];

return [self apply:_BBSubtractionCompositeFilterKernel, src, bg, 
   kCIApplyOptionExtent, outputExtent, nil];

and that is it. that will set the output extent to be the same as the inputImage extent. You can, of course set it to whatever you want, but i imagine the general case is that you want to get out something just as big as you sent in.

I hope this helps someone!

This entry was posted in code, CoreImage. Bookmark the permalink.

6 Responses to CIFilter infinite Extent problems

  1. sandor says:

    LOL Ben! I have to admit that i understand only a few % of the techie stuff, but your humor is international and understandable for NOOBs ;-) But the problem with the infinite dimension has run also across my way as i was playing wit QC ;-) Ben: is there an adress where we could send you a few bottles of beer ,-) ;-) ;-)

    Keep it up!

    Sandor

  2. Ben says:

    hehe, thanks sandor!

    BTW, if you find that you are using a QC filter that has an infine extent (and you cant change the code) then you can use a CICrop to get it back down to a renderable size.

    Groovy!
    -b

  3. sandor says:

    Hey Ben,

    i was trying to understand the differences in CFImage and the other stuff. Well basicaly i was thinking: why Ben does not uses the Core Filters? It should work? ;-) So i played around with Xcode and stuff – Jezz i LOVE apple ;-) What came out is my VERY FIRST EVER software product. I’m sooooooo prod about – mostly becose it’s COMPLETLY USELESS ;-))) But it demonstartes for me that Filters and Core Image Filters are usable at runtime – LOL. Check it out (and don’t forget to drop the provided image mask in the appropiate slot)….

    BTW: a serious question now. Do you think it would be possible (and usable) to extract the projected image (the output image from the projector) from the image that the camera is getting? Well maybe this sounds senseless, but if this is possible, it would ease up the hardware building process a LOT (no more IR soldering etc.)… Take a look at my thread “TFRI” in IR/lasers etc…

    Her’s the link to my app: hope you like it ;-)

    http://workflow.cd-cologne.de/download/CrazyCam.zip

    Have a nice Weekend!

  4. Ben says:

    Hey Sandor,

    Fun app! hehe.

    to answer you first question, even though I have not been very successful at getting the CIImage/CIFilter data stream going, i do think that is the way to go in the future. I just need to find that super-secret ingredient that allows me to get access to the raw image bytes in a decent amount of time (i am sure that I must be doing something wrong)..

    To answer your second question: I have actually thought about this very same idea previously. The problem is that when you are projecting, say a white background and trying to differentiate light colored blobs. So you would need some way to punch-up the blobs reflectiveness to be ‘more’ white than the projected white. It would be very prone to false positives i think.

    That is why the IR is so brilliant. It give the computer a nice easy background and nice differentiated blobs, but still allows the projector to use the same surface to project stuff in the visible spectrum..

    groovy!

    -b

  5. This was just what I was looking for a week ago. I threw it into a tutorial I wrote of what I learned and gave props.

    https://www.georgestarcher.com/?p=254

  6. Ben says:

    Hey George,

    thanks for that, your tutorial looks great! I think that you and I went through much the same process :-)

    Cheers!
    -B

Leave a Reply