>
>
> I'm thinking it's more arbitrary/conservative -- the GMA950 is comfortable
> with images up to 2048x2048, but it subdivides them anyway (at unusual
> locations, no less). I'm sure it's trying to do the right thing, but it
> appears to be more limited than the capabilities alone.
My card (ati 2600) supports 4k x 4k, so I really doubt it's a hardware
limit. When stretching up to 4k x 4k I see odd divisions too, with the
bottom right tile split in two (and it varies randomly between a horizontal
and vertical split as I change the resolution - odd!).
>
>
> If your kernel samples beyond the current pixel (samplerCoord()), you need
>> to supply an ROI (region of interest) function to tell it the area you will
>> sample from for any subdivision. The CI documentation goes into some detail
>> on this, with examples. In your case, you need to return the region passed
>> in to the ROI function expanded by 'scale' pixels each way.
>>
>
>
> I added this ROI function:
> function myROIFunction(samplerIndex, dstRect, info)
> {
> dstRect[0] -= info*1;
> dstRect[1] -= info*1;
> dstRect[2] += info*2;
> dstRect[3] += info*2;
> return dstRect;
> }
>
> (info is scale in the apply function call)
>
> however, I still get occasional seams when the viewer is sized at various
> sizes.
>
I've also tried clamping the sampler coords to within the image dimensions
without luck. It gets rid of the lines around the edge, but not the ones
inside the image.
Btw, the reason for the 'lines' is that the filter samples the pixels
adjacent to the current one (or further if you increase scale) then uses
those values to change the current pixel. If it's sampling outside the image
area it gets a black pixel, and that makes the current pixel lighter than it
should be. Increasing scale means pixels further from the edge are affected
so the line gets bigger.
Initially I was clamping the samplerCoords, but I figured a (normally
1-pixel wide) line at the edge wasn't so important as performance :)
>
> If I expand it a bit more (by *4 / *8 in place of *1 / *2, for example) it
> seems ok. why does it need to be enlarged so much? (honestly curious)
>
I'm not going to 'scale up' the image, the incoming video will be high res.
The app is for astrophotography, so the equipment + needs are a bit
different from normal. First, there are CCD cameras out there with 4k x 4k
resolution and 16bit colour depth, I'd like to support this if possible :D
Second, resolution is better than frame rate here - more pixels = more
detail, while lower frame rate = longer exposure time, more light collected
(a lot of the stuff up there you might want to photograph is VERY dark - a
big part of what the app does is making a pretty picture from data that's
near enough invisible to the naked eye). So instead of running a webcam at
640x480, 30fps, it's better to go for say 2048 x 1536, 5fps.
For a bit of background, I looked into the options for doing some
photography with a cheap telescope I bought. Using a DSLR is pretty complex
+ expensive (you need long exposure, but at high magnification an object
drifts across the view in maybe 5 seconds so you need expensive motorised
tripods and such to track it..), so many people use a webcam/video camera
and record a video. Then, you run the video through some software that
splits it into frames and moves/rotates the images so they're aligned. You
then run them through something else to 'stack' the images together to
reduce noise + improve brightness. Then you load it into photoshop, and fix
colour levels, sharpness etc.
I don't see anything there that can't be done realtime at the telescope with
a laptop, and honestly, it's probably less hassle to write a new app to do
it with QC than do mess about with all the different (and horribly complex!)
apps needed :)
A recent (ish) screenshot: http://web.me.com/psonice/screencap.jpg
And an old example of how it handles low light:
http://web.me.com/psonice/1.jpg (raw camera output from QC, with lights off,
screens dimmed - this is what I need to work with :)
http://web.me.com/psonice/2.jpg (scaled up - stuff is visible, but in motion
it's almost pure noise) http://web.me.com/psonice/4.jpg (longer exposure +
some processing, the red pixels are actually 'hot pixels' on the camera's
CCD - I have something to remove that now). I've improved it a ton since
then, so the results are a lot better. A decent camera instead of the
built-in imac one would perform wonders too :)
(great note by Alessandro by the way -- completely forgot ROI since the
> texture sizes weren't in excess of hardware limits -- thanks for reminding
> us (or just me, at least :))
Yep. I'm always forgetting about the ROI stuff (from experience, it's
usually better that way ;)
Thanks
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]
