chris clepper wrote:
On May 7, 2004, at 12:50 PM, IOhannes m zmoelnig wrote:
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.
ah alright. i think i was a bit tired and it had puzzled me (among other things) for hours.
Here's the current state of Pete's plugs for me:
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.
i agree that it is not a good solution. anyhow, it was simple to do, it worked on my PC and (i think) a lot of video-programs use this trick to use effects for images in the "wrong" colourspace (which doesn't make it *any* faster) i have noticed myself that it is so crashy on macs; so i would agree to get it out again. as for slowness: it is slow on both RGBA and YUV-images.
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.
and it still works on x86 ;-)
pix_kaleidoscope - output is different, but hey it's about 3x faster in YUV. Will anyone complain?
fine
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).
at least the luminance-channel is processed correctly ;-) grayscale works too
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 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?
yes, i think so.
pix_refraction - this seems to work pretty well for both RGB and YUV, but the output is different. Does that matter?
not for me
halftone - I don't know where this one is going wrong.
hmm, it works on x86. and jamie has been working on this too almost getting it to work on mac (i think).
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).
i am not that sure about it (the crashes are there, alright; but why). i have numerous crashes when trying to re-create pete's objects which i cannot track down (debugging is not helpful as crashes appear rather randomly) probably there is a stupid bug like the un-initialized GemState hidden elsewere.
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.
i agree.
mfg.a.dr IOhannes