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
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







pix_film_tests5.pd
Description: Binary data


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

Re: [PD] GEM / pix objects : limiting colours

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


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

Re: [PD] GEM / pix objects : limiting colours

[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



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

Re: [PD] GEM / pix objects : limiting colours

[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

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

Re: [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* <[EMAIL PROTECTED] >  
>> 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
> onwait...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


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

Re: [PD] GEM / pix objects : limiting colours

[IOhannes m zmoelnig]

chris clepper wrote:
> On 3/11/07, *Sciss* <[EMAIL PROTECTED] > 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
onwait...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

Re: [PD] GEM / pix objects : limiting colours

[chris clepper]

The colors should not wrap around.  What CPU are you using?

On 3/9/07, Sciss <[EMAIL PROTECTED]> 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

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

Re: [PD] GEM / pix objects : limiting colours

[chris clepper]

On 3/11/07, Sciss <[EMAIL PROTECTED]> 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.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] GEM / pix objects : limiting colours

[Sciss]

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 <[EMAIL PROTECTED]> 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
>


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

[PD] GEM / pix objects : limiting colours

[Sciss]

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