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] Drawing model (take 2)

[...2 of 2...]

Thanks to Benoit for a thorough job on this!

My opinions are embedded at Benoit's questions.  Can we hear from others as 
well, especially *implementors*.

At 11:57 AM 4/19/2006 -0400, Benoit Bezaire wrote:
>Here is an attempt to address the Drawing model comment: "Color space
>for compositing not described, is alpha linear or not (maybe described
>later?) What is the influence of grnode on compositing - grouping
>complexifies compositing, neds to be carefully described."
>This could be a replacement or in addition to 2.2.2 Drawing model.
>  - color values are premultiplied.
>  - addition of three simple examples.
>  - typos in last paragraph.

I'm basically repeating what I said on the call...

This stuff has been sitting underspecified and unimplemented for 6 
years.  My basic instinct is:  the less we say, the better.  Or rather, 
maybe it isn't "better', but IMO there is less the chances of getting 
dragged into a complex issue and having to agree on a bunch of new 
specifications and write them into 2.0 (probably would be errata 
[clarifications] on 1.0 as well).

>  - Is this too much?

I wish it could be shorter, but on the other hand I don't see what to 
cut.  Examples?  Could the 10 lines of equations be consolidated 
somehow?  Are those fairly conventional and uncontroversial (except for my 
previous question about possible bug)?

>  - Is this not enough?

I think it's enough -- just answers his questions, plus a little more.

>  - What should we say (if anything) about Escape 45 and RGBA/sRGBA?

I'm somewhat in favor of saying nothing until/unless asked.

Alternatively, we could say that it was the intention of the original 
authors that you use one or the other, but not both together, therefore 
using both together would be prohibited (and that would also be a 1.0 
erratum).  It sounded yesterday like everyone agreed about that.

The only problem, why this isn't my first choice, is ... once we go there, 
we start to potentially open lots of doors and end up having to specify how 
all of the bits work together (or don't).  Which is something of a waste, 
as no one has implemented Esc45, or RGBA.

>  - What should we say (if anything) about transparent rasters?

You mean transparency within the PNG data, as opposed to Transparent Cell 
Colour of CGM.  (I don't know how the PNG transparency is defined.  Is it 
an Alpha channel?)

Like before, my preference is saying nothing until/unless asked.

>  - What should we say (if anything) about transparent cell arrays?

(And it gets uglier, when combined with potential  for Esc.45 and RGBA in 
the cell colours.)

Like before, my preference is saying nothing until/unless asked.

I could be convinced that it's NOT a good idea for us to try to remain mute 
on these questions.  I would listen to a specific solution.  That solution 
could be as simple as something like, "These functionalities [there are 
something like a half-dozen?] were designed to be used individually, and 
not in combination."  Then what?  Choice:  "...their use in combination is 
prohibited in this version of WebCGM"; or, "the effect of their use in 
combination is undefined in this version of WebCGM, and therefore it is 
strongly discouraged (may be prohibited in future version)."

The problem again ... as soon as we say something simple, we need to look 
at the 6x6 matrix of combinations and see if the statement makes 
sense.  Then we start arguing about simple exceptions (combinations), ...etc...

Enough for now.  Other thoughts?


>Implementations of WebCGM are expected to behave as though they
>implement a drawing model corresponding to the one described below. A
>real implementation is not required to implement the model in this
>way, but the result on any device supported by the implementation
>shall match that described by this model.
>WebCGM uses a painters model of rendering. Colors are applied in
>successive operations to the output device. When an area overlaps a
>previously colored area the new color partially or completely obscures
>the old. When the color is not completely opaque the result on the
>output device is defined by the following (mathematical) rules for
>compositing (all color values use premultiplied alpha):
>Pr, Pg, Pb    - Primitive color value
>Pa            - Primitive alpha value
>Cr, Cg, Cb    - Canvas color value (before blending)
>Ca            - Canvas alpha value (before blending)
>Cr', Cg', Cb' - Canvas color value (after blending)
>Ca'           - Canvas alpha value (after blending)
>Ca' = 1 - (1 - Pa) * (1 - Ca)
>Cr' = (1 - Pa) * Cr + Pr
>Cg' = (1 - Pa) * Cg + Pg
>Cb' = (1 - Pa) * Cb + Pb
>Example #1:
>Primitive is semi transparent red: (Pa, Pr, Pg, Pb) = (0.5,0.5,0,0)
>Canvas is opaque black: (Ca, Cr, Cg, Cb) = (1,0,0,0)
>Ca' = 1 - (1 - 0.5) * (1 - 1) = 1
>Cr' = (1 - 0.5) * 0 + 0.5 = 0.5
>Cg' = (1 - 0.5) * 0 + 0 = 0
>Cb' = (1 - 0.5) * 0 + 0 = 0
>The result is an opaque dark red (1,0.5,0,0).
>Example #2:
>Primitive is opaque red: (Pa, Pr, Pg, Pb) = (1,1,0,0)
>Canvas is semi transparent black: (Ca, Cr, Cg, Cb) = (0.5,0,0,0)
>Ca' = 1 - (1 - 1) * (1 - 0.5) = 1
>Cr' = (1 - 1) * 0 + 1 = 1
>Cg' = (1 - 1) * 0 + 0 = 0
>Cb' = (1 - 1) * 0 + 0 = 0
>The result is an opaque red (1,1,0,0).
>Example #3:
>Primitive is semi transparent red: (Pa, Pr, Pg, Pb) = (0.5,0.5,0,0)
>Canvas is semi transparent black: (Ca, Cr, Cg, Cb) = (0.5,0,0,0)
>Ca' = 1 - (1 - 0.5) * (1 - 0.5) = 0.75
>Cr' = (1 - 0.5) * 0 + 0.5 = 0.5
>Cg' = (1 - 0.5) * 0 + 0 = 0
>Cb' = (1 - 0.5) * 0 + 0 = 0
>The result is a transparent dark red (0.75,0.5,0,0).
>Alpha compositing is performed in the current COLOUR MODEL (see T.16.19).
>Primitives in a WebCGM document have an implicit drawing order, with the
>first primitives in the WebCGM document getting drawn first.
>Subsequent primitives are drawn on top of previously drawn primitives.
>Primitives which have a value for Escape 45 other than fully opaque,
>have the effect of producing a temporary separate canvas initialized
>to transparent black onto which the primitive is drawn. The canvas
>is then composited into the background, taking into account the Escape
>45 value. The presence of APS in the primitive list has no effect on
>the rendering. No temporary canvas are created. It is identical to the
>case of no APS.
>  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.

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