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.