Hi,
Isn't our turbulence filter producing darker output than expected? The attached svg file is borrowed from the w3c test suite, and also contains the expected png output: our render looks draker.
I bumped into this trying to use turbulence as a displacement map: the displacement always globaly shifts the image downward and to the right. This is because the avarage value in each turbulence output channel is not 128 but much darker.
I think this is a bug... (maybe premuliplied alpha versus normal alpha color mode?)
Am I wrong? jfb.
Fractal noise is, channel by channel i.e. before mixing with alpha, centered around 128, Gaussian (or pink) noise using 128 as zero point.
Turbulence comes by taking numerical value of this (again 128 as zero point) and interpreting the result with zero point out in one end, so it cannot be centered around 128. Fractal noise comes closer to, what you expected from turbulence.
The fractal noise is also known as "Perlin Noise" after Carl Perlin, who invented it in the 1980es. He has made a better version - simplex noise - later, but that was after the old Perlin noise was adopted by everybody. Simplex noise does not give the artifacts with the systematic white pattern, you can see in turbulence.
There is a description of simplex noise here: http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf
_____
From: jf barraud [mailto:jf.barraud@...400...] Sent: 25 June, 2009 07:53 To: inkscape-devel Subject: [Inkscape-devel] turbulence filters
Hi,
Isn't our turbulence filter producing darker output than expected? The attached svg file is borrowed from the w3c test suite, and also contains the expected png output: our render looks draker.
I bumped into this trying to use turbulence as a displacement map: the displacement always globaly shifts the image downward and to the right. This is because the avarage value in each turbulence output channel is not 128 but much darker.
I think this is a bug... (maybe premuliplied alpha versus normal alpha color mode?)
Am I wrong? jfb.
Thanks for your reply and explainations! You are right, fractal noise works better as displacement map, and I see there is some intrinsic reason for it now :-P.
However, this does not explain why our output is darker, and I still think there is something wrong there; I noticed the turbulence alpha channel affects the output of the displacement mapeven when the latter takes values in the color channels only:
Do the following test:
Create a filter with - turbulence primitive -color matrix -displacement map
Set the color matrix to do nothing (only 1s on the diagonal, 0s everywhere else and in the last column). Set the channels in displacement map to Red and Green for instance, give scale some positive value. Observe the result.
Kill the alpha channel in the color matrix, i.e. change the last coef in the last column of color matrix to 1:
See how the output is modified, while the displacement map is supposed to take values only in the Red and Green channels (and not in the Alpha channel).
I suspect we are using premultiplied alpha where normal colors should be used, but I remember I already bumped into similar strongly non intuitive conventions of svg with this respect (maybe the same one, I don't remember), so I'm not sure.
cheers, jfb.
jf barraud wrote:
... I suspect we are using premultiplied alpha where normal colors should be used, but I remember I already bumped into similar strongly non intuitive conventions of svg with this respect (maybe the same one, I don't remember), so I'm not sure.
No, it's not a premultiplied/non-premultiplied issue (btw, in the standard, if it doesn't say it's non-premultiplied it is premultiplied, it says so in section 15.7.1 of SVG 1.1). Rather, it has to do with Inkscape's lack of support for the color-interpolation-filters attribute (in combination with the extremely unintuitive decision to give color-interpolation-filters a different initial value than color-interpolation).
In SVG there are two attributes that determine the color space used for operating on color values, these are color-interpolation and color-interpolation-filters (both can be set to either linearRGB or sRGB). For some reason that is completely beyond me the W3C decided to make the initial value sRGB for color-interpolation and linearRGB for color-interpolation-filters... As Inkscape has no support whatsoever for color-interpolation-filters pretty much any file which uses a filter looks wrong in Inkscape.
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.
On Thu, Jun 25, 2009 at 9:52 AM, Jasper van de Gronde<th.v.d.gronde@...528...> 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.
Haven't we decided to insert this automatically if a filter is used?
bulia byak wrote:
On Thu, Jun 25, 2009 at 9:52 AM, Jasper van de Gronde<th.v.d.gronde@...528...> 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.
Haven't we decided to insert this automatically if a filter is used?
No, just to insert it when creating a new filter (or something along those lines). But even then I'm not sure it's doing it right (I'm quite unfamiliar with Inkscape's serializing code).
On 06/25/2009 05:52 AM, Jasper van de Gronde wrote:
In SVG there are two attributes that determine the color space used for operating on color values, these are color-interpolation and color-interpolation-filters (both can be set to either linearRGB or sRGB). For some reason that is completely beyond me the W3C decided to make the initial value sRGB for color-interpolation and linearRGB for color-interpolation-filters... As Inkscape has no support whatsoever for color-interpolation-filters pretty much any file which uses a filter looks wrong in Inkscape.
The last line here seriously worries me for a number of reasons. The most obvious of which is the basic implication that "pretty much any file which uses a filter looks wrong in Inkscape". With all of the work that has been put into filters for this release, it seems like a pretty big mistake to release with an issue that seems to loom so large.
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 can see the bug tracker post-release now, "Filters in inkscape are buggy/broken", and a bunch more like it. If people need to manually modify a file to get other renderers to create the same output (or to get our output to match others), it's fundamentally broken as far as the users are concerned (myself included).
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?
Will others please chime in on this?
Cheers, Josh
Thu, 25 Jun 2009 07:21:16 -0700 Josh Andler <scislac@...400...> kirjoitti:
I can see the bug tracker post-release now, "Filters in inkscape are buggy/broken", and a bunch more like it. If people need to manually modify a file to get other renderers to create the same output (or to get our output to match others), it's fundamentally broken as far as the users are concerned (myself included).
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?
As Bulia Byak just noted, Inkscape generates filters with color-interpolation-filters="sRGB" so no need to edit manually the files generated with 0.47.
An also, I don't want to belittle the problem, but this "key new feature" has been like this since 0.45 and it wasn't until lately that the problem was spotted. For real color-interpolation-filters support, I believe there exists a simple solution and a high-quality solution.
Simple: when needed, transform the filter input image to linearRGB and the output image back to sRGB. Colour quantization problems likely (read: banding)
High-Quality: make filters use 16 bit colours internally and do the simple solution. Would help with some other quality issues, too. This qould require a fair amount of work, so I'd be wary of pushing such update in this late in release cycle. (or we could create special versions of filters so they do sRGB->linearRGB->sRGB conversion internally -- lots of work and doesn't account for the possibility of linearRGB input images)
On Thu, Jun 25, 2009 at 6:56 PM, Niko Kiirala wrote:
High-Quality: make filters use 16 bit colours internally and do the simple solution. Would help with some other quality issues, too.
What would be really great is collecting all rendering quality fail cases (gradients, anyone? :)) and listing steps required to take to solve them.
Alexandre
On Thu, 2009-06-25 at 17:56 +0300, Niko Kiirala wrote:
An also, I don't want to belittle the problem, but this "key new feature" has been like this since 0.45 and it wasn't until lately that the problem was spotted.
I'm definitely aware of when we started to get filter support. :) And I can see why it would have been so difficult to spot in the past when we only had a couple primitives available.
For the record, by "key new feature", I'm referring to how "in your face" filters will be by comparison to previous releases (as well as how many more primitives are supported). I think that with having so many complex filters as easily available as we do now, if the problem hadn't have been noticed prior to release, it would not have taken long for a user to report it.
Either way, it sounds like it's being addressed (if it wasn't already)... so my concerns are definitely eased. Out of curiosity, when opening documents created outside of inkscape, do we insert the same attributes? or at least on a filter modification within inkscape?
Cheers, Josh
I tested most filters today with Batik, Firefox and Opera and the results are prettily similar now in those three apps. Thus seemingly all filters who extensively use Color matrix (to control blur, transparency, lightings display wrong in Inkscape.
Thus if I am not wrong and if this is the only problem could we imaginate some kind of translator which converts filters color matrix data of the already created filters after this problem will be solved ?
ivan
________________________________ De : Joshua A. Andler <scislac@...400...> À : Niko Kiirala <niko@...1267...> Cc : inkscape-devel@lists.sourceforge.net Envoyé le : Jeudi, 25 Juin 2009, 18h22mn 40s Objet : Re: [Inkscape-devel] turbulence filters
On Thu, 2009-06-25 at 17:56 +0300, Niko Kiirala wrote:
An also, I don't want to belittle the problem, but this "key new feature" has been like this since 0.45 and it wasn't until lately that the problem was spotted.
I'm definitely aware of when we started to get filter support. :) And I can see why it would have been so difficult to spot in the past when we only had a couple primitives available.
For the record, by "key new feature", I'm referring to how "in your face" filters will be by comparison to previous releases (as well as how many more primitives are supported). I think that with having so many complex filters as easily available as we do now, if the problem hadn't have been noticed prior to release, it would not have taken long for a user to report it.
Either way, it sounds like it's being addressed (if it wasn't already)... so my concerns are definitely eased. Out of curiosity, when opening documents created outside of inkscape, do we insert the same attributes? or at least on a filter modification within inkscape?
Cheers, Josh
------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Ivan Louette wrote:
I tested most filters today with Batik, Firefox and Opera and the results are prettily similar now in those three apps. Thus seemingly all filters who extensively use Color matrix (to control blur, transparency, lightings display wrong in Inkscape.
Thus if I am not wrong and if this is the only problem could we imaginate some kind of translator which converts filters color matrix data of the already created filters after this problem will be solved ?
No, this affects all filters and more (although filters are the most obvious as there the default case is different from what we do). In fact, the first time I noticed the effect was with the gaussian blur filter (I couldn't explain the difference between our rendering and Batik's rendering, until I found these properties and verified that they were indeed the cause).
Thanks. In fact my question is simple : will the coding changes to reach compatibility with other viewers and renderers affect the aspect of the already created works using filters, gradients and other features which causes problem ? Of course if doing some changes in filters numerical entries could help I would search actively how to do this, but if the problem stays deeper in Inkscape code I can't do anything.
________________________________ De : Jasper van de Gronde <th.v.d.gronde@...528...> À : Inkscape Devel List inkscape-devel@lists.sourceforge.net Envoyé le : Vendredi, 26 Juin 2009, 9h36mn 55s Objet : Re: [Inkscape-devel] Re : turbulence filters
Ivan Louette wrote:
I tested most filters today with Batik, Firefox and Opera and the results are prettily similar now in those three apps. Thus seemingly all filters who extensively use Color matrix (to control blur, transparency, lightings display wrong in Inkscape.
Thus if I am not wrong and if this is the only problem could we imaginate some kind of translator which converts filters color matrix data of the already created filters after this problem will be solved ?
No, this affects all filters and more (although filters are the most obvious as there the default case is different from what we do). In fact, the first time I noticed the effect was with the gaussian blur filter (I couldn't explain the difference between our rendering and Batik's rendering, until I found these properties and verified that they were indeed the cause).
------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
participants (9)
-
Alexandre Prokoudine -
bulia byak -
Ivan Louette -
Jasper van de Gronde -
jf barraud -
Josh Andler -
Joshua A. Andler -
Niko Kiirala -
Preben Soeberg