Re: [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

0.5 before the colourization, then afterwards a pix_gain 2.0 with
saturation ...

don't want to degrade the bit-resolution... --), i could do pix_gain

here.



mfga.-sdr
IOhannes

right, gem handles colors as 8bit integer values, so you are out of luck 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.

<colourwrapping.png>

pix_film_tests5.pd
Description: Binary data

_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list