[GEM-dev] Next week?

[chris clepper]

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