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

[Dieter Weidenbrück <dieter@itedo.com>]

One additional issue:

Where are the two implementations for each of these features that we will
need?
We don't have one. 

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