[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] Issue CL-d3: 2.2.2 Drawing model
Tuesday, March 28, 2006, 6:13:57 PM, you wrote:
> Benoit (& all) --
> Thanks for the research. My comments and answers are embedded.
> At 04:06 PM 3/27/2006 -0500, Benoit Bezaire wrote:
>>Some good and bad news...
>>
>>First the good news; Escape 45 is well defined since it defines the
>>compositing equation: result = alpha*foreground + (1-alpha)*background.
> Okay, so does that answer Chris's question, "is alpha linear?" -- it would
> seem to answer it.
It would seem like it. Although Chris may also be asking if the alpha
compositing is done in a linear or gamma corrected color space?
>>The bad news is that I don't know how a 4 channel RGB color model (say
>>RGBA or sRGBA) works in combination with Escape 45. I can't find the
>>answer in the pointers given to me. RGBA says the following:
>>"Conceptually, values of the alpha transparency are real numbers
>>between 0.0 (fully transparent) and 1.0 (fully opaque), inclusive, and
>>intermediate values have meaning identical to the alpha transparency
>>defined in Escape 45." I dunno, it still seems vague.
>>
>>My question is as follows:
>>Can I use the RGBA color model and also use Escape 45 in the same
>>WebCGM file?
> Let me ask in return, "why not?". Do you see any downside to allowing
> it? As long as we spell out the result precisely, then I see no problem
> with letting authors do it, if they want.
It's this sentence "[...] intermediate values have meaning identical
to the alpha transparency defined in Escape 45." that bothers me.
When the other color models were added (RGBA and sRGBA), the behavior
with Escape 45 should have been defined. (Assuming that RGBA and sRGBA
were added after Escape 45.
>>- If Yes...
>> - How are they combined?
>> i) multiply the two alpha values.
> I would vote for this. (I think "yes" and "multiply" is by far the easiest
> to specify -- fewer rules and conditions.)
Yikes!
>> ii) A of RGBA is used.
>> iii) Escape 45 is used.
>>- If No...
>> - Who wins?
>> i) RGBA
>> ii) Escape 45
>>
>>Thougths?
> As far as alpha goes, see above for my opinion.
> There seems to be several other aspects to Chris's comment, other than "is
> alpha linear":
> 2.) "What is the influence of grnode on compositing - grouping complexifies
> compositing, neds to be carefully described." My answer: the drawing
> model of CGM:1999, in the absence of APS, only implies compositing each
> successive primitive directly to the view surface, then the next primitive,
> then the next... In the case of alpha, then each primitive is composited
> to the partially-drawn view surface according to the linear equation.
I didn't ignore these other questions... only postponed them until I
had a clear picture of the transparency model of CGM.
I agree with what you say here.
> In the presence of APS, with inheritance mode equals 'statelist' (the only
> value allowed in WebCGM), is identical to the case of no APS. This is a
> rule of CGM:1999 -- the drawn picture is identical if the viewer ignores
> APS (note that we're violating that rule with 'visibility' ApsAttr, and
> that's the only such case of which I'm aware, in WebCGM). We need to
> remember than a WebCGM APS-structured stream of CGM primitives is still
> basically a stream of CGM primitives. An APS is not like a group in SVG,
> on which one must consider "group opacity" -- composite the whole group
> onto an off-screen bitmap and then blast it to the screen.
> Another way to say it -- Esc45 and the "A" of RGBA are primitive
> attributes, not group attributes.
I agree.
> 3.) "Color space for compositing not described" -- does the linear equation
> of Esc45 imply that the color space for compositing is the same as the
> color space of the metafile? (In WebCGM it's basically RGB -- can be RGB,
> RGBA, sRGB, sRGBA). I'm unsure of the answer. I do note that we purposely
> eliminated fine color control from WebCGM, i.e., the COLOUR CALIBRATION
> element. I suppose we ought to say how alpha (whether Esc45, or "A", or
> the product of the two) is done/rendered -- I would think that we just
> multiply each component -- R, G, and B -- by the "effective alpha",
> right? (effective alpha = Esc45, or "A", or the product of the two if both
> are present).
I was going to propose that alpha compositing be done in the same
color space as specified in the metafile. You seem to agree with me.
> I think that would probably suffice for WebCGM. (Although I'm unsure
> whether or not, by saying that, we might complicate the future
> specification of a WebCGM-cascaded "colorful profile").
> Thoughts about #2 and #3?
My concern about multiplying the alphas is implementation.
Who currently supports:
- Escape 45?
- RGBA?
- sRGBA?
Now if there's an implementation out there that supports say (Escape
45 and RGBA), what is it doing when the two are used together?
--
Regards,
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.
> Regards,
> -Lofton.
>>Friday, March 24, 2006, 11:26:00 AM, you wrote:
>>
>> > At 05:08 PM 3/23/2006 -0500, Benoit Bezaire wrote:
>> >>Link:
>> >>http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/17
>> 342/CL-comments.html#CL-d3
>> >>
>> >>Doh! The short version didn't work eh ;)
>> >>
>> >>I can take this one if nobody wants it.
>>
>> > Thanks!
>>
>> > (Btw, I have the impression that Forrest and Don have more interest in
>> > colour and compositing, with their petro application backgrounds. I'd like
>> > to see their feedback on these questions.)
>>
>> >>Lofton, you state that WebCGM is pretty unspecified here... what about
>> >>ISO CGM, what _does it_ specify? I wouldn't mind a couple of pointers
>> >>in the ISO CGM spec as a starting point:
>> >>
>> >>Section 2.5.3 Color and transparency of Webcgm 2.0 states:
>> >>- "The normal behavior of CGM:1999 viewers is to render later occurring
>> >>primitives completely opaquely on top of earlier primitives." Where is
>> >>this said in CGM:1999?
>>
>> > Amazingly, I can't find the explicit statement. ***ANYONE*** ... can you
>> > provide a reference to a precise statement in CGM:1999?
>>
>> > ("6.11 State model" certainly implies it, but actually is about an abstract
>> > state machine, as opposed to a viewer with rendering).
>>
>> > However, I assert that these are true, and *everyone* has implemented them:
>> > 1.) drawing occurs in element order (painters model);
>> > 2.) drawing is unaffected by APS grouping, i.e., one does not composite
>> > into an off-screen bitmap and then draw (like SVG).
>>
>> > (See 6.13.4, 'statelist' being the only inheritance value that is allowed
>> > in WebCGM.)
>>
>> > I think this is also true: WebCGM 1.0 & 2.0 people do not care about
>> > precise colour rendering -- it is not a requirement of the WebCGM
>> > constituency. COLOUR CALIBRATION is the CGM element that gives precise
>> > control, and it was excluded from both profiles.
>>
>> > Here are a couple of useful ISO CGM references:
>> > ISO 6.7.6 (Colour attributes)
>> > ISO 6.5.7 (Transparent Cell Colour)
>>
>>
>> >>- the alpha-transparency Escape element... where is that element
>> >>specified? Can we get the wording?
>>
>> > Two general references, plus the esc045 specific reference:
>>
>> > http://www.cgmopen.org/technical/registry/
>> > http://jitc.fhu.disa.mil/nitf/graph_reg/class_pages/escape.html
>>
>> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/esc045.html
>>
>>
>> >>- same question for sRGB/sRGBA, RGB/RGBA.
>>
>> > Two general references:
>> > http://www.cgmopen.org/technical/registry/
>> > http://jitc.fhu.disa.mil/nitf/graph_reg/class_pages/colour.html
>>
>> > and the three specific ones:
>> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/col006.html
>> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/col007.html
>> > http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/col008.html
>>
>>
>> >>Would it be fair to say that Esc 45 maps to the 'opacity' attribute in
>> >>SVG?
>>
>> > Same general idea. (Maybe inverted? I.e., transparency vs. opacity? I
>> > haven't looked at SVG to see which one it defines.)
>>
>> > -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]