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: [cgmo-webcgm] transparency -- conceptual recommendations


Hi Lofton,

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.

Regarding the background object attribute... 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.  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).

Benoit.

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]