Re: [Inkscape-devel] Fwd: [Inkscape-user] unable to export bitmaps
bulia byak wrote:
Thanks, indeed this is a bug. There's a limitation of the size of buffer that Inkscape can allocate, about 5000 by 5000 pixels. However this should not prevent your 7000 by 8000 file from exporting, because the export is done piecewise. So the problem is that the piecewise export fails when there's a blurred object, and looks like it tries to allocate the entire 7000 by 8000 buffer for the blurred ellipse. Instead it must only allocate the current strip plus approx the 2.5 times stdDeviation of the blur (that's the difference at which the blur fringe is virtually invisible). Jasper, can you please look into that, as you last changed that code? It would be nice to reduce the memory requirements of export with blur - without introducing artefacts, of course :)
I will definitely take a look, but it could take a while, as I'm currently quite busy. If someone else wants to take a look, my guess is that it's "simply" a matter of getting the boundingboxes right.
Basically what I did earlier was adjust the visible area (or something like that, I'd have to check) of the export area to the entire image. Usually this doesn't mean that the entire image is drawn for each stripe, but especially if you have objects spanning the entire image this probably could (I couldn't figure out exactly how this all worked, when I tried actually modifying the clipping code I got some results I didn't expect). What it should do instead is just extend the current stripe by the amount needed by any blurs in the current stripe.
One theory I had about why modifying the clipping code didn't work (for me) and why the current set up does work was that perhaps some calculations where creating bboxes with negative coordinates and that possibly something didn't like that much, since I suddenly got off set images and so on, but it's mostly guesswork.
BTW, if someone gets this fixed there is a good chance it would also fix bug 1643892.
On 3/5/07, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
Basically what I did earlier was adjust the visible area (or something like that, I'd have to check) of the export area to the entire image. Usually this doesn't mean that the entire image is drawn for each stripe, but especially if you have objects spanning the entire image this probably could (I couldn't figure out exactly how this all worked, when I tried actually modifying the clipping code I got some results I didn't expect).
Can it be that you assumed that you only need to add one stdDeviation to the margins? In fact it's too small and would definitely lead to step-like artifacts. In the blur margins in svg:filter width/height/x/y attributes we currently set 2.4*stdDeviation which is the distance at which the edge of the object contributes too weakly to be noticeable (about 1e-3). Previously it was 2*stdDeviation and that gave a slight cut edge to the blur that could be noticed if you look close enough (at about 1e-2).
What it should do instead is just extend the current stripe by the amount needed by any blurs in the current stripe.
Yes, definitely.
BTW, if someone gets this fixed there is a good chance it would also fix bug 1643892.
So I'll rename that bug and attach this sample file to it. Thanks!
bulia byak wrote:
On 3/5/07, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
Basically what I did earlier was adjust the visible area (or something like that, I'd have to check) of the export area to the entire image. Usually this doesn't mean that the entire image is drawn for each stripe, but especially if you have objects spanning the entire image this probably could (I couldn't figure out exactly how this all worked, when I tried actually modifying the clipping code I got some results I didn't expect).
Can it be that you assumed that you only need to add one stdDeviation to the margins? In fact it's too small and would definitely lead to step-like artifacts. In the blur margins in svg:filter width/height/x/y attributes we currently set 2.4*stdDeviation which is the distance at which the edge of the object contributes too weakly to be noticeable (about 1e-3). Previously it was 2*stdDeviation and that gave a slight cut edge to the blur that could be noticed if you look close enough (at about 1e-2).
Actually, 3*stdDeviation is used for this. But in any case, I didn't change that. The main problem with the old code, as far as I could see, is that it enlarged the bounding box and then clipped it again to the stripe being exported (which also agreed perfectly with the results).
(BTW, 3*stdDeviation is about right, the total area of the tails becomes smaller than 2^-9 around that point, which seems like a reasonably good criterion.)
What it should do instead is just extend the current stripe by the amount needed by any blurs in the current stripe.
Yes, definitely.
BTW, if someone gets this fixed there is a good chance it would also fix bug 1643892.
So I'll rename that bug and attach this sample file to it. Thanks!
Well, that might be a bit early, after all, I could be wrong.
participants (2)
-
bulia byak
-
Jasper van de Gronde