[PD] GEM / pix objects : limiting colours

[Sciss]

ok, but let me know if there's any kind of work around ... i guess  
internally everything is int8 not float32? because if float32 (-- i  
don't want to degrade the bit-resolution... --), i could do pix_gain  
0.5 before the colourization, then afterwards a pix_gain 2.0 with  
saturation ...

ciao, -sciss-

Am 12.03.2007 um 09:00 schrieb IOhannes m zmoelnig:

> chris clepper wrote:
>> On 3/11/07, *Sciss* <contact at sciss.de <mailto:contact at sciss.de>>  
>> wrote:
>>
>>     mac intel. however the pix_offset help file says "When adding an
>>     offset to each color-channel, no clipping is done. Thus you  
>> can wrap
>>     around the color-space", so probably it behaves right, only in my
>>     case i want to prevent wrapping ...
>>
>>
>> The PPC code does not wrap around since Altivec has saturating
>> addition.  Maybe MMX lacks that.  I'll check when I have the time.
>
>
> yes i think the mmx/sse2 code does overwrap.
> however, i also think that there is a switch to turn that
> on....wait...no ehm there is only a switch in the [pix_gain] object to
> turn this on/off: it is [saturate 1/0(
>
> though saturation is the logical usage, i would like to provide both
> ways, for legacy reasons and for freedom of choice.
>
> mfa.sdr
> IOhannes
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list