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