Memory hole when rendering certain vectors? [SOLVED]

[Cobra_Fast]

When I'm trying to generate a roughly 300x300 render of a few specific vector files (so far SVG and EPS), after calling gs (which is GhostScript to decode the vector data, i believe), ImageMagick is processing the data and memory usage goes astronomically.
So far I've been able to record as much as 12GB memory usage before I had to abort the process so it wouldn't kill the system.
I havn't yet figured out what exactly causes this behaviour.

The command line I'm using:

Code: Select all

convert source.svg -filter triangle +antialias -colorspace rgb -density <longest side of target resolution * 2> -flatten -scale <target resolution> -sharpen 2x1 -geometry center watermark.png -compose dissolve -define compose:args=66,0 -composite result.jpg

The forum unfortunately doesn't allow me to post an attachment, so for now I'm unable to provide the problematic source file.

Versions

Code: Select all

ImageMagick 6.7.8-2 2012-07-10 Q16 http://www.imagemagick.org
GhostScript: 8.71

Is this behaviour normal, have I found an actual bug or am I doing something wrong?

[snibgo]

Your IM and GS versions are both old. An upgrade may solve the problem.

source.svg is probably text, so you can paste it here. Put it between [ code ] and [ / code ] to preserve the formatting.

[Cobra_Fast]

Your IM and GS versions are both old. An upgrade may solve the problem.

Thanks, I've updated IM to

Code: Select all

ImageMagick 6.8.3-9 2013-03-11 Q16 http://www.imagemagick.org

but the described behaviour persists (aborted at 8GB this time). GS is provided by my package maintainer (debian stable), so I have still to try to update that.
Watching the I/O-throughput of the GS call I found out that GS produces a 2.8GB large temporary file to return to IM. Not sure if that's relevant.

source.svg is probably text, so you can paste it here. Put it between [ code ] and [ / code ] to preserve the formatting.

I'll try that, here it goes:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>

<svg version="1.2" baseProfile="tiny" viewBox="0 0 21000 29700" preserveAspectRatio="xMidYMid" fill-rule="evenodd" clip-path="url(#presentation_clip_path)" stroke-width="28.222" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0" xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" xml:space="preserve">
 <defs>
  <clipPath id="presentation_clip_path" clipPathUnits="userSpaceOnUse">
   <rect x="0" y="0" width="21000" height="29700"/>
  </clipPath>
 </defs>
 <g id="id2" class="Master_Slide" clip-path="url(#presentation_clip_path)">
  <g id="bg-id2" visibility="visible" class="Background">
   <rect fill="none" stroke="none" x="0" y="0" width="21000" height="29700"/>
  </g>
  <g id="bo-id2" visibility="visible" class="BackgroundObjects"/>
 </g>
 <g id="id1" class="Slide" visibility="visible" clip-path="url(#presentation_clip_path)">
  <g class="com.sun.star.drawing.OpenFreeHandShape">
   <g>
    <path fill="none" stroke="rgb(0,0,0)" d="M 4300,3733 C 3758,3710 3230,3991 2930,4489 2652,4951 2227,5352 2126,5906 2035,6406 2130,6953 2552,7324 2984,7704 3398,8154 3969,8316 4512,8470 5075,8482 5623,8410 6160,8339 6791,8174 7040,7607 7270,7083 6949,6477 6568,6142 6217,5833 5519,5748 5245,6426 5027,6966 4531,7368 4394,7985 4262,8579 4611,8990 4867,9402 5186,9915 5852,10134 6473,10111 7047,10090 7623,10041 8174,9875 8741,9704 9314,9503 9780,9119 10302,8689 10472,7967 10206,7465 9928,6940 8984,7084 8505,7513 8026,7942 7511,8351 7182,8930 6924,9383 6755,9901 6851,10395 6971,11014 7514,11457 8032,11812 8549,12167 9144,12351 9733,12521 10233,12665 10741,12650 11245,12615 11896,12570 12499,12161 12899,11670 13220,11276 13210,10658 12993,10158 12758,9617 12198,9144 11623,9261 11040,9380 10874,10063 10820,10584 10762,11144 10576,11717 10820,12284 11071,12867 11636,13180 12095,13560 12660,14028 13386,14197 13938,14694 14428,15135 15131,15073 15686,14883 16289,14677 16790,14076 16867,13418 16935,12838 16697,12243 16300,11859 15930,11501 15426,10897 14836,11151 14239,11408 13807,11993 13607,12615 13425,13181 13398,13778 13324,14363 13254,14916 13447,15439 13560,15970 13707,16660 14202,17236 14741,17671 15306,18127 15984,18489 16726,18568 L 17198,18663 17387,18710"/>
   </g>
  </g>
  <g class="com.sun.star.drawing.OpenFreeHandShape">
   <g>
    <path fill="none" stroke="rgb(0,0,0)" d="M 2410,14363 C 2740,14908 3243,15301 3733,15686 4280,16116 4801,16569 5292,17056 L 5764,17529 6001,17718"/>
   </g>
  </g>
  <g class="com.sun.star.drawing.OpenFreeHandShape">
   <g>
    <path fill="none" stroke="rgb(0,0,0)" d="M 2788,17718 C 2843,17125 3279,16671 3686,16300 4192,15839 4618,15312 5103,14836 L 5575,14363 6001,13891 6095,13796"/>
   </g>
  </g>
  <g class="com.sun.star.drawing.OpenFreeHandShape">
   <g>
    <path fill="none" stroke="rgb(0,0,0)" d="M 7324,19183 C 7333,18591 7538,18025 7749,17482 7956,16948 7966,16342 8221,15828 8355,15558 8280,14072 8599,15356 8734,15899 8487,16350 8646,16962 8884,17879 9546,17163 9780,16773 9902,16570 10606,14944 10206,16348 10055,16877 9910,17406 9828,17954 9750,18472 9615,18986 9591,19513 L 9686,19891"/>
   </g>
  </g>
 </g>
