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>