[GEM-dev] Next week?

[James Tittle II]

On May 6, 2004, at 7:18 AM, zmoelnig at iem.at wrote:
>
>> realized the only change was the SHIFT_U & SHIFT_V stuff:  guess we
>> should've expected endianess like in rgba/argb...
> basically i did expect it (because suddenly something turned green 
> after i cvs
> upgraded where the log says "at least it isn't green any more;-)"), 
> but i
> haven't had any possibility to test it.
> so i just left it there and shifted the problem into the 
> GemPixPete-defines.
> btw: i do think we should use SHIFT_Y0/Y1 instead of Y1/Y2 (but i 
> committed to
> soon...)
>
>>
>> ...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
>>
>> ...any suggestions?
>
> i have had a look at the colour2grey-conversion and there were 2 
> problems:
> a) RGBA: Grey=77*Red+50*Green+29*Blue is wrong; it should read: 
> ...150*Green...
> this boosts the RGBA-luminance significantly
> b) Greyscale: averaging was done in 4byte-blocks, but only the first 3 
> values
> were taken into account (like ignoring the alpha-value of an 
> rgba-tuple)
>
> having fixed this, the halftone-images almost(!) are the same for all 
> color-spaces.

...just checked out yr new version:  very interesting!  Of course, it 
just produced a green image at first, but that's just because you used 
the SHIFT macros, an on ppc they were shifting to 24 and 16 in a short! 
  I'm still working on U32 pointers with two pixels, and get a fairly 
different output from you:  hard to say who's closer...mine seems to be 
biased to the high end (fr'instance, the reflection on the pot at the 
left is very visible), whereas your version is more smoothed out...I'm 
trying to figure out why we get such different results...

> but unfortunately i have found more problems with YUV-endianess in 
> some objects
> (e.g. [pix_metaimage] swaps chroma and luma on my system)
> i'll investigate

...yeh, we definitely will need to go back and roll those macros in...

we'll get it eventually!

jamie