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


Hi Lofton,

Here is how I see the problem(s)... We have the following
possibilities in WebCGM 2.0.

- enable/disable background.
- fill color expressed as RGBA (A may be < 255).
- stroke color expressed as RGBA (A may be < 255).
- PNGs with transparency.
- a raster-intensity DOM property.
- an intensity DOM property.
- Escape 45.

What I don't like is that I'm being asked to write wording for
features that are not supported by implementations. Are you aware of
an implementation that would render the following correctly:
APS with an escape 45 other than 100% opaque; in combination with a
partially transparent filled color; also in combination with a
partially transparent stroke color; all of that composited into a
'disabled background'?  Hence my 'yikes'!

I also have some concerns about the Escape 45 functionality... it may
require offscreen rendering after all. Take for example the following
case (much simpler than what is above):

- black background rgb(0,0,0).
- object with a red fill rgb(255,0,0) and a blue stroke rgb(0,0,255)
and an alpha value (Esc 45) of 50%.

I'm not a rendering expert, but I think an offscreen is required to
get the desired result. You can't apply the 50% on the fill operation,
blend it to the background and then apply the 50% on the stroke
operation and blend it to the background. That's wrong.

Another problem is that Esc 45 doesn't define the resulting opacity
after compositing. The equation:

result = alpha*foreground + (1-alpha)*background

assumes the background to be opaque, but the introduction of RGBA and
sRGBA says otherwise; is it not possible to define a semi-transparent
background?

In the past, we've been strict about what's in and what is out of
WebCGM 2? Why don't we take the same approach here?

Vendors,
Who supports enable/disable background?
Who supports transparent PNGs?
Who supports Esc 45?
Who supports RGBA, sRGBA?

As for Itedo, I would need Dieter to verify this (who's on vacation at
the moment), but I think we don't support any of those features.

-- 
 Benoit   mailto:benoit@itedo.com

This e-mail and any attachments are confidential and may be protected
by legal privilege. If you are not the intended recipient, be aware
that any disclosure, copying, distribution or use of this e-mail or
any attachment is prohibited. If you have received this e-mail in
error, please notify us immediately by returning it to the sender and
delete this copy from your system. Thank you for your cooperation. 


Wednesday, March 29, 2006, 11:08:00 AM, you wrote:


> 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]