RE: [cgmo-webcgm] RE intensity

["Dieter Weidenbrueck" <dieter@itedo.com>]

Why don't you use this:
new_color.red    = 0xff - intensity*(0xff - old_color.red);
new_color.green = 0xff - intensity*(0xff - old_color.green);
new_color.blue   = 0xff - intensity*(0xff - old_color.blue);

Instead of 16 bit it uses 8 bit per channel, and the clamping is
[0...255]. This is the usual way of storing rgb in unsigned
integers.


>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Wednesday, July 14, 2004 2:16 AM
>To: Benoit Bezaire
>Cc: cgmo-webcgm@lists.oasis-open.org
>Subject: Re: [cgmo-webcgm] RE intensity
>
>
>At 03:02 PM 7/13/2004 -0400, Benoit Bezaire wrote:
>>Hi all,
>>
>>I think we should go with this approach.  The main reason is that it
>>is simpler.  The HLS approach does work in an absolute scale, but not
>>very well on a relative scale.  I also recall people saying we wanted
>>to 'fade' the colors.  We should just add wording to say that the new
>>color values are clamped to [0..255].
>
>If we go with Forrest's equations (below), the clamping caveat is not a
>necessary part of the definition.  With the intensity parameter in the
>range [0,1], each component will be in the range [old_color,0xffff].  The
>only way that a component could go out of range (i.e., out of [0,0xffff])
>is if the parameter is out of range.
>
>That said, whether or not to say anything about clamping depends on what's
>the error philosophy -- the equations can only yield out-of-range results
>for illegal parameter values.
>
>>[...]
>>Tuesday, July 13, 2004, 1:34:49 PM, Forrest wrote:
>>
>>FC> All,
>>
>>FC> My understanding was that we wanted to make some APS fade in color
>>FC> (go toward white) so other objects would stand out more in the image.
>>FC> So an intensity of 1 would not change the color and an intensity of 0
>>would
>>FC> make it white.
>
>I can live with it.
>
>It is an odd transformation, at least relative to its name ("relative
>intensity").  If adapted to a color component range of [0,255], then for
>any component x (R, or G, or B), the equations produce x' as follows:
>
>for i=1:  x' = x'  (all colors are unchanged)
>for i=0:  x`=255  (all colors become white)
>for i=0.5:  x' = 127 + 0.5*x
>         -- black becomes gray, white is fixed
>         -- red becomes 255,127,127
>         -- etc.
>
>Am I the only one that thinks "intensity" is a bad term for it?
>It is very
>counter-intuitive to me, that *minimum* intensity (=0) is white.
>(White =
>(255,255,255), and I think of this as maximum "intensity", in all
>components; minimum "intensity" in all components I would think of
>as black.)
>
>>Internally  in our applications we convert all colors to a range
>>FC> from 0 to 0xffff where (0xffff,0xffff,0xffff) is white. If we are
>>going the
>>FC> other way
>>FC> how do you make red more intense, make it black?
>
>I guess when I think of "intensity", I imagine something like the "V" in
>HSV (or alternately "B" in HSB, for "brightness").  [See Foley & Van Dam,
>2nd edition, plate II.7].  It doesn't really matter -- if a transformation
>like this does what people want, we should go with it, and be as clear as
>possible about what it does -- the equations (-- and think of a good name
>for it).
>
>-Lofton.
>
>>Tuesday, July 13, 2004, 1:34:49 PM, Forrest wrote:
>> >>         new_color.red    = 0xffff - intensity*(0xffff -
>old_color.red);
>> >>         new_color.green = 0xffff - intensity*(0xffff -
>old_color.green);
>> >>         new_color.blue   = 0xffff - intensity*(0xffff -
>old_color.blue);
>
>
>