[GEM-dev] releasing GEM: tag "r0-888-pre"; CVS-checkins

[IOhannes m zmoelnig]

tigital wrote:
> On Sunday, September 14, 2003, at 10:28  PM, chris clepper wrote:
> 
>> i added help for the following
>>
>>> PIX's
>>> pix_background
>>> pix_blur
>>> pix_chroma_key
>>> pix_compare
>>> pix_duotone
>>> pix_mix
>>> pix_motionblur
>>> pix_roll
>>> pix_scanline
> ...cool!

i have been ill the last days and thus have done a lot of documentation.
somebody has noted a while ago: great minds tend to think alike ;-)
i have integrated yours into mine and committed them
but will commit mine for quite all the rest
(still missing and NOT on my TODO-list are:
  pix_convert
  pix_dv
  pix_emboss
  pix_depot
  pix_get
  pix_put
  pix_movieYUV
  pix_test

some of them might be in my local copy only ;-)
)

> 
>> i'm not sure what the following objects even do (or why they exist):
>>
>> pix_pix2sig~.pd or pix_pix2sig.pd?
well, the object should be named [pix_pix2sig~] (which is in fact an 
alias for [pix_pix2sig]). it is the inverse of [pix_sig2pix~] (which is 
documented neately now) and btw is a very cool object (in my opinion)


>> pix_test - nothing?
really nothing, it is just somthing to test. have i committed it to the 
cvs ?
>> pix_emboss - looks like my old yuv_ object to try and make a fast 
it is. i consider it not functional and have not documented it.

 >> pix_rds
>> pix_dot - does this work?
> 

i have also made changes to the srces:

one of my major issues is to get rid of values between 0 and 255.
this range exists for purely technical reasons.
In Gem all these ranges (eg: colors) have been handled as floats (0..1) 
for a long time.
This (the history of Gem) is the only reason why i think we should try 
to make all limited ranges go from 0.0 to 1.0. and i think it is nice to 
have only one range to remember....
and now the big: SO::

[pix_duotone], [pix_posterize], [pix_backlight], [pix_mix] now all work 
with values between 0..1.
this will surely break some patches :-(
most of the controls for these objects had to be commited via a message 
to the first inlet. i have made additional inlets for the controls.
this would have made it easy to give different names to (the old) uchar- 
and to (new) normalized values, but unfortunately i have thought of this 
  very lately. i think one of the objects features this, but the others 
will break things.


[pix_chroma_key]: changed the default to  m_processOnOff=1. it is very 
disturbing if some of the pix_fx have to be turned on, while others work 
as soon as they are connected. we cannot change the default behaviour 
for all pix_fx to not do anything before they are explicitly turned on 
(because it would break all(!) patches with pix'es) and i don't think 
that it is good to have some turned on and some turned off.

[pix_compare]: m_processOnOff=1 (see above). additionally i have changed 
  the behaviour to compare luminances rather than the rgb-channels 
separately. this should make it more compatible to the YUVprocessing.


some YUV/Gray support for [pix_]-objects
Geos:
[rubber]/[ripple]: both have now arguments that allows to specify the 
number of segments of the grid.
i haven't yet changed it, but i would prefer the ctrX and ctrY value be 
rather normalized.
What should the sizeMess do exactly ? Right now it does nothing. Should 
we remove it or just put a glScale inside the object (but this could be 
done outside too)
i have made at least the "height" message do something intelligent.

i have no idea what the inletFov is for at [ripple]


[newWave]: added some sense to the heightMess