[GEM-dev] Next week?

zmoelnig at iem.at zmoelnig at iem.at
Thu May 6 13:18:15 CEST 2004


Zitiere James Tittle II <tigital at mac.com>:

> hey gang,
> 
> > [pix_halftone] : works (although it is a bit brighter than rgba/grey
> 
> > due to the usage of "real" luminance)
> 
> ...heheh, I almost fainted! 
oh sorry.

> 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.


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


mfg.as.dr
IOhannes




More information about the GEM-dev mailing list