RE: [cgmo-webcgm] transparency -- conceptual recommendations

[Lofton Henderson <lofton@rockynet.com>]

Hi Benoit,

At 01:08 PM 2/21/2008 -0500, Bezaire, Benoit wrote:
>[...]
>About RGBA and cell colors... I don't really get it... From my point of
>view, RGBA compositing is much more powerful than transparent cell
>colors. I don't see why a user would mix the two. It's your call.

TCC is a legacy item, predating the RGBa of WebCGM 1.0, and there are tests 
for it in the test suite.

(Note, in case it wasn't clear earlier, that one can only specify cells to 
be **fully transparent** via the TCC mechanism -- the cells are either 
displayed with their specified color, or are fully transparent if their 
specified color matches the TCC "flag color".)

To be clear, I'm not recommending that the two -- TCC and RGBa color model 
-- should be mixed, nor am I suggesting that TCC is in any way 
superior.  But since it is legacy functionality, and valid (incl. in RGBa 
metafiles) in WebCGM 1.0, and valid in WebCGM 2.0, then I thought it would 
be useful to address the meaning.

The meaning is pretty simple, whether the color model is RGB or RGBa -- the 
conceptual viewer behavior is to initialize (Pr,Pg,Pb,Pa) in the 2.2.2 
equations to transparent black, for those cells.

I don't mind if we "Note" or otherwise point out that the TCC functionality 
is available also through the RGBa color model, and if the latter is the 
color model of the metafile then it is redundant and "somewhat silly" to 
mix the mechanisms.

Is that what you had in mind?  Or did you want to put a new rule into 2.1, 
that would ban the mixing of TCC and RGBa?   (Which mixing was legal in 1.0 
and 2.0, tho' it's unlikely that it was ever done.)

Thoughts?  (Anyone, esp. implementors.)


>Regarding the background object attribute...

Okay, we're talking about the 'background' <param> element within the 
<object> element, right?  For reference, here is the 3.4 description:

[[[
States whether the CGM picture shall be drawn with its normal background 
color, as given in the CGM picture (Enable), or whether the background 
color of the picture shall be suppressed (Disable), thus allowing the 
background color or background image of the HTML page to show through. 
Default is Enable. Note: the background color of the picture is either 
default, or is explicitly defined by the BACKGROUND COLOUR element in the 
CGM picture.
]]]

>I can only speak for a
>Windows implementation but no, it's not the same thing. The canvas
>initialization is not really related to the background object attribute.
>Using an RGBA color model; it should always be initialized to
>transparent black.

Huh?  What if the color model of the metafile is RGBa, and the picture's 
Background Color element specifies "opaque green"?  Doesn't the viewer 
initialize the canvas to opaque green?

(I'm suspecting I'm misunderstanding your point here...)

