hi,
how can i limit the RGB channels of a film that goes through
[pix_film] -> [pix_buf] -> [pix_gain] -> [pix_offset]. right now i
get colour wrapping from gain + offset but i want to limit the
colours. say i scale down the red channel and i add an offset to the
green channel, i don't want to green channel to wrap from >= 1 to 0,
but to limit all values above 1.0 to 1.0.
thanks, -sciss-
The colors should not wrap around. What CPU are you using?
On 3/9/07, Sciss contact@sciss.de wrote:
hi,
how can i limit the RGB channels of a film that goes through [pix_film] -> [pix_buf] -> [pix_gain] -> [pix_offset]. right now i get colour wrapping from gain + offset but i want to limit the colours. say i scale down the red channel and i add an offset to the green channel, i don't want to green channel to wrap from >= 1 to 0, but to limit all values above 1.0 to 1.0.
thanks, -sciss-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 ...
ciao, -sciss-
Am 11.03.2007 um 18:13 schrieb chris clepper:
The colors should not wrap around. What CPU are you using?
On 3/9/07, Sciss contact@sciss.de wrote: hi,
how can i limit the RGB channels of a film that goes through [pix_film] -> [pix_buf] -> [pix_gain] -> [pix_offset]. right now i get colour wrapping from gain + offset but i want to limit the colours. say i scale down the red channel and i add an offset to the green channel, i don't want to green channel to wrap from >= 1 to 0, but to limit all values above 1.0 to 1.0.
thanks, -sciss-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 3/11/07, Sciss contact@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.
chris clepper wrote:
On 3/11/07, *Sciss* <contact@sciss.de mailto:contact@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
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@sciss.de mailto:contact@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 youcan 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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
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
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>
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>
-
chris clepper -
IOhannes m zmoelnig -
Sciss