On May 9, 2004, at 3:10 PM, IOhannes m zmoelnig wrote:
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.
I have placed an #ifdef around the YUV to remove it from the OSX version until a better solution is found.
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
I see what you tried to do, but I have started to separate the processing into the usual processYUVImage, RGBA etc. I think that is the only way to get it to work decently on all platforms with each colorspace. The 'uniform' adjustment seems to give sensible output for YUV now, but non-uniform still does crazy things though. I've committed what I have so far...
lumaoffset -
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.
To me it looks like a bounds checking is failing and a pointer is shooting off into space. The instant I turn on 'smooth' for YUV or RGBA it crashes (line 559 and 154 which are the same). I guess we could just remove that feature? ;)
FIxing the lumaoffset crash is getting close to complete as far as I'm concerned.
cgc