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]: [cgmo-webcgm] Issue CL-d3: 2.2.2 Drawing model


Benoit (& all) --

Thanks for the research.  My comments and answers are embedded.

At 04:06 PM 3/27/2006 -0500, Benoit Bezaire wrote:
>Some good and bad news...
>
>First the good news; Escape 45 is well defined since it defines the
>compositing equation: result = alpha*foreground + (1-alpha)*background.

Okay, so does that answer Chris's question, "is alpha linear?" -- it would 
seem to answer it.


>The bad news is that I don't know how a 4 channel RGB color model (say
>RGBA or sRGBA) works in combination with Escape 45. I can't find the
>answer in the pointers given to me. RGBA says the following:
>"Conceptually, values of the alpha transparency are real numbers
>between 0.0 (fully transparent) and 1.0 (fully opaque), inclusive, and
>intermediate values have meaning identical to the alpha transparency
>defined in Escape 45." I dunno, it still seems vague.
>
>My question is as follows:
>Can I use the RGBA color model and also use Escape 45 in the same
>WebCGM file?

Let me ask in return, "why not?".  Do you see any downside to allowing 
it?  As long as we spell out the result precisely, then I see no problem 
with letting authors do it, if they want.

>- If Yes...
>   - How are they combined?
>     i)   multiply the two alpha values.

I would vote for this.  (I think "yes" and "multiply" is by far the easiest 
to specify -- fewer rules and conditions.)

>     ii)  A of RGBA is used.
>     iii) Escape 45 is used.
>- If No...
>   - Who wins?
>     i)  RGBA
>     ii) Escape 45
>
>Thougths?

As far as alpha goes, see above for my opinion.

There seems to be several other aspects to Chris's comment, other than "is 
alpha linear":

2.) "What is the influence of grnode on compositing - grouping complexifies 
compositing, neds to be carefully described."  My answer:  the drawing 
model of CGM:1999, in the absence of APS, only implies compositing each 
successive primitive directly to the view surface, then the next primitive, 
then the next...  In the case of alpha, then each primitive is composited 
to the partially-drawn view surface according to the linear equation.

In the presence of APS, with inheritance mode equals 'statelist' (the only 
value allowed in WebCGM), is identical to the case of no APS.  This is a 
rule of CGM:1999 -- the drawn picture is identical if the viewer ignores 
APS (note that we're violating that rule with 'visibility' ApsAttr, and 
that's the only such case of which I'm aware, in WebCGM).  We need to 
remember than a WebCGM APS-structured stream of CGM primitives is still 
basically a stream of CGM primitives.  An APS is not like a group in SVG, 
on which one must consider "group opacity" -- composite the whole group 
onto an off-screen bitmap and then blast it to the screen.

Another way to say it -- Esc45 and the "A" of RGBA are primitive 
attributes, not group attributes.

3.) "Color space for compositing not described" -- does the linear equation 
of Esc45 imply that the color space for compositing is the same as the 
color space of the metafile?  (In WebCGM it's basically RGB -- can be RGB, 
RGBA, sRGB, sRGBA).  I'm unsure of the answer.  I do note that we purposely 
eliminated fine color control from WebCGM, i.e., the COLOUR CALIBRATION 
element.  I suppose we ought to say how alpha (whether Esc45, or "A", or 
the product of the two) is done/rendered  -- I would think that we just 
multiply each component -- R, G, and B -- by the "effective alpha", 
right?  (effective alpha = Esc45, or "A", or the product of the two if both 
are present).

I think that would probably suffice for WebCGM.  (Although I'm unsure 
whether or not, by saying that, we might complicate the future 
specification of a WebCGM-cascaded "colorful profile").

Thoughts about #2 and #3?

Regards,
-Lofton.



>Friday, March 24, 2006, 11:26:00 AM, you wrote:
>
> > At 05:08 PM 3/23/2006 -0500, Benoit Bezaire wrote:
> >>Link:
> >>http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/17 
> 342/CL-comments.html#CL-d3
> >>
> >>Doh! The short version didn't work eh ;)
> >>
> >>I can take this one if nobody wants it.
>
> > Thanks!
>
> > (Btw, I have the impression that Forrest and Don have more interest in
> > colour and compositing, with their petro application backgrounds.  I'd like
> > to see their feedback on these questions.)
>
> >>Lofton, you state that WebCGM is pretty unspecified here... what about
> >>ISO CGM, what _does it_ specify? I wouldn't mind a couple of pointers
> >>in the ISO CGM spec as a starting point:
> >>
> >>Section 2.5.3 Color and transparency of Webcgm 2.0 states:
> >>- "The normal behavior of CGM:1999 viewers is to render later occurring
> >>primitives completely opaquely on top of earlier primitives." Where is
> >>this said in CGM:1999?
>
> > Amazingly, I can't find the explicit statement.  ***ANYONE*** ... can you
> > provide a reference to a precise statement in CGM:1999?
>
> > ("6.11 State model" certainly implies it, but actually is about an abstract
> > state machine, as opposed to a viewer with rendering).
>
> > However, I assert that these are true, and *everyone* has implemented them:
> > 1.) drawing occurs in element order (painters model);
> > 2.) drawing is unaffected by APS grouping, i.e., one does not composite
> > into an off-screen bitmap and then draw (like SVG).
>
> > (See 6.13.4, 'statelist' being the only inheritance value that is allowed
> > in WebCGM.)
>
> > I think this is also true:  WebCGM 1.0 & 2.0 people do not care about
> > precise colour rendering -- it is not a requirement of the WebCGM
> > constituency.    COLOUR CALIBRATION is the CGM element that gives precise
> > control, and it was excluded from both profiles.
>
> > Here are a couple of useful ISO CGM references:
> > ISO 6.7.6 (Colour attributes)
> > ISO 6.5.7 (Transparent Cell Colour)
>
>
> >>- the alpha-transparency Escape element... where is that element
> >>specified? Can we get the wording?
>
> > Two general references, plus the esc045 specific reference:
>
> > http://www.cgmopen.org/technical/registry/
> > http://jitc.fhu.disa.mil/nitf/graph_reg/class_pages/escape.html
>
> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/esc045.html
>
>
> >>- same question for sRGB/sRGBA, RGB/RGBA.
>
> > Two general references:
> > http://www.cgmopen.org/technical/registry/
> > http://jitc.fhu.disa.mil/nitf/graph_reg/class_pages/colour.html
>
> > and the three specific ones:
> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/col006.html
> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/col007.html
> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/col008.html
>
>
> >>Would it be fair to say that Esc 45 maps to the 'opacity' attribute in
> >>SVG?
>
> > Same general idea.  (Maybe inverted?  I.e., transparency vs. opacity?  I
> > haven't looked at SVG to see which one it defines.)
>
> > -Lofton.




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