RE: [cgmo-webcgm] Drawing model (take 2)

[Lofton Henderson <lofton@rockynet.com>]

At 05:50 PM 4/20/2006 +0200, Dieter  Weidenbrück wrote:
>One additional issue:
>
>Where are the two implementations for each of these features that we will
>need?
>We don't have one.

That is indeed a good question.  It occurred to me also.  Here are some 
thoughts...

At the time WebCGM 1.0 was standardized (Jan '99), it was not required that 
each feature have two implementations to progress beyond CR.  These are 1.0 
features.  So the question is, should we remove them from REC (in 2.0) 
because they're not implemented?

It can probably be argued either way.  On the one hand, we have removed the 
unused (and somewhat redundant) 'viewport' PARAM feature.  On the other 
hand, this alpha thingy was a general requirement for graphics-on-Web 
(s.v.g.) formats, written by Chris about a decade ago.

While it might be a general requirement, as we see, the specific main 
constituency of WebCGM is not yet using it (which is why it's not implemented).

Given that it is already in a REC, I suspect that we would have to 
deprecate it before removing it.  (If we were to decide that it should be 
gotten rid of).

Bottom line again ... my preference is to ignore it (the question), until 
pressed about it.

-Lofton.


> > -----Original Message-----
> > From: Lofton Henderson [mailto:lofton@rockynet.com]
> > Sent: Thursday, April 20, 2006 5:34 PM
> > To: Benoit Bezaire; cgmo-webcgm@lists.oasis-open.org
> > 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.
> > >
> > >Modifications:
> > >  - 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).
> >
> > >
> > >Questions:
> > >  - 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?
> >
> > -Lofton.
> >
> >
> > >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.
> >
> >
> >