Ah, typical. I just modified my original .tiff export slightly so it just dumps the original file. Checking the file, I was a bit surprised to see a 512x512 image taking 4mb - yep, it's saved as 32bit float format! I guess that's my needs done already then without the messing about!
Chris 2009/9/15 Chris Wood <[email protected]> > Sounds like a driver/CI bug -- I'd report it as concisely as possible, and >> then shake your fist at the sky in desperation when it doesn't get resolved >> ;) workarounds like what you describe are really annoying simply because >> when you do get it fixed, they'll fix it too, and then it'll break your fix. >> But of course, if you don't fix it, neither will they... so either way, be >> prepared to have a 1.1 ready to go on some 10.6.x update ;) (I've >> experienced this at least 3 times with 10.5) >> > > Probably a good idea. I came across that on leopard btw - it'll probably > already be fixed in 10.6 leaving me with the headache of supporting both ;) > > >> From the GPU engineers I've spoken with (from both ATI and Nvidia), POT is >> an ancient relic that doesn't actually help performance significantly >> anymore. It can help with some fancy calls, like automatic mipmap >> generation, but other than that I don't think it'll help as much as you're >> hoping. I'm not sure on requiring POT for >8bpc modes -- I've never heard >> that, but I'm oft mistaken on intricate GL details. hardware-wise, >> POT+>8bpc only requires a different multiplier, so it's not like it actually >> requires any additional transistors or fanciness -- as long as the >> multiplier can handle a number 4x larger (2 extra bits), there's nothing >> physically required that isn't already there. > > > Guess I need to figure out the situation with >8bit textures. I can't > remember now what made me think NPOT wasn't properly supported, but > something did because I'm converting my camera input to POT sizes before > processing. Perhaps I did that while trying to figure out the >1024 pixels > sampling thing though, and it's not necessary. If it does need POT textures > though, tiling will definitely improve performance because I won't need to > run my expensive filters on the whole image (no need to process the black > bars). > > >> I've not tried the ofType: variant, but I _think_ that lets you request >> CGImages. I'd give it a spin. >> >> Oh: On leopard, requesting CGImages would give you BGRA images that >> claimed to be RGBA -- I don't think that was ever fixed on leopard, but >> maybe it's finally fixed since PPC is dead? you might want to check on that >> before jumping in headlong. > > > Ah, more nastiness ahead it seems. Luckily I have a PPC machine, and an > intel one that's currently dual-booting 10.5/6. Thanks for the heads up. > > Yeah, readpixels is only good for contexts -- I was thinking you were >> having the QCRenderer render to the context, not act as an image filter. I >> always forget that kind of usage ;) > > > I'm using it for both: it takes a video input, does lots of processing, > then outputs it back to the app via a published port. But it's also doing a > bit more processing for on-screen preview, adding overlays etc. End result > is that the renderer is running at maybe 640x480 in part of a window, but > it's doing perhaps 1024x1024 processing internally and saves at that res. It > makes for a good image processing setup - better than doing the processing > then passing the image to a separate renderer I think. > > Chris > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
