Image Filter broken for extrernal images

[Tavmjong Bah]

The Image filter using external images appears to be broken in 0.46+svn.

Method to recreate:

1. Draw rectangle.
2. Open Filters Dialog.
3. Add Image Filter
4. Select Source of Image from Image File.
5. Apply filter to rectangle.

Expected result: The image should fill the rectangle.
Actual result: No image appears.

This breaks my Displacement Map examples, see:

http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Filters-Pixel.html#Filters-DisplacementMap

[jazzynico (jazzynico)]

Confirmed on Ubuntu 9.04, rev. 21460.

[su_v (suv-lp)]

Mac OS X 10.5.7, MBP 2GB RAM, XQuartz 2.3.3.2, Inkscape 0.46+devel r 21420

Confirmed. When 'Source of Image' didn't produce a visible result, I clicked on 'Selected SVG Element'. This resulted in Inkscape freezing, the whole system almost unresponsive. I had to force quit inkscape-bin.

console msg:
** (inkscape-bin:3508): WARNING **: Inkscape only supports edgeMode="none" (and a filter uses a different one)!
** (inkscape-bin:3508): WARNING **: More than 32 iteration while updating document '(null)'
<repeated, several 1000 times>
** (inkscape-bin:3508): WARNING **: More than 32 iteration while updating document '(null)'
inkscape-bin(3508,0xa084d720) malloc: *** mmap(size=598016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
** (inkscape-bin:3508): WARNING **: FilterImage::render: not enough memory to create pixel buffer. Need 594516.
** (inkscape-bin:3508): WARNING **: FilterImage::render: Can not find: #rect12
** (inkscape-bin:3508): WARNING **: caught Glib::FileError in FilterImage::render 4
<last two msgs repeated, several 1000 times, until force quit>

[su_v (suv-lp)]

oops, just read bug #195320, that's an already confirmed crash.

[Tavmjong Bah (tavmjong-free)]

I think bug #195320 is different... that one results from using an object to create a filter that is applied to itself.

[su_v (suv-lp)]

sorry for being unclear - I meant the freeze I had when switching from 'Source of Image' to 'Selected SVG Element' seems to fit the description of bug #195320.
I can confirm that the image filter using external images doesn't work with Inkscape r21420 on Mac OS X 10.5.7.

[Tavmjong Bah (tavmjong-free)]

More info.

A simple image filter does not work if applied to one rectangle in a new document. It does work if applied to a rectangle in a second new Inkscape document (opened from the first document).

It also works on the first instance of a rectangle with the image filter applied if the image filter is applied to a second rectangle.

It also works on previously created documents (but not in the specific case of my Displacement map example where an image filter is used as an input for a Displacement map applied to an image).

This bug may be not directly responsible for breaking my Displacement map example. My example was broken by commit 20421:

r20421 | johanengelen | 2008-12-31 01:23:40 +0100 (Wed, 31 Dec 2008) | 1 line
Changed paths:
   M /inkscape/trunk/src/display/nr-filter-units.cpp
   M /inkscape/trunk/src/display/nr-filter-units.h
   M /inkscape/trunk/src/display/nr-filter.cpp

switch nr-filter to 2geom

This is all very confusing... it is likely that multiple bugs are at work.

[Johan Engelen (johanengelen)]

could someone attach a testfile for me please? thanks!

[Johan Engelen (johanengelen)]

or... adding a testfile to the testsuite in SVN would be even better!

[Tavmjong Bah (tavmjong-free)]

The problem seem to occur if the image is too large. I'll attach two SVG files that are identical except for the image size. The smaller image works but the larger one fails. The image file is ripple_100.png. It should be placed in the same directory as the SVG files.

[theAdib (theadib)]

attached a patch for 2geom that solves that issue.

Background: there is an epsilon that determines if two positions are (nearly) same. This is in 2geom defined as:
src/2geom/coord.h
const Coord EPSILON = 1e-5; //1e-18; <--- you see it has been experimented using higher precision
This is a correct simplification as nobody can detect such tiny differences. And speed will improve.
btw: libnr has a similar (but different parameter)
src/libnr/nr-values.h
#define NR_EPSILON 1e-18

Now, While calculating the inverse matrix of an given matrix for bounding box. There you need to divide each element of the matrix by the determinant of the matrix. Obvious that the determinant must not be 0(zero). So far fine. This 2geom-epsilon has been used to detect if the determinant is zero or not. This was the root of evil.
You can not compare graphical precision and numerical significance. Because what matters also is how big is the dividend. In our case determinant was 9.4679289999999989*10^-6.

so the patch does a hard coding epsilon = 1e-18 for mathematical matrix inversion only.

Adib.

[ScislaC (scislac)]

Committed in rev 22316. Thanks Adib, works like a charm!