[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] Issue CL-d3: 2.2.2 Drawing model
At 05:20 AM 3/29/2006 -0500, Benoit Bezaire wrote:
>Tuesday, March 28, 2006, 6:13:57 PM, you wrote:
>
> > [...]
> >>
> >>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.
>It would seem like it. Although Chris may also be asking if the alpha
>compositing is done in a linear or gamma corrected color space?
Yes, that is exactly what I was wondering about.
> >>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.
>It's this sentence "[...] intermediate values have meaning identical
>to the alpha transparency defined in Escape 45." that bothers me.
I think it meant to apply the similar linear equation.
>When the other color models were added (RGBA and sRGBA), the behavior
>with Escape 45 should have been defined. (Assuming that RGBA and sRGBA
>were added after Escape 45.
Agreed. So let's add a clarification to WebCGM 2.0. Any problem with that?
> >>- 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.)
>Yikes!
Does that mean you don't like it? To be clear, I don't feel strongly about
how we answer it, as long as we do so. I just thought "both/multiply" was
easiest and cleanest to write into the spec.
To be honest, I see no strong use case for both/multiply. But I also see
no harm, if the effect is well defined. Let "user beware", if they want to
combine 'em.
As I said, it is easier to define than rules of precedence, if both are
present.
Am I missing something, that perhaps you're seeing as an implementor? (Ah
yes, I'm seeing your final comments below.)
We see to agree on the rest...
> >> 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.
>I didn't ignore these other questions... only postponed them until I
>had a clear picture of the transparency model of CGM.
>I agree with what you say here.
>
> > 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.
>I agree.
>
> > 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 was going to propose that alpha compositing be done in the same
>color space as specified in the metafile. You seem to agree with me.
>
> > 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?
>My concern about multiplying the alphas is implementation.
>Who currently supports:
>- Escape 45?
>- RGBA?
>- sRGBA?
>
>Now if there's an implementation out there that supports say (Escape
>45 and RGBA), what is it doing when the two are used together?
I would be surprise to find such an implementation. So that might argue
for a rule of precedence (e.g., "A" takes precedence over Esc45, because
it's more specific?), or a rule that only one may be used (either the "A"
or "Esc45" but not both).
-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]