|
|
CIColorCube This has an inputCubeData, that is actually a NSData input; an unsupported type for CI filters. That input is a virtual data input on the patch itself, as can be seen by looking at it on the Editor in QC and hovering over the input with the mouse cursor. What's going on with this? It says that it takes a 3 dimensional color table, but since the input is virtual, I'm at a bit of a loss as to figure out a way to use it "in QC". I wonder what app uses it, and what it looks like in action. It definitely does look like it's meant to have that input published, so that the patch can recieve data in the context of an app (this seems obvious, though I guess I may be wrong). My thought was that this is a "bounding box" thing for head tracking or maybe even part of a facial recognition system, given that it's doing a color analysis and then making a box, but that could be a bit of a leap that I'm making on that one. (I would bet $1 though.) |
Do you mean the Color Cube patch, GT, as I cannot find one listed as CIColorCube, and I do have list Private Patches enabled?
Update - yeah you must be talking about this one see http://www.patentstorm.us/patents/5627950/description.html for further information courtesy of Apple
Yeah... sorry for being unclear. I'm definitely thinking about the Color Cube.
I always see this when I'm looking at the Graph Foundation Log:
WARNING- Core Image filter "CIColorCube" input "inputCubeData" is of an unsupported class "NSData"
I was basically wondering if anyone had any practical experience in using or feeding info to it yet, and if so, if they were willing to share.
http://developer.apple.com/mac/library/documentation/GraphicsImaging/Ref...
Cybero...
I'm well familiar with all of the links (I'm a top notch Googler)... they just don't say too much about how to actually use it.
I'm guessing here, but is sounds a bit like it needs some kind of 3D texture as a LUT (lookup-table). QC can't deal with 3D texture files ordinarily, so I guess that's why it's a virtual input.
I'd love to see some more light thrown on this though. There has been talk (mostly from me) of some kind of plugin to allow the use of 3D textures in the GLSL Shader patch, which would be very cool indeed.
a|x http://machinesdontcare.wordpress.com
http://www.lightillusion.com/freeluts.htm
Picked up these and most of them just cause QC to spit its dummy out :-)
As you've no doubt found out, GT, a|x & others interested, there are plenty of links online for LUT [Look Up Tables] and not that much in the way of QC specific and QC friendly examples.
Will keep plugging away though.
What will be most telling is figuring out where/if it's used, and then it's easier to see how.
I'm guessing it's Leopard or Tiger only, no SL action for this item, possibly superceded directly by other patches
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Fou...
Yep, definitely needs a table... it's the fact that it's a virtual input that kinda hamstrings playing with it easily.
The idea of the 3D textures in the GLSL is a really cool one.
With GLSL 3D texture support, I could do this kinda thing, but with actual volume textures (CAT scans would be particularly cool)
http://machinesdontcare.wordpress.com/2009/07/06/more-raycaster-screensh...
a|x
This is a link to a page about the "getBytes" method being a deprecated method... I think you may be inferring the wrong conclusions, not sure.
NSData isn't deprecated, if that's what you are inferring... it's part of Objective-C.
The Color Cube path itself has always been a Private patch, as far as I know.
Logical deduction would seem to point to the fact that this patch must have been originally (or still) used in a qtz, as a resource, where the app is setup to send it that data. I've never seen it though. I wonder if it could have been used in a qtz for ease of setup, and then turned into an executable file. I'm curious if Apple does that. It would make sense to do for something that they wanted to make a little less obvious.
From a (very brief) look at the docs, it looks like it's just doing colour transformation with a LUT. I.e. you can change any specific colour to any other specific colour - like replace a specific shade of blue with a yellow. And change EVERY possible colour in the same way.
The reason for it using a 3d LUT is just that it has to look up a combination of r, g and b - that's 3 dimensions.
Say if you have a pixel with colour r = 28, g = 55, b = 200. All it does is open the LUT texture, and select column 28, row 55, plane 200. There it finds a new colour for the pixel.
It's not the most exiting patch in the world, but for doing really detailed colour adjustment it would rule. Look in apps that do complex colour matching and stuff, you'll probably see it in action there.
I don't know how you'd format the data for it, but it needs a 3d array of 8bit int values. I don't think it actually uses a 3d texture - more likely it runs in software.
It could use a shader though, internally. OpenGL itself has no problems with 3D textures (apart from memory issues, of course), so there's no reason why that particular patch couldn't run on the GPU using an actually 3D texture, in whatever format.
a|x
Interesting! I've been paying attention to your exploits in this area. I could digress a long time on this!
BTW, this brings to mind - Superglsl w/iterator...broken in SL :/ Without iterator, it workee. Just ran into this yesterday. Man, that 140508 04.0.1 was an awesome looking piece.
I'am thinking psonice is right :
As I understand the patch manage synchronisation of colors thru a complete system ex :
Dimension 1 : the color of the pixel you are drawing
Dimension 2 : the color of the pixel displayed on your screen (monitor)
Dimension 3 : the color of the pixel printed ( by a printer for exemple)
As dimension 2 and 3 can have differents characteristic (gamma, color depth... etc) this patche probably return the "real" or "transformed" color to be display for each device of the print chain according to the characteristics of this device (cube data)
It could, if it was a GLSL patch of some sort. But the CI in the name is a clue that it isn't ;) Core image doesn't support 3d textures so far as I know.
Good point. So I guess it wants some kind of multi-dimensional structure/NSArray as input then.
Having said that, the distinction is somewhat artificial. Afterall, a texture is essentially just an array of pixel values, anyway...
a|x
Can't CI filters be used by any app, without going through QC? It looks to me like it's made for software processing, which doesn't fit in with QC so well.
yes, coreimage can be used independently of QC (they're completely separate technologies that can be used independently -- though QC will always load CI, it might not always make use of it).
Yeah, good call! I forgot that it doesn't have to be considered for QC at all, to show up in the patch list and load on the Editor. Duh (at me).
Is it possible that the CISmallGaussianBlur doesn't load onto the editor because it doesn't have any kind of input or output that QC can deal with (or is it just a random dud that should have been erased(?)... I know random dud has been the verdict, but I noticed it's still there in SL).
I was under the impression that CoreImage filters were supposed to compile to something that could be run on the GPU, which is why the language is limited in some ways compared to straight GLSL. The things that were taken out, like some loop functions, noise() support, some kinds of branching logic, arrays, etc. were removed from the CIFilter language because they weren't supported by the majority of graphics hardware at the time.
a|x
Damn, hadn't checked that one :(
a|x
I would love to be able to easily concoct a test with the old iterator and the new Shadows to see if it would crap-out like it does now in SL now, especially after seeing that break with the GLSL (though it could very well be the way that things are evaluating in the iterator that makes it not work anymore... haven't looked enough).