- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 7 Aug 2012 06:59:34 -0700
- To: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- CC: "public-fx@w3.org" <public-fx@w3.org>, Stephen Chenney <schenney@google.com>
On Aug 7, 2012, at 6:35 AM, Dirk Schulze <dschulze@adobe.com> wrote: > > On Aug 6, 2012, at 9:23 PM, Dirk Schulze <dschulze@adobe.com> wrote: > >> At first I have to reverse my first response. The feGaussianBlur has the FillPaint as input. So it is not unrelated. >> >> See inline comments. >> >> On Aug 6, 2012, at 8:09 PM, Nikos Andronikos <nikos.andronikos@cisra.canon.com.au> wrote: >> >>> Hi Dirk, >>> >>> In the definition for FillPaint, what does the following line mean? >>> >>> This keyword represents the target element rendered filled. >> See comment at the end of the mail. >> >>> >>> What I would read it to mean conflicts with my previous understanding of FillPaint, and the other text in the definition. >>> >>> On 7/08/2012 11:50 AM, Dirk Schulze wrote: >>>> It clarifies already that requested pixels outside of the current primitive are assumed to be transparent black. Therefore the rendering output of opera and webkit is correct here. FillPaint is a pseudo filter primitive and does not contribute to the context you describe. I can add the quotes in a follow up mail once I am on my desk if you can't find the necessary quotes. >>>> >>>> Greetings >>>> Dirk >>>> >>>> Sent from my iPhone >>>> >>>> On Aug 6, 2012, at 5:28 PM, "Cameron McCormack" >>>> <cam@mcc.id.au> >>>> wrote: >>>> >>>> >>>>> Consider this document: >>>>> >>>>> >>>>> http://people.mozilla.org/~cmccormack/tests/blur.svg >>>>> >>>>> >>>>> The Filters spec (and SVG before it) says the following in the >>>>> feGaussianBlur section: >>>>> >>>>> If the input has infinite extent and is constant (e.g FillPaint, >>>>> this operation has no effect. >> Like Rik said is actually the correct interpretation of this line. According this line, the feGaussianBlur has the FillPaint as input and is constant. Therefore feGaussianBlur should not have any effect. But there are a couple of problems with that line: >> >> a) input/output clipping region - Every primitive has a sub region (depends on the input but is x="0%" y="0%" width="100%" height="100%" for Cameron's example). The question is if this sub region, which acts as a clipping region, is an input clipping, output clipping or both. The spec should be more clear about that. In WebKit we interpret the clipping region as output clipping region IIRC (added Stephen Chenney to confirm). If we say the sub region is an input, or an input and output clipping region, the line is wrong and the output of Opera is correct. If it is just an output clipping region, the result on Firefox is correct. >> >> b) This line says "constant". I would interpret constant as a solid color, but this line seems not to do so, since it assumes that FillPaint is always constant. If we have an output clipping region, and the FillPaint is solid, the feGaussianBlur should have no affect (since the color values are the same everywhere). But how about patterns and gradients? It wouldn't make sense not to blur this content. So we have an inconsistency here. >> >> >> I would rather delete this line and clarify the affect of clipping region on input and output. This should clarify all cases. > > The spec says the following currently: > > "The filter primitive subregion act as a hard clip clipping rectangle on both the filter primitive's input image(s) and the filter primitive result." > > With the issue: > > "Consider making it possible to do select between clip-input, clip-output, clip-both or none." > > This is a clarification that was added in Filter Effects 1.0. With this clarification the previous quote on infinite input is invalid. I will remove this line. With the current default of input and output clipping, the FillPaint should be blurred on the edges for Cameron's example. > > Greetings, > Dirk Since we did not decide if we want to give the author the choice to choose between input and output clipping, I added an issue for now. It turns out that the initially quoted sentence is incomplete and should be "… (e.g FillPaint where the fill is a solid color)" like for feMorphology. This sentence seems to be a hint for implementers how to improve the filtering. It is obvious that a blur on a color with infinite extends does not have any effect (or better: looks like it does not have an effect). FillPaint needs to be blurred if it is a gradient or pattern. Greetings, Dirk > > >> >>>>> >>>>> The document uses FillPaint as the input to feGaussianBlur, but in Opera >>>>> at least, the blue rectangular area has blurry edges, because it is >>>>> (presumably) sampling transparent black outside the source image area. >>>>> For the operation to have no effect, you would expect the rectangle to >>>>> have sharp edges, which would imply sampling the FillPaint outside the >>>>> source image area. >>>>> >>>>> The test >>>>> >>>>> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/filters-overview-01-b.html >>>>> >>>>> seems to assume that transparent black is sampled outside the source >>>>> image area. >>>>> >>>>> The spec should be clarified to indicate how to sample around the edges >>>>> of the source image, and if it should be transparent black, the sentence >>>>> about having no effect with FillPaint should be changed. >>>>> >>>>> >>> >>> The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system. >> >> To >>> This keyword represents the target element rendered filled. >> A FillPaint references the paint server of the filtered element: >> >> <rect fill="url(#aPattern)" filter="url(#aFilter)"/> >> >> The paint server would be #aPattern here. >> >> Greetings, >> Dirk > >
Received on Tuesday, 7 August 2012 14:00:08 UTC