[GEM-dev] Next week?

[chris clepper]

On May 7, 2004, at 12:50 PM, IOhannes m zmoelnig wrote:
> just for clarification: the rgb-like colourspace (RGBA on other 
> systems) is GL_BGRA even though it is actually ARGB ? is this true ??

It's ARGB but submitted as BGRA only reversed using the _REV_ GL flags. 
  Confusing, but I guess concessions to the PC world were needed.

Here's the current state of Pete's plugs for me:

pix_backlight - the output is different between the colorspaces as 
previously noted.

pix_colorreduce - just crashes on any YUV data I try.  It's not a very 
good solution to do the conversions just to get it to work.  Even if it 
did work, I would vote to just not have it process YUV since it would 
be so slow.

pix_halftone - doesn't really produce very meaningful output in YUV.  
It makes the dot patterns but it's not nearly as legible as the RGB.  I 
fixed the shifts for OSX so now it's not just green, but maybe that 
screws up the x86 code so I put a little ifdef around it.

pix_kaleidoscope - output is different, but hey it's about 3x faster in 
YUV.  Will anyone complain?

pix_levels - doesn't seem to do any sane YUV processing at all.  The 
code obviously just applies RGB transforms without regard to the chroma 
offset.  This needs a rewrite for YUV (it might work for gray as well).

pix_lumaoffset - now crashes religiously when using smooth and YUV (the 
version I committed did not), and the RGB code crashes no matter what 
when the offset and gap get too high.  Some sort of bounds checking is 
either not in place or failing.

pix_metaimage - sometimes using YUV and not 'cheap' there is a green 
edge to the boxes.  this is probably an off by one where there is not a 
proper pixel pair.  I don't know where to fix this.  Also, when size = 
0 CPU load skyrockets and things start to turn into a slideshow.  
Should that value be trapped and just bypass the effect altogether?

pix_refraction - this seems to work pretty well for both RGB and YUV, 
but the output is different.  Does that matter?

To sum up, the following seem fine:

backlight, kaleidoscope, refraction, and possibly metaimage

The rest need work:

colorreduce - this needs a full reworking in YUV, and I have a hard 
time understanding how the hell the histogram is made.  I would think 
you need it to hold either 256 slots per channel or one for every 
possible pixel sampled because they might all be unique.  This code 
seems to do neither?  It does sample every 4 pixels which would reduce 
the array needed for the second method.  The sort might be hellish on a 
720x480 though.

halftone - I don't know where this one is going wrong.

levels - this one seems easiest to write for YUV.  Heck, just a quick 
multiply for each component would do and skip the rest of it.

lumaoffset - I could have sworn there was some sort of sanity check for 
pixel coordinates, but now I just don't know.  The crash is always at 
the smoothing conditional and one of the attendant pointer operations.  
I checked out the version I committed a few days ago and now it crashes 
and it did not before (or else I wouldn't have committed it).

The real question to me is how much effort do these really warrant?  
Sure some of them look quite nice, but none of the objects are 
particularly essential, and the original Pete code performs terribly.  
Also, I can't recall anyone ever posting about these objects apart from 
the Linux compile problems caused by kaleidoscope.  It's starting to 
irritate that these are holding up the show.

cgc