[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, You said: Don wrote in his proposal, "Then the desired Relative Intensity replaces the luminance component in calculated HLS". That does not seem ambiguous -- it corresponds to the 2nd interpretation. But I still think it is ambiguous, see Don's (private) reply to me. He went for the 1st interpretation. -- Benoit mailto:benoit@itedo.com Tuesday, July 13, 2004, 9:30:17 AM, Don wrote: DL> Benoit, DL> > Hi all, DL> > Thank you for the information Don. What we now have to decide is what DL> > is 'relative intensity' relative to? To say "Then the desired DL> > Relative Intensity replaces the luminance component in calculated HLS" DL> > might not be specific enough. DL> > Here's an example, let's take purple color RGB(171,73,201) with an HLS DL> > equivalent of HLS(285,54,54). DL> > If I set the relative intensity to 50%, what is the new HLS value: DL> > HLS(285,27,54) or HLS(285,50,54)? In other words, is it relative to DL> > the initial value or relative to the DL> black(L=0%)-white(L=100%) range? DL> > Given the name 'relative intensity', I suspect we mean the former, is DL> > that correct? DL> Yes, it would relative to the "initial" value. The original RGB value of a DL> metafile color attribute should be used each time a relative intensity DL> is applied. DL> > If the answer is that it is relative to the initial value, are we DL> > allowed to make the color 'whiter' by setting an intensity higher than DL> > 100%, for example setting 150% on that purple would make the HLS DL> > values(285,81,54). If this is allowed, I presume we should clamp the DL> > L value at 255, correct? DL> Yes, the L value should be clamped. DL> > Please let me know what's your take on this. DL> > -- DL> > Best regards, DL> > Benoit mailto:benoit@itedo.com DL> Regards, DL> Don. DL> > DL> > This is a forwarded message DL> > From: Don Larson <dlarson@cgmlarson.com> DL> > To: Benoit Bezaire <benoit@itedo.com> DL> > Date: Monday, July 12, 2004, 11:33:31 AM DL> > Subject: [cgmo-webcgm] New draft snapshot DL> > ===8<==============Original message text=============== DL> > Benoit, DL> > Attached is the description for "relative Intensity" that was assigned to DL> > me. DL> > Note that I did not include the actual algorithm, just a reference to it. DL> > I can provide the algorithm text if necessary. DL> > Regards, DL> > Don. DL> > Larson CGM Software. DL> > 713-977-4177x102 DL> > > Hi all, DL> > > Here's a snapshot of the latest draft. I would appreciate it if DL> > > we could talk about it during Wednesday's conference call. DL> > > What's new in this draft: DL> > > - new wording in section 1.1.3 Coordinate values. DL> > > - added a new 'src' attribute on the GetWebCGMDocument, we need to DL> > > standardize this! DL> > > - modified the applyCompanionFile method, I removed the 'refresh' DL> > > parameter and added a reloadPicture method on the Picture interface. DL> > > - improved the wording of getAppStructureById and DL> > > getAppStructuresByName (clearer now). DL> > > - new wording for highlight() method. DL> > > - fixed many typpos :-) in the 'style attribute' table. Note, DL> > > character-height and stroke-weight are in relative scale only. I DL> > > don't think the use case is there to justify anything else. DL> > > - added wording in the Event interface regarding the event DL> > > processing order. DL> > > - removed relatedTarget and added preventDefault() on the Event DL> > > interface. DL> > > - added appendix placeholders. DL> > > - getElementsByAttrNameValueNS is removed from this draft (can be DL> > > inserted back in if desired). DL> > > - getAppStructuresByType was removed (why retrieve by type when 95%+ DL> > > of content are grobject)? DL> > > - the Text interface is not whitespace aware since WebCGM 1.0 is not DL> > > either. DL> > > New questions (sorry!): DL> > > - is it valid to have the 'src' property on the GetWebCGMDocument DL> > > interface? DL> > > - I'm still having a hard time with the 'attributes' attribute on DL> > > the Node interface. Currently, a script writer would have a real DL> > > hard time using this! DL> > > - do we need a removeEventListener method()? DL> > > - highlighting a layer, what happens? DL> > > - issue, does the interactivity attribute conflict with event DL> > > listeners. DL> > > - do we need a removeLinkuris and removeNames? DL> > > - In my opinion, the spec doesn't provide clear enough explanation DL> > > regarding coordinate values... what should clientX/Y say? DL> > > - What happens if a user clicks on the background of a CGM Picture DL> > > instead of on an APS? Anything? DL> > > DL> > > What's still missing (I know I'm forgetting some): DL> > > - architectural illustration. DL> > > - rules for applying companion file (we don't have any wording for DL> > > that). DL> > > - examples & pictures to explain coordinate values of DOM. DL> > > - formula for intensity. DL> > > - editorial work. DL> > > - integrating DTD with spec (not really sure how the entire spec DL> > > should be organized). DL> > > -- DL> > > Benoit mailto:benoit@itedo.com DL> > > -- NextPart -- DL> > > Attached File: DL> \\barley\apps\goldmine\MailBox\Attach\treeExample2(3).png DL> > > -- NextPart -- DL> > > Attached File: DL> \\barley\apps\goldmine\MailBox\Attach\Draft WebCGM DOM DL> > > 2004-07-07.html DL> > > -- NextPart -- DL> > > Attached File: DL> \\barley\apps\goldmine\MailBox\Attach\treeExample1(3).png DL> > ===8<===========End of original message text=========== DL> > -- NextPart -- DL> > Attached File: DL> \\barley\apps\goldmine\MailBox\Attach\Relative Intensity.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]