Color-interpolation properties
I found out at least one source of differences in rendering of filters between Inkscape and Batik/W3C test suite, and that's the color-interpolation-filters property. This property determines the color space used for filter operations (color-interpolation does the same for gradients and normal compositing), and Inkscape doesn't support it at the moment.
The problem is that by default color-interpolation is set to sRGB and color-interpolation-filters to linearRGB (sRGB before the gamma adjustment)... There was probably some rationale for this, but it's a pretty big nuisance, as it means that we'll probably have to convert to and from linearRGB for each application of filtering (as the conversion is very much non-linear).
Also, this means that pretty much any file that uses filters should actually be rendered differently from how it is rendered now (and often quite visibly different). So it might be a good idea to do something about this ASAP, to minimize the impact.
So, now my question is: What to do about this?
There are a number of possibilities. First of all, Inkscape could start setting the color-interpolation-filters property to use sRGB. This would probably be a very quick "fix" and at least ensure that any new files created with Inkscape will render the same in other (compliant) viewers. Obviously this wouldn't resolve problems with current files.
The main other possibility is to add support for color-interpolation-filters. Obviously this is the right thing to do in the long run, but it's also tricky to do it right. Quality (and probably performance) wise it would likely be best to allow the conversion to be part of the filter, as for example gaussian blur already uses increased precision internally and could apply the conversions with little loss in quality. However, it would obviously be much easier to simply write conversion functions and call them before and after applying any filters.
And even if support for color-interpolation-filters is added, it might still make sense to set it to sRGB (or set color-interpolation to linearRGB), as letting the settings be different results in non-intuitive behaviour like having normal compositing behaving differently from the equivalent feBlend and feComposite modes.
Sun, 11 Jan 2009 21:01:36 +0100 Jasper van de Gronde <th.v.d.gronde@...528...> kirjoitti:
The main other possibility is to add support for color-interpolation-filters. Obviously this is the right thing to do in the long run, but it's also tricky to do it right. Quality (and probably performance) wise it would likely be best to allow the conversion to be part of the filter, as for example gaussian blur already uses increased precision internally and could apply the conversions with little loss in quality. However, it would obviously be much easier to simply write conversion functions and call them before and after applying any filters.
I think we could use a mixed approach, just like we now do with rotated coordinate systems. Some filter primitives can handle rotated coordinate systems, some require coordinate systems aligned with pixel grid. If any primitive in a filter can't handle rotated coordinate systems, the rotation will be undone before filtering and redone after filtering.
And yes, setting color-interpolation-filters to srgb by default sounds like a good idea. I could be rather confusing, if same colour value would result in one colour when used as object colour and another colour when used in feFlood. (for example)
Niko Kiirala wrote:
Sun, 11 Jan 2009 21:01:36 +0100 Jasper van de Gronde <th.v.d.gronde@...528...> kirjoitti:
The main other possibility is to add support for color-interpolation-filters. Obviously this is the right thing to do in the long run, but it's also tricky to do it right. Quality (and probably performance) wise it would likely be best to allow the conversion to be part of the filter, as for example gaussian blur already uses increased precision internally and could apply the conversions with little loss in quality. However, it would obviously be much easier to simply write conversion functions and call them before and after applying any filters.
I think we could use a mixed approach, just like we now do with rotated coordinate systems. Some filter primitives can handle rotated coordinate systems, some require coordinate systems aligned with pixel grid. If any primitive in a filter can't handle rotated coordinate systems, the rotation will be undone before filtering and redone after filtering.
Something like that would indeed be ideal.
And yes, setting color-interpolation-filters to srgb by default sounds like a good idea. I could be rather confusing, if same colour value would result in one colour when used as object colour and another colour when used in feFlood. (for example)
I think that the color you specify for feFlood is actually still interpreted as sRGB, it's just that all calculations are carried out using linearRGB. So for feFlood I don't think it should make any difference, but I could be wrong.
participants (2)
-
Jasper van de Gronde -
Niko Kiirala