[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