Mitigating color-interpolation-filters problems
According to the SVG spec filters can be rendered in either the sRGB or the linearRGB color space, the same goes for gradients and alpha compositing). The latter is controlled by the color-interpolation attribute, the former by the color-interpolation-filters attribute. Inkscape does not handle either of these.
Unfortunately the default for color-interpolation is sRGB, while the default for color-interpolation-filters is linearRGB... This means that Inkscape's rendering of pretty much any filter is incorrect (how severe this is depends on the filter). And perhaps more importantly, it differs from how other renderers behave.
I don't think it's a good idea at this time to truely "solve" this problem. But perhaps we could make sure that new filters created by Inkscape automatically have their color-interpolation-filters attribute set to sRGB? (I have no idea how to do that, so any help is appreciated.)
For reference, I created the following bug report: https://bugs.launchpad.net/inkscape/+bug/365073
On Wed, Apr 22, 2009 at 8:50 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
I don't think it's a good idea at this time to truely "solve" this problem. But perhaps we could make sure that new filters created by Inkscape automatically have their color-interpolation-filters attribute set to sRGB? (I have no idea how to do that, so any help is appreciated.)
If that fixes the rendering discrepancy, of course let's do it. Later when we enable Inkscape to handle other values, this attribute in old files will not hurt as it is a compliant way to set the default. It is easy to add for all filters Inkscape writes to SVG by modifying sp_filter_write in sp-filter.cpp, please also add a comment there explaining why it's needed.
bulia byak wrote:
On Wed, Apr 22, 2009 at 8:50 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
I don't think it's a good idea at this time to truely "solve" this problem. But perhaps we could make sure that new filters created by Inkscape automatically have their color-interpolation-filters attribute set to sRGB? (I have no idea how to do that, so any help is appreciated.)
If that fixes the rendering discrepancy, of course let's do it. Later when we enable Inkscape to handle other values, this attribute in old files will not hurt as it is a compliant way to set the default. It is easy to add for all filters Inkscape writes to SVG by modifying sp_filter_write in sp-filter.cpp, please also add a comment there explaining why it's needed.
I don't think that's the right solution, as it is *not* the default. So technically all filters Inkscape has made (and frankly most filters in general) effectively have color-interpolation-filters="linearRGB", while Inkscape treats every filter as if it had color-interpolation-filters="sRGB".
So writing this property to *any* file Inkscape writes could suddenly cause old files to render differently than they did (not in Inkscape but in other renderers). Perhaps a minor nuisance (unless you're wondering why Batik suddenly renders your file completely differently), but it would be nicer to just do it for newly created filters.
On Wed, Apr 22, 2009 at 11:55 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
So writing this property to *any* file Inkscape writes could suddenly cause old files to render differently than they did (not in Inkscape but in other renderers).
If this brings them in line with the way Inkscape renders them, I think it's the least of all evils that we can do. Leaving this as is is certainly worse.
Perhaps a minor nuisance (unless you're wondering why Batik suddenly renders your file completely differently), but it would be nicer to just do it for newly created filters.
Actually, the write method is not called every time you save, but only when you changed the filter in some way, or resave it in plain SVG format. If you just open a file, change something else, and save back, the write method will not fire (test it). So this sounds like what you're after.
bulia byak wrote:
Perhaps a minor nuisance (unless you're wondering why Batik suddenly renders your file completely differently), but it would be nicer to just do it for newly created filters.
Actually, the write method is not called every time you save, but only when you changed the filter in some way, or resave it in plain SVG format. If you just open a file, change something else, and save back, the write method will not fire (test it). So this sounds like what you're after.
I tried this (and committed it), but it appears it is ONLY done when saving to plain SVG... I guess this may not be that bad, but I do think it's odd.
On Thu, Apr 23, 2009 at 9:27 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
I tried this (and committed it), but it appears it is ONLY done when saving to plain SVG... I guess this may not be that bad, but I do think it's odd.
It's probably because it's not so easy to generate the update signal for the filter object itself (as opposed to its children primitives). Most importantly, does it get set for newly created filters? If so we're good to go.
bulia byak wrote:
On Thu, Apr 23, 2009 at 9:27 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
I tried this (and committed it), but it appears it is ONLY done when saving to plain SVG... I guess this may not be that bad, but I do think it's odd.
It's probably because it's not so easy to generate the update signal for the filter object itself (as opposed to its children primitives). Most importantly, does it get set for newly created filters? If so we're good to go.
No, it really only seems to be triggered when saving to plain SVG.
participants (2)
-
bulia byak -
Jasper van de Gronde