>Instead, the object background attribute controls
>how the activeX is created (i.e., does it have it's own device context
>or, does it share IE's device context). Something along those lines
>(sorry, lack of info).

I'm not sure I understand.  Maybe it would be easier to discuss.  Given the 
description of 'background' <param>, it really seems that its effect is 
identical to a background color in the picture definition that is 
transparent (whether by Esc.45 in the PD, or (0,0,0,0) as the Background 
Color element in the PD).

Regards,
-Lofton.


>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Thursday, February 21, 2008 11:06 AM
>To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] transparency -- conceptual recommendations
>
>At 09:49 AM 2/21/2008 -0500, Bezaire, Benoit wrote:
> >Hi Lofton,
> >
> >I'm trying to understand all of this. I'm confused about the V1/V3
> >stuff (wasn't around early on)... for #B, what is Transparency suppose
>to do?
>
>
>"V1/V3" means it was basic ISO CGM functionality applying to Version 1
>and Version 3 CGM.  (That detail is actually irrelevant to this topic.)
>
>Transparency is 'on' or 'off' (default).  When 'off', then the
>inter-dash spaces in dashed lines, and a few other things also, are
>fully transparent.  When 'on', then inter-dash spaces (etc) are rendered
>opaquely in the Auxiliary Color.
>
>See 7.5.3 and 7.5.4 in CGM:1999:
>http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
>
>
> >For #C, when you say "for any cell whose color matches the specified
> >TCC", does color match mean R, G, B and A components (all four) or only
>
> >RGB (color only, transparency is irrelevant)?
>
>That is a good question/issue.  I guess I was thinking all four.  Seems
>most consistent with CGM:1999.  Also, color could be indexed, in which
>case it is the index that matches (regardless of whether the
>corresponding Color Table entry is RGB or RGBa.)
>
>I don't really care which way we resolve it.  We could say just R,G,B
>(if color mode is 'direct', instead of 'indexed').  Is there a use case
>that suggests we should have the additional complexity to just pick out
>the R,G,B of an RGBa color?
>
>I'll propose "no".  Match the whole 4-component RGBa.  If anyone wants
>to argue for "ignore 'a'", have at it.
>
>(Btw, who amongst us has implemented the RGBa color model?)
>
>
> >For #D, don't you mean "to 1 (opaque)"? if (0,0,0,0) is transparent
> >black; (r,g,b,1) should be opaque.
>
>Indeed, good catch.  Thanks.
>
>
> >For #F, we could say DON'T DO THIS. However, I think the last paragraph
>
> >of 2.2.2 covers this case: it's an additional temporary canvas.
>
>Okay.  I can live with that.
>
>
> >For #G, I don't believe we support that attribute. Who does?
>
>Good question.  I suspect "no one".
>
> >The
> >equations work with premultiplied values, so (r,g,b,0) where r,g,b is >
>
> >0 is impossible.  I would instead assume that the way to implement this
>
> >is to initialize the background to transparent black and blend the
>"CGM"
> >result into the HTML background.
>
>I'm fine with that.
>
> >Is it possible that the working group
> >added the 'background' attribute without knowing the implementation
> >implications, which are (I think): windowless activeX controls and
> >alpha blending support (on Windows at least). If no vendor supports
> >this attribute, I think we should deprecate it in 2.1.
>
>Propose deprecation to the TC as an issue.
>
>Btw, does the same issue arise for the viewer if background transparency
>is indicated either by an Esc.45 in the Picture Descriptor (PD) or by a
>Background Color element of (0,0,0,0) in the PD?
>
>
> >Hope my comments help a bit,
>
>They do indeed.  Thanks!
>
>-Lofton.
>
> >-----Original Message-----
> >From: Lofton Henderson [mailto:lofton@rockynet.com]
> >Sent: Wednesday, February 20, 2008 8:00 PM
> >To: cgmo-webcgm@lists.oasis-open.org
> >Subject: [cgmo-webcgm] transparency -- conceptual recommendations
> >
> >Hi All --
> >
> >Here is my analysis of the transparency functionality in WebCGM.  I
> >have summarized the possible sources, given recommendations, and
> >proposed preliminary *conceptual* changes to the spec.  After we agree
> >on those, I'll actually draft the changes.
> >
> >Sorry if it is lengthy.  But we need it to be complete.  High-level
> >summary:  the 2.0 spec is in pretty good shape, though lacking clarity
> >on a couple of items.  I propose some small changes that will fill
> >those holes.  (Recognizing that these specs go beyond what most will
> >implement.)  And I propose ignoring or labelling some silly
> >combinations.
> >
> >Please comment...
> >
> >SOURCES:
> >=====
> >
> >Foreground Sources:
> >f1.) "a" (alpha) of color models RGBa, sRGBa.
> >f2.) Esc.45 in picture body.
> >f3.) Auxiliary Color & Transparency elements (CGM:1999)
> >f4.) Transparent cell color (CGM:1999 & Esc.22).
> >
> >Background Sources:
> >b1.) RGB background color specification in PD:
> >b2.) RGBa background color specification in PD:
> >b3.) Esc.45 in the picture descriptor:
> >b4.) <object> elt's 'background' <param>: enable | disable
> >
> >ANALYSIS & RECOMMENDATIONS:
> >=====
> >
> >A.) The basics of #f1 and #f2 are handled by Sec.2.2.2 [1].
> >
> >B.) #f3 is V1 functionality.  Effect is not explicitly defined in
> >WebCGM combinations with the other transparency effects.  Recommended
> >meaning:  when Transparency is 'on' (default), then for the inter-dash
> >spaces (etc) the (Pr, Pg, Pb, Pa) in the equations of [1] is set to
> >(0,0,0,0) -- transparent black.  When transparency is 'off', then for
> >inter-dash spaces (etc) the (Pr, Pg, Pb, Pa) is set to (r,g,b,a) of the
>
> >Transparent Color.  (If the color model of the metafile is simple RGB,
> >then (Pr, Pg, Pb, Pa) it is set to (r,g,b,1).)  This is simply a
> >precise description of the intended meaning of V1 CGM, I think.
> >
> >C.) #f4 is V1/V3 functionality.  Effect is not explicitly defined in
> >WebCGM combinations with the other transparency effects.  Recommended
> >meaning:  for any cell whose color matches the specified TCC, the (Pr,
> >Pg, Pb, Pa)  for that cell in the equations of [1] is set to (0,0,0,0)
> >-- transparent black.  This is simply a precise description of the
> >intended meaning of V1/V3 CGM, I think.
> >
> >D.) #b1:  Ca in the equations of [1] should be initialized to 0
> >(opaque);  Cr, Cg, Cb are initialized to the (r,g,b) of the specified
> >background color.
> >
> >E.) #b2:  (Cr, Cg, Cb, Ca) in the equations of [1] should be
> >initialized to the (r,g,b,a) of the specified background color.
> >
> >F.) #b3:  If the color model is RGB, then (Cr, Cg, Cb, Ca) in the
> >equations of [1] should be initialized to the (r,g,b,a), where (r,g,b)
> >is the specified background color and "a" is the Esc.45 alpha value.
> >If the color model is RGBa, then ... silly combination ... why would
> >you have an RGBa specified background color in the PD and then throw in
>
> >an
> >Esc.45 element to (re)do what is already done by the "a" of RGBa?
> >DON'T DO THIS.
> >
> >G.) #b4:  After initializing (Cr, Cg, Cb, Ca) according to the contents
>
> >of the metafile (#D-F), then:  if 'enable', we're done;  if 'disable',
> >then replace Ca with 0.0.
> >
> >PROPOSED CHANGES TO SPEC -- CONCEPTUAL:
> >=====
> >
> >Sec.2.2.2 [1] is well-written and provides a foundation for all of
> >this, without much change.
> >
> >-- clarify #B by a "Note" in T.18.3 and in T.18.4 [6] that describes as
>
> >in #B and points back to Sec.2.2.2 [1].
> >
> >-- clarify #C by a "Note" in T.18.16 [5] that describes as in #C and
> >points back to Sec.2.2.2 [1].
> >
> >-- clarify #D-F by:  *brief* elaboration in Sec.2.2.3 [2] about how
> >#b1-b3 define the effective background color, which initializes
> >(Cr,Cg,Cb,Ca) of Sec.2.2.2.  This is basically what is already there,
> >except being a little more precise and complete.  Ignore the "silly"
> >case.  (Or alternatively, identify it as a silly thing to do and warn?)
> >
> >REFERENCES:
> >=====
> >
> >[1] Sec. 2.2.2:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Concepts.html#webcgm
> >_
> >2_2_2
> >[2] Sec. 2.2.3:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Concepts.html#webcgm
> >_
> >2_2_3
> >[3] Esc.45:
> >http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/esc045.html
> >[4] Sec. 3.4:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-IC.html#webcgm_3_4
> >[5] TCC in T.18.16:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Profile.html#webcgm_
> >4
> >_7
> >[6] AuxClr & Trnsp in T.18.3 & T.18.4:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Profile.html#webcgm_
> >4
> >_7
> >
> >Regards,
> >-Lofton.
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe from this mail list, you must leave the OASIS TC that
> >generates this mail.  You may a link to this group and all your TCs in
> >OASIS
> >at:
> >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe from this mail list, you must leave the OASIS TC that
> >generates this mail.  You may a link to this group and all your TCs in
> >OASIS
> >at:
> >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php