Re[2]: [cgmo-webcgm] RE intensity

[Benoit Bezaire <benoit@itedo.com>]

Hi Dieter,

Yes, we could use 8 bit instead 16 bit, that's not a problem.  What's
your take on the intensity range, [0,1] or something else?  See
previous emails.  This brings up the clamping issue.  And Don wants us
to consider normalizing the color values using the Colour Value Extent
range.

Tuesday, July 13, 2004, 8:25:21 PM, Dieter wrote:

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

DW> Instead of 16 bit it uses 8 bit per channel, and the clamping is
DW> [0...255]. This is the usual way of storing rgb in unsigned
DW> 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);
>>
>>
>>



-- 
 Benoit   mailto:benoit@itedo.com