hey gang,
On May 5, 2004, at 11:22 AM, IOhannes m zmoelnig wrote:
chris clepper wrote:
Seeing that it's already Cinco de Mayo here I don't see it also being GEM release day as well. One good thing about the title of this mail is that it always points towards a future date. ;) I had underestimated the amount of time and effort to get Pete's Plugins into working order for YUV, and it looks like there is still a bit to
..aye eye an "i" or two...
ok. i have done a bit of work too, and now the status for these objects is:
[pix_halftone] : works (although it is a bit brighter than rgba/grey due to the usage of "real" luminance)
...heheh, I almost fainted! I've been working feverishly on this for the last week or so, and finally got a hold on it last night; so my stomach dropped when ya said you got it too work: coulda been doing something else all that time...luckily, after looking at yr solution I realized the only change was the SHIFT_U & SHIFT_V stuff: guess we should've expected endianess like in rgba/argb...
...anyway, I've got it working almost totally correctly (at least we aren't doing the pixel doubling), but there's one sticking point, and it's due to the calculation of the pGreyScaleTable[]...in essence, it creates a 512 place table with 0's from 0-256 and 255's from 383-511...in between, we have 1,3,5,7...up to 255...so I did a little experiment and found the following:
# of pixels nDiff>383 nDiff<257 natural yuv 1369 48703 transformed yuv 1369 48703 transformed RGBA 16 63662
...this tells us two things: 1. "natural" yuv gives us the same values as transformed, so we can remove the transform 2. we get a lot higher bias using yuv luma than a calculated rgb luma
...so, on the one hand we can try to find a "magic number" to subtract from yuv luma to try to get a similar distribution (which I'm fiddling with), or we can recalculate the greyScaleTable (or DotFuncResult) so that it better fits the yuv luma spread...
...any suggestions?
[pix_levels] : seem to work [pix_colorreduce] : works (ok, my hack to make it work is really quick and dirty; it is awfully slow; but as jamie mentioned, it is soooo complicated; if someone finds the time *later* it could be done in a proper way)
...tried this, but it crashed immediately...will look at later...
[pix_refraction] and [pix_backlight] seem to work, although the output is not exactly the same as it would be in rgba
...pix_refraction works fine, haven't tried chris' changes yet...
[pix_kaleidoscope]: the only problem remaining (although working halfway, or rather doublewide)
...this is next on my list...
additionally there appeared an issue with the YUV-texturing under linux (just for your information): Mesa seems to have incorporated the GL_APPLE_ycbyr_422 into the newer releases (i haven't yet been able to really test it, but at least the defines are there in the gl.h); unfortunately nvidia's driver do not yet support this. so i have made a runtime check for GL_APPLE_ycbyr_422 to enable/disable YUV2RGBA-conversion.
do. Also, I have tentatively scheduled a testing session on a friend's dual G5 for this weekend, which should allow for ironing out any potential problems on that version of GEM.
fine
...let's hope we can get it done by then!
l8r, jamie