Colour change on blurred elements with a transform (regression in trunk)

[Cheeseness]

When a blurred element is transformed via a flip, rotate or shear, the colour of that element appears darker.

It does not happen when transforming an element inside a blurred group. Removing the blur reverts the element to its original colouring.

Steps to reproduce:
1) Launch inkscape with default prefs
2) Create a path (it's easier to see on filled paths)
3) Blur the path using the Fill and Stroke dialog's blur slider
4) Flip the path using the "Flip selected objects horizontally" toolbar button

Expected result:
The path should appear to be an exact mirrored version of its original form.

Actual result:
The fill and stroke of the flipped path is darker than its original colour.

Tested with Inkscape 0.48+devel r12044 on Fedora 17 32 bit.

Thanks to su_v for confirmation with other revisions (as far back as 11973) and additional assistance.

[su_v (suv-lp)]

Reproduced with Inkscape 0.48+devel r12129 on OS X 10.7.4 (tested with cairo 1.12.2, and cairo 1.12.14)

Tests with archived builds:
- Not reproduced with revision <= 11965
- Reproduced with revision >= 11973

Likely introduced with changes between r11969-11972 (support for color-interpolation-filters = linearRGB):
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/11973>

[su_v (suv-lp)]

Adding another sample file which illustrates the difference whether the Gaussian blur was applied via Filter editor, or via Fill&Stroke

Steps:
1) draw a path
2) create two clones, flip one of the clones
3) blur the original path

[Jabiertxof (jabiertxof)]

The problem is that the Fill&Stroke apply doesnt include the style color-interpolation-filters:sRGB to the filter element.

[Jabiertxof (jabiertxof)]

Fill&stroke blur slider bug fix

[Jabiertxof (jabiertxof)]

Im not sure to change the status to "fix commited" or not

[su_v (suv-lp)]

> Im not sure to change the status to "fix commited" or not

No, not yet - the bug status will be changed once a fix has actually been committed to trunk.

[su_v (suv-lp)]

Not sure where the proposed patch is the correct fix - to me it seems that the bug is in the rendering code (else Inkscape 0.49 will render old files considerably different than current stable 0.48.4, and also different than e.g. web browsers):

Please open attached sample file (created with Inkscape 0.48.4) first in stable Inkscape 0.48.4:
- all three objects have the same shade of grey
Now open the same file in current trunk (unpatched, or with Jabiertxo's patch applied - doesn't matter):
- the blurred object with a preserved transformation (a flipped clone of the blurred original) renders with a noticeably darker shade of grey.

[Jabiertxof (jabiertxof)]

Thanks ~suv for the info.

El mar, 10-09-2013 a las 02:36 +0000, ~suv escribió:
> > Im not sure to change the status to "fix commited" or not
>
> No, not yet - the bug status will be changed once a fix has actually
> been committed to trunk.
>

[Jabiertxof (jabiertxof)]

Hi ~suv you are ok, the problem with old files persist if you open a "old" svg and dont touch the blur slider.
I think the best thing we can do is set a defautl render colorspace. ¿whats your opinion?

[su_v (suv-lp)]

On 2013-09-10 12:39 +0200, Jabiertxo Arraiza Cenoz wrote:> I think the best thing we can do is set a defautl render colorspace. ¿whats your opinion?

In my limited understanding, it looks like a math error in the renderer code for blurs on objects which have a (preserved) matrix transformation applied, or are inside a container (group) which has such a transform attribute applied (affects e.g. working with PDF files opened in Inkscape too - their initial layer is vertically flipped). I'm not a developer myself, and don't know whether to "set a defautl render colorspace" would address this (I was under the impression that Inkscape already does assume a default color space if not explicitly defined in the filter definition).

[Jabiertxof (jabiertxof)]

Hi ~suv i made the change for use sRGB instead linearRGB by default. Now the file opens OK but im not sure about others problems. Tav has some post about linearRGB in filters...

[su_v (suv-lp)]

@Jabiertxo - any chance you could create your patches with 'bzr diff' against trunk?

[su_v (suv-lp)]

Attaching patch from comment #13 formatted with 'bzr diff' against current trunk (r12504) for easier review and testing.

[Jabiertxof (jabiertxof)]

Sorry ~suv i lost remove a line here are the correct patch formatted with 'bzr diff'

[Martin Owens (doctormo)]

I've tested the patch and it's working with all the example files as well as the STRs. I'm going to leave the Linear colour space problem to the feature developers to sort out later, for now I've merged the patch and I'm posting this as Fixed Committed.

[Martin Owens (doctormo)]

Sorry: see r12530 for the merge.

[su_v (suv-lp)]

Attaching comparison of the rendering of the sample SVG filter effect
  <http://www.w3.org/TR/SVG/images/filters/filters01.svg>
with
1) current trunk r12579 (left)
2) current trunk r12579 with r12530 reverted (right)

Bottom row: montage (for easier comparison)

[Tavmjong Bah (tavmjong-free)]

Revision 12590 should be a proper fix to this bug.

[su_v (suv-lp)]

@Jabiertxo, @Tav - thanks a lot to both of you for the time and efforts spent to fix this regression!