370554 - linearRGB/sRGB correction on restricted rects giving odd result

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[tor]

The linearRGB/sRGB correction for filters only does the correction on the pixels on the pixels in the entry region.  In the attached testcase, this causes a problem since the full image is converted to premultiplied-linearRGB when looked up by the blend filter as input, but it defines an image with a 0,0-0x0 rect.  When FilterPaint looks up the result image to paint, it requests premultiplied-sRGB, but since there is an empty region the pixels aren't converted back.

Comment 1

[tor]

Attachment: testcase - should show a single light green square

Comment 2

[Robert Longson [:longsonr]]

Attachment: patch

Comment 3

[tor]

I'm probably missing something obvious, but do we need this now given the filter subregion change?  The area outside the valid region indicated by the rect will be transparent black, which is unaffected by the color or packing conversions.

Comment 4

[Robert Longson [:longsonr]]

My thinking is that you'd need two filters covering different areas to see a problem. Imagine you have filter a (linearRGB) and filter b (sRGB), neither of which cover the complete area c (which must be sRGB). Note that a and b might partially overlap each other.

Apply filter a and c goes to linearRGB. Then apply b and you have to convert c back to sRGB. If you only convert a to sRGB then anything in b which falls outside a would be operating on a linearRGB surface.

The alternative would be to just convert the filter regions (i.e. a and b) but as you said before when I was developing this code the default is linearRGB and you'd have to convert a and b back to sRGB after applying so that you had a consistent surface.

Is that right or am I confused?

Comment 5

[tor]

The way I see it, after fE <a> is applied, only the region <a> contains data - the rest is transparent black.  <a> is converted to sRGB for fe <b>, which again only outputs pixels in region <b> - the rest is blank.  It defines a final image with the correct region <b>.

Comment 6

[Robert Longson [:longsonr]]

OK so we're fine functionally. Things to think about though:

a) We convert the whole surface when we acquire it. We only need to do the filter subregion. (My current patch does not address this).

b) do we need the subregion size in ImageEntry?  nsSVGFilterInstance::LookupImage gets it in nsSVGFilterResource::AcquireSourceImage only to pass it back to nsSVGFilterInstance::GetFilterSubregion. GetFilterSubregion could get it itself (covered in this patch).

Comment 7

[Robert Longson [:longsonr]]

Roc's rewrite of filters fixed all this up.