[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] RE intensity
Hi Don, We can normalize, I think it makes sense. One correction below... -- Benoit mailto:benoit@itedo.com Tuesday, July 13, 2004, 3:20:50 PM, Don wrote: DL> Benoit, DL> I agree. DL> However, I think we should use normalized RGB color values DL> in the algorithm since in the metafile the RGB values can be DL> any range like this: DL> new_color.red = 1.0 - intensity * (1.0 - old_color.red); DL> new_color.green = 1.0 - intensity * (1.0 - old_color.green); DL> new_color.blue = 1.0 - intensity * (1.0 - old_color.blue); DL> Where the values ..red, ..green and .blue are the metafile DL> colour attibute values normalized to 1 by applying the DL> metafile Color Value Extent. For example, if the values in DL> the metafile are RGB(255,255,200) and the Color Value Extent DL> is 0 to 255 then the normalized RGB is (1.0, 1.0, 1.0) You meant "the normalized RGB is (1.0, 1.0, 0.7843)", right? DL> Regards, DL> Don. DL> > Hi all, DL> > I think we should go with this approach. The main reason is that it DL> > is simpler. The HLS approach does work in an absolute scale, but not DL> > very well on a relative scale. I also recall people saying we wanted DL> > to 'fade' the colors. We should just add wording to say that the new DL> > color values are clamped to [0..255]. DL> > -- DL> > Benoit mailto:benoit@itedo.com DL> > Tuesday, July 13, 2004, 1:34:49 PM, Forrest wrote: DL> > FC> All, DL> > FC> My understanding was that we wanted to make some APS fade in color DL> > FC> (go toward white) so other objects would stand out more in the image. DL> > FC> So an intensity of 1 would not change the color and an intensity of 0 DL> > would DL> > FC> make it white. Internally in our applications we convert all colors to DL> > a range DL> > FC> from 0 to 0xffff where (0xffff,0xffff,0xffff) is white. If we are going DL> > the DL> > FC> other way DL> > FC> how do you make red more intense, make it black? DL> > FC> Forrest DL> > FC> Forrest proposed a different system: DL> > >> new_color.red = 0xffff - intensity*(0xffff - old_color.red); DL> > >> new_color.green = 0xffff - intensity*(0xffff - old_color.green); DL> > >> new_color.blue = 0xffff - intensity*(0xffff - old_color.blue); DL> > FC> I need clarification -- is this about subtractive color (ink) or DL> > additive DL> > FC> (luminous)? Because I was at first reading (0xffff,0xffff,0xffff) as DL> > FC> white, in which case minimum intensity (=0) would lead to white and DL> > maximum DL> > FC> intensity (=1) leads to "old_color" -- DL> counter-intuitive. On the other DL> > FC> hand, if 0xffff is black, it makes more sense. 0 intensity is black, DL> > and 1 DL> > FC> intensity is "old_color". I.e. with this system, what you do is DL> > traverse DL> > FC> the difference from old_color to 0xffff (black or white). (If DL> > subtractive) DL> > FC> you can get dimmer than old_color but never brighter. DL> > FC> -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]