Well, upon further examination, my memory was wrong, my result isn't the average pixel value stretched across the grid, it's just black. In fact, there isn't even any evaluation happening past the Image Texturing Properties, if I hook it in between the Video Patch, and the shader input! I could swear I've seen the "average pixel" but it may have been in a more complex qtz(?).
Hovering over the output of Image Texturing Properties reveals a totally dead output (when added to the attached composition), on my system. The output of the Video patch is still viewable, interestingly. When the Video Patch is hooked directly to the GLSL Shader, the Video patch output is still live, but the Image input of the shader reveals "no image", e.g.. it's dead. On Wed, Jan 4, 2012 at 6:08 PM, vade <dokt...@mac.com> wrote: > > Well, sampler2DRect makes sense, as almost all of the native texture > formats in the entire OS X pipeline (at least, as provided by Apple to 3rd > party devs in public APIs) seem to prefer rect texture format. Core Video > without a doubt (in fact, I do not think you can even publicly request > GL_TEXTURE_2D formatted textures from Core Video), and I beleive for Core > Image it is also the preffered internal format. > Sure, I agree with that logic, it makes good sense. > > I suspect that because the image texturing properties patch fails, but > core image does not, like you said there is some internal conversion > mechanism failing. Image Debugging Info indicates that a GL_TEXTURE_2D is > being created, and a quick trip to GL Profiler indicates that there are > properly populated GL_TEXTURE_2D images being created. > I've scoped similar results out (ala "GL_TEXTURE_2D is being created, so why isn't it there?). > However, whatever is being passed either to the uniform variable for the > sampler is incorrect, some GL state is missing, or some coordinate > conversions (normalized vs non normalized) are not happening. I suspect its > a state/uniform thing, because attempting to manually specify coordinates > to the sampler does not reveal any change in the output pixel (always > vec4(0.0) for me). > > CIImages are recepies, so I suspect the internal mechanism to get a > requested texture format from them is more reliable. > > Obviously, all speculation, with a peppering of examination. > I suspect that anywhere that any type of "setMetadata" call is used in the internal api, or where the input image gets a "[inputImage setOnOpenGLContext:context unit:GL_TEXTURE0];" type of liberty, that things will be broken, and possibly other scenarios as well. -gt > > On Jan 4, 2012, at 6:00 PM, George Toledo wrote: > > > > On Wed, Jan 4, 2012 at 5:49 PM, vade <dokt...@mac.com> wrote: > >> GLSL Shader 1 in the attached comp works fine if you use Rect texture >> samplers2Rects and texture2DRects , but no texture2D with the video input. >> >> What is the difference between the 2 GLSL Shaders. I did not notice any >> at first glance. >> >> additionally: Using an image texturing properties patch and forcing the >> image from the video input object to Texture 2D does not correct for using >> sampler2D (ie, having both texture 2D type selected, and using a sampler2D >> in the GLSL shader does not work). However, putting a dummy CI Unit in >> between seems to fix it. Clearly the CVPixelBufferRefs coming from the >> video input patch are not being converted to 2D Texture properly. >> > > Oh really? Core Image to fix it. Wow. I'm not surprised that image texture > call is broken in this context given my findings/whiney complaints a few > months ago w/ setting the metadata not working w/ GFPlugin in Lion. > > I think there may be problems with the Video Patch, but some other > observations make me feel like something (or multiple things) in the > internal image pipeline is broken. Besides the 2D stuff not working > correctly, I've noted image flips not working correctly with RII, and > without RII but just using certain mixes of patches, and some places where > alpha values/compositing isn't correct. > > -gt > > > >> >> On Jan 4, 2012, at 5:42 PM, George Toledo wrote: >> >> Apologies for the quick successive messages, but I neglected to mention: >> >> Non-moving 2D images work fine for me, using this kind of composition, in >> Lion. If I were to use the image patch instead, I'd see the expected >> texture. Using the cropped output of the checkerboard patch works fine as >> well. It's the video patch that looks completely wrong. >> >> Thanks for any thoughts. >> -gt >> >> On Wed, Jan 4, 2012 at 5:36 PM, George Toledo <gtole...@gmail.com> wrote: >> >>> It would probably help if I had attached the file. Here it is. >>> >>> -gt >>> >>> >>> On Wed, Jan 4, 2012 at 5:35 PM, George Toledo <gtole...@gmail.com>wrote: >>> >>>> Does the attached composition work for anyone using OS X 10.7? >>>> >>>> Work, being defined as successfully applying the video texture to the >>>> GLSL Grid, via the glsl shader. This composition uses one video patch, >>>> connected to a GLSL Environment patch's texture input (using the default >>>> GLSL shader program), with a GLSL Grid patch inside of the GLSL >>>> Environment. >>>> >>>> This works fine for me in OS X 10.5 and 10.6, but in 10.7, it looks >>>> like the vertex program is broken, possibly something to do with the >>>> gl_TexCoord. I get what looks like the average pixel value, or when an >>>> image is fed to something with improper UV values, across the GLSL grid, >>>> instead of the video image I would expect to get. >>>> >>>> Possibly related, when I make fragment shaders in OS X 10.7, things >>>> seem to work as expected, until I place them in a Render In Image >>>> Environment, at which time they sometimes flip on the Y axis. This is when >>>> using a 100% stock install, with no plugins or patches. >>>> >>>> -George Toledo >>>> >>> >>> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> >> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com >> >> This email sent to dokt...@mac.com >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> >> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com >> >> This email sent to gtole...@gmail.com >> >> > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
