On May 6, 2004, at 7:18 AM, zmoelnig@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<257natural 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