Josh Andler wrote:
On 06/25/2009 05:52 AM, Jasper van de Gronde wrote:
To ensure that your file looks the same in Inkscape as in other viewers, use color-interpolation-filters="sRGB" (as far as I know it's perfectly valid to do this just once, on the root SVG element). I've attached a file that shows how Batik renders filters-turb-01-f.svg with this modification.
I have a very important Q here for others... Should this be a release blocker? It sure sounds like a pretty significant one to me.
I raised the issue back in april (and in january) and suggested that we do not try to truly fix this for the upcoming release, as this would not exactly be trivial. At the time I tried mitigating it somewhat with some help from bulia by making Inkscape automatically write the property on filters it creates, but this could probably be greatly improved upon by someone who really knows how this part of the code works (not the filter part, but the SVG representation/serialization part).
... Not only is this something that we want to get corrected for our users, but this is one of those project reputation issues. It will be well over a year since our last release and one of our key new features is "broken" compatibility-wise with other SVG renderers/editors... and yet we're still on track to knowingly release with it?
I completely agree, and if you know of a low risk fix I'm completely in favour. From what I can tell we would need to do the following:
- Make sure EVERY element (not just filters) knows the value of its color-interpolation(-filters) property/-ies. - Convert the "input" colors (background color, foreground color, gradient stops, etc.) of each element to linearRGB if necessary. Note that there are some tricky issues here with regards to gradients. - Somehow make sure that elements are composited correctly. They should be composited using the color space of the *child* (and I'd have to check whether this translates to always using the color space of the foreground). - Convert any image that is used as input to a filter to the right color space before operating on it. - Anything else I've forgotten?
And while you're at it there's a good chance you'll want to increase the supported bit depth as well (to prevent any accuracy issues with conversions back and forth).
And of course you'll still want to think about what we want to use as a default, as I think the default from the standard is pretty weird to say the least (especially since it actually includes operations which can do normal alpha compositing, which would then only look different because of the color space). It would probably be most logical to either use sRGB for both properties or linearRGB for both properties.