turbulence filters

[jf barraud]

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.

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[jf barraud]

oops, here is the attached file...



------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Preben Soeberg]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...]
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.

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[jf barraud]

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.

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jasper van de Gronde]

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.


------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[bulia byak]

On Thu, Jun 25, 2009 at 9:52 AM, Jasper van de
Gronde<th.v.d.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.

Haven't we decided to insert this automatically if a filter is used?

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Josh Andler]

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

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Niko Kiirala]

Thu, 25 Jun 2009 07:21:16 -0700
Josh Andler <scislac@...> 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)

--
Niko Kiirala
niko@...

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jasper van de Gronde]

bulia byak wrote:
> On Thu, Jun 25, 2009 at 9:52 AM, Jasper van de
> Gronde<th.v.d.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.
>
> 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).

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alexandre Prokoudine]

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

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jasper van de Gronde]

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.

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Josh Andler]

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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Ivan Louette]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...>
À : Niko Kiirala <niko@...>
Cc : inkscape-devel@...
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jasper van de Gronde]

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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Ivan Louette]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...>
À : Inkscape Devel List <inkscape-devel@...>
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Ivan Louette]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Now to be more precise again : admitting I work with the future corrected version of Inkscape, I select an object or a picture in my document, I click on a filter in one of the lists in a Filters submenu while the filters.svg file in Inkscape directory is the same than today. Will Inkscape new version add to the filter the instructions needed to display the filter like it displays in Inkscape today ?

Sorry, I am a visual person and not a coder (if I could I would... but at the moment no time to go further in this direction I am afraid) and I try to understand the most clearly I can because I must evaluate which kind and amount of work will be needed to adapt the results of my work if necessary.

Thanks for your patience and regards,
ivan

---

De : Jasper van de Gronde <th.v.d.gronde@...>
À : Ivan Louette <ivan_louette@...>
Envoyé le : Vendredi, 26 Juin 2009, 13h49mn 18s
Objet : Re: Re : [Inkscape-devel] Re : turbulence filters

Most definitely! Any existing work using filters will be rendered differently using other viewers or newer versions of Inkscape. How visible the difference is depends on the type of filter. And since the transfer function is highly non-linear there is really no other fix than adding the color-interpolation-filters="sRGB" property to the affected filters (which will make them look the same in other viewers as in Inkscape).

Ivan Louette wrote:
> 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.

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jasper van de Gronde]

I'm not entirely sure I fully understand the scenario, but it sounds
about right. Except that as far as I've understood no one has committed
to actually coding something like this. (And I definitely do not have
the time to do this until about December or something.)

Ivan Louette wrote:

> Now to be more precise again : admitting I work with the future
> corrected version of Inkscape, I select an object or a picture in my
> document, I click on a filter in one of the lists in a Filters submenu
> while the filters.svg file in Inkscape directory is the same than today.
> Will Inkscape new version add to the filter the instructions needed to
> display the filter like it displays in Inkscape today ?
>
> Sorry, I am a visual person and not a coder (if I could I would... but
> at the moment no time to go further in this direction I am afraid) and I
> try to understand the most clearly I can because I must evaluate which
> kind and amount of work will be needed to adapt the results of my work
> if necessary.

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Ivan Louette]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks a lot for your reply !

However, don't be worry if that gives me some extra work to adjust filters settings in the future. Designing these filters was already a fantastic creative discovery.

ivan

---

De : Jasper van de Gronde <th.v.d.gronde@...>
À : Inkscape-devel@...
Envoyé le : Mardi, 30 Juin 2009, 12h18mn 03s
Objet : Re: [Inkscape-devel] Re : Re : Re : turbulence filters

I'm not entirely sure I fully understand the scenario, but it sounds
about right. Except that as far as I've understood no one has committed
to actually coding something like this. (And I definitely do not have
the time to do this until about December or something.)

Ivan Louette wrote:

> Now to be more precise again : admitting I work with the future
> corrected version of Inkscape, I select an object or a picture in my
> document, I click on a filter in one of the lists in a Filters submenu
> while the filters.svg file in Inkscape directory is the same than today.
> Will Inkscape new version add to the filter the instructions needed to
> display the filter like it displays in Inkscape today ?
>
> Sorry, I am a visual person and not a coder (if I could I would... but
> at the moment no time to go further in this direction I am afraid) and I
> try to understand the most clearly I can because I must evaluate which
> kind and amount of work will be needed to adapt the results of my work
> if necessary.

------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel