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[2]: Fwd: re: [cgmo-webcgm] New draft snapshot


Hi Lofton,

LH> Forrest proposed a different system:

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

LH> I need clarification -- is this about subtractive color (ink) or additive
LH> (luminous)?  Because I was at first reading (0xffff,0xffff,0xffff) as
LH> white, in which case minimum intensity (=0) would lead to white and maximum
LH> intensity (=1) leads to "old_color" -- counter-intuitive.  On the other
LH> hand, if 0xffff is black, it makes more sense.  0 intensity is black, and 1
LH> intensity is "old_color".  I.e. with this system, what you do is traverse
LH> the difference from old_color to 0xffff (black or white).  (If subtractive)
LH> you can get dimmer than old_color but never brighter.

I could use some clarification as well.  Forrest, what is 0xffff?
What is it not 0xff (or 255)?  I presume that your implementation is
16 bit instead of 8 bit, correct?  Is 0xffff black or white?

Thanks,

-- 
 Benoit   mailto:benoit@itedo.com



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