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

[Lofton Henderson <lofton@rockynet.com>]

Benoit,

Thanks for the clarifications.  I'll suggest that we finish this off in 
telecon.  It is only a couple of small quibbles now.

Brief comments embedded...

At 07:58 PM 2/21/2008 -0500, Bezaire, Benoit wrote:
>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?

Ah, I misunderstood your point.  I'll propose "include Ca", and entertain 
objections.  (I don't care strongly, as I think it is a marginal [silly] 
case to use TCC in an RGBa metafile.)


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

Okay, I see your model.

(Tho' I need to ponder more about the difference between that and just 
initializing the canvas to opaque green -- let's talk Wednesday.)


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

As I remember, the motivation here was to provide a way for document 
builders to override the CGM contents (bkgd clr), if the CGM was created 
with a background specification that is inappropriate for its use in the 
document.  (Overlaying on another CGM, or HTML, or JPEG, or ...)

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

Point taken, about the use case of allowing the HTML to show through.

You might be right about that intent.  It was about 9 years ago that this 
was invented, and I can't exactly remember.  I don't remember any detailed 
discussion about the requirements of overlaying the CGM picture, in the 
context of HTML <object> element (which is what the 'background' <param> is 
about).

Let's talk Wednesday -- what, if anything, should we do to 'background' 
<param> text in 3.4 (and the reference in 2.2.3)?

Also, how many people have implemented this?  (And wasn't there an earlier 
suggestion to deprecate it?)

Thanks,
-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
>
>
>
>---------------------------------------------------------------------
>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