"Pixel image" 0-30 limit?

Give more details about what you're actually trying to do and the patches involved.

I've done this multiple times different ways, and not had problems; I'd suspect one of the patches is just being set incorrectly.

Are you trying to make a structure of all of the pixel values at full resolution, or are you trying to reduce the pixel w/h first to some lower resolution and output that? Or, are you just trying to output a single pixel value of an area of the raster, or an overall average or something?

I have strip of controllable LEDs abouve my monitor, and im trying to send to them the corresponding colour info of the top line of pixels from the monitor. so suppose there are 11 leds spanning the length of the monitor and a horizontal resolution of 1000, i need the first pixel to show x=0, the second to show x=100, 3rd x=300 etc. Later i will get round to sampling a section of the screen and using that for the colour info but for now i'm happy to take a single pixel.

I have an image resizer, but currently that irrelevant as all the test videos im making are 1280x720. it's just there so that laterr on if i send a different size 16:9 video it will still work.

actually i was slightly off.. and now i see that it is 0-31 in both directions, x & y. top left of the screen is 0,31; top right 31,31, bottom left 0,31 and bottom right 0,0.

qtz file attached.

thanks.

Ok, cool.

So, I don't have v002 movie player installed, but I hooked my iSight up (640x480 resolution).

Checking your composition, bottom left corner is at coordinate (x=0,y=0) and delivering correct output, top right corner is at coordinate (x=639,y=479) as expected, and delivering output.

If this is how you're thinking about pixel coordinate space (it sounds like you are), and you're not getting expected results, I'd maybe try something different than the v002 movie player and see if you start getting expected results, or maybe twiddle with the colorspace - perhaps there's some weird bug with certain colorspaces on your machine? I'm pretty much stabbing in the dark. I'll note that I'm actually testing this in 10.6 at the moment, so there may be some kind of new bug that's screwing stuff up.

BIngo.

yep v002 movie player is causing the problem.. thanks!\

Try routing the output of v002 Movie Player to a Billboard that's inside of a Render In Image (with a Clear at Layer 1), and maybe even do your resize via manipulating the size of the Billboard and width and height pixel values on the Render In Image.

The v002 is likely not adding texture ID's to the output frames, and this is probably making the Image Pixels not work. The Render In Image technique I'm suggesting should likely result in the basic setup working because the image output of the Render In Image will have texture id's (and you'll have the bonus of doing your resize faster, likely), but you'll want to make sure the technique doesn't result in leaking memory on whatever your machine/os version is. I've had it work with no leaking memory, but it still makes me feel uncomfortable.

(Don't test in the QC Editor, try testing in a basic xcode proj with Instruments app... or do the luddite thing of viewing your HD space, walk away for 5~20 minutes, b/c the leak I'm talking about should fill HD space up quickly if you see it happening).

Ok i'll try that thanks very much.

Ok i'll try that thanks very much.

What is the memory leak bug you are referring to George? Is it a RII bug?

usefuldesign.au wrote:
What is the memory leak bug you are referring to George? Is it a RII bug?

Short answer, I don't know exactly what causes it, but I don't think it's a render in image bug.

Longer answer-It may be some kind of problem with when a patch is programmed and doesn't generate/specify the texture, making it wind up without a texture ID. Certain processing patches don't work correctly when that happens, the queue being the first that comes to mind, ImagePixel being another. I think the leak might be a byproduct of "working around" that by using a Render In Image/Billboard to manually render that kind of image to texture.

However, I can't point to a specific patch or OS Version, or say that it happens across the board, or at all in any production patch. I also am not exactly sure exactly "why" it would happen - whether it's a problem with the internal image pipeline, expected or unexpected behavior.

Meno, please please report bugs with the v002 software on the v002 forum. Its important because I don't read this forum or get notified of posts concerning v002.

If its not reported, we can't fix it. That said, we are aware of this issue, but reporting it helps give us a kick in the ass.

gtoledo:

"The v002 is likely not adding texture ID's to the output frames, and this is probably making the Image Pixels not work. The Render In Image technique I'm suggesting should likely result in the basic setup working because the image output of the Render In Image will have texture id's (and you'll have the bonus of doing your resize faster, likely), but you'll want to make sure the technique doesn't result in leaking memory on whatever your machine/os version is. I've had it work with no leaking memory, but it still makes me feel uncomfortable."

George, you are making assumptions again :P

I dont know how you could not add texture IDs and still output a frame, if you look at v002 movie player with the extra metadata you can clearly see its GL backed and has a texture ID.

The issue is because we use an IOSurface as a backing of the QCPluginOutputImageProvider factory method and output a texture that is backed by a surface coming from a background decoder (to get around 32 and 64 bit limitations in Quicktime). That coupled with QC not being able to handle IOSurfaces as a native type, means it wont lock the surface when trying to read the pixel data (IOSurface backed textures introduce this complexity, normal textures backed by VRam just work.

The current workaround is to use a Core Image kernel on the output of the movie player. This should not leak, and I've not seen it leak. That said, it may leak in weird circumstances.

Both Tom and I have been insanely busy, and have yet to fully work around this bug, and fix how we output images (we have an internal fix, but we've not had a chance to fully test it, that fix should also fix a few other bugs).

With the advent of AVFoundation being semi usable on 10.8, it may not get ever fixed, as we are hoping to replace the movie player with a new plugin that is 10.8 only.

Anyway, if you have issues with v002 plugins, please please let us know, remind us, so we can get to it.

Oh, ok. To clarify, I mean when one is reusing the same texture object for each execution of an image, as opposed to each frame having a unique object. Thanks for clarifying what the issue is, and I should have said "might", or just not speculated :)