[PD] GEM / pix objects : limiting colours

[Sciss]

i found a workaround. if i insert a [pix_rgba] object before  
[pix_offset], it will work (doesn't work without your fix, so thanks  
a lot for it!). strangely the alpha channel is the first, followed by  
red, green, blue, so it's really ARGB not RGBA ...

's fine for me know!

ciao, -sciss-

Am 18.03.2007 um 22:00 schrieb Sciss:

> p.s. [saturate 1( and [saturate 0( _do_ work with [pix_gain],  
> however not with [pix_offset], so maybe you could just copy the  
> behaviour from pix_gain directly to pix_offset?
>
> Am 18.03.2007 um 21:54 schrieb Sciss:
>
>> i managed to build GEM from the CVS, but the problem is same as  
>> before (see attached image : the dark blue portion in the top-left  
>> should be 100% white) ... i checked on PPC, there it looks good  
>> (also looks good with the previous GEM version)
>>
>> ciao, -sciss-
>>
>> Am 12.03.2007 um 11:15 schrieb IOhannes m zmoelnig:
>>
>>> Sciss wrote:
>>>> 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 ...
>>>
>>>
>>> right, gem handles colors as 8bit integer values, so you are out  
>>> of luck
>>> here.
>>>
>>> however, i just added the changes for saturated maths in  
>>> [pix_offset] to
>>> the CVS, so check it out recompile and report whether it works as  
>>> expected.
>>>
>>> mfga.-sdr
>>> IOhannes
>>
>> <colourwrapping.png>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_film_tests5.pd
Type: application/octet-stream
Size: 2932 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070318/e60ad96c/attachment.obj>
-------------- next part --------------