</svg>

This particular SVG has been exported from LibreOffice Draw (LibreOffice 3.5.7.2 / Build-ID: 350m1(Build:2)) and triggers the described behaviour.

[snibgo]

When I do ...

Code: Select all

convert source.svg s.png

... I get "Unable to extend cache. No space left on device."

The SVG defines elements width="21000" height="29700". This would be 623.7 million pixels, which would take about 6 GB of memory, which my poor little laptop can't cope with.

Maybe, possibly, some large-image tricks in IM might solve the problem. Or perhaps you can regenerate the SVG at more modest dimensions.

[Cobra_Fast]

So just to get this right; IM tries to render the vector in full size to then shrink it to the desired resolution?
That doesn't sound very efficient to me... Can't I tell IM to directly render it to the desired resolution?

[snibgo]

The SVG can be tweaked so the units there don't correspond 1:1 to pixels. I forget how; see the SVG docs for details.

After seeing another thread viewtopic.php?f=3&t=22951 , I tried ...

Code: Select all

convert -define registry:temporary-path=h:\temp -debug cache source.svg s.png

... where h: is a Windows disk with 1 TB free. This seems to work, but is still running 30 minutes after I started it.

[snibgo]

An hour later, my "convert" is still thrashing away. [Edit: it finished after 90 minutes, successfully creating a 21000x29700 png.]

The job is better handled by Inkscape. Eg:

Code: Select all

inkscape.exe -f source.svg -d 2 -e s.png -y 1

The "d" parameter gives the correspondence between units and pixels. Use "90" for one unit to one pixel. Here, "2" gives a smaller output.

[magick]

Here's an easy fix. Add -density 5 to your command line, before the SVG image filename. That will create a reasonably sized result.

[Cobra_Fast]

Here's an easy fix. Add -density 5 to your command line, before the SVG image filename. That will create a reasonably sized result.

Thanks a ton, 5 created blurry results (because im using -scale) but 90 (as pointed out by snibgo) seems to produce good results while being gentle on memory.