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

["Bezaire, Benoit" <bbezaire@ptc.com>]

Please see below... 

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Thursday, February 21, 2008 5:13 PM
To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] transparency -- conceptual recommendations

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.
BB: understood!

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.)
BB: I was only asking if "matching color" meant equal Cr, Cg, Cb values
or if it also included Ca?

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

BB: Yes, we are talking about the same thing.

>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...)
BB: well maybe I was a bit brief, sorry. In my opinion, everytime a
"canvas" is created, it should be initialized to black. That way,
regardless of the background param, or the Picture's Backgroud Color,
compositing will work. For the "opaque green" example you mention
above... I would have first created a transparent black canvas, then
filled it with opaque green when once I'd have encountered the
Background Color element (assuming background param is set to enabled).

>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).
BB: I don't think so. If yes, why is it necessary to have this on the
<object> tag? Isn't the CGM by itself sufficient? I think it was meant
for something else, cool looking web pages! Note: "thus allowing the
background color or background image of the HTML page to show through."
Imagine a CGM on top of a gradiant background, or a raster image, or
some other HTML content. I bet Chris wrote that part, right ;-)  For the
HTML to show through, you need to create your activeX differently.

Benoit.


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#webc
> >gm
> >_
> >2_2_2
> >[2] Sec. 2.2.3:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Concepts.html#webc
> >gm
> >_
> >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#webcg
> >m_
> >4
> >_7
> >[6] AuxClr & Trnsp in T.18.3 & T.18.4:
> >http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Profile.html#webcg
> >m_
> >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.ph
> >p
> >
> >
> >---------------------------------------------------------------------
> >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.ph
> >p
>
>
>
>---------------------------------------------------------------------
>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