[GEM-dev] Next week?

[James Tittle II]

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