OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]