ellipse does not work in some cases - too many bezier coordinates / non-conforming drawing primitive definition

[helch]

In some cases drawing ellipse failes and reports weird errors:

Code: Select all

$ magick -size 2100x200 xc:white -draw "ellipse 1950,100 50,50 0,360" test.png # works as expected
$ magick -size 2100x200 xc:white -draw "ellipse 1990,100 50,50 0,360" test.png
magick: too many bezier coordinates `' @ error/draw.c/DrawImage/3050.
magick: non-conforming drawing primitive definition `ellipse' @ error/draw.c/DrawImage/3308.

Looks like a clear bug to me.
Seems to happen when coordinates are higher than some limit.

Code: Select all

$ magick --version
Version: ImageMagick 7.0.7-23 Q16 x86_64 20180218 http://www.imagemagick.org
Copyright: © 1999-2018 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules 
Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png rsvg tiff webp wmf x xml zlib

$ uname -a
Linux urban 4.14.15-1-default #1 SMP PREEMPT Thu Jan 25 13:26:16 UTC 2018 (5b3d0ce) x86_64 x86_64 x86_64 GNU/Linux

[fmw42]

I get the same error on IM 6.9.9.36 Q16 and 7.0.7.24 Q16 HDRI on Mac OSX Sierra. My guess is that the ellipse is too big and therefore needs too many bezier points.

This works:

Code: Select all

magick -size 1100x1100 xc:white -draw "ellipse 1000,1000 100,100 0,360" test.png

But this fails:

Code: Select all

magick -size 2100x2100 xc:white -draw "ellipse 2000,2000 100,100 0,360" test.png

[snibgo]

The problem command in the OP works fine with v7.0.3-5.

[magick]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

[helch]

That was quick!
Thanks a lot!

[Alexvb6]

Hi @magick,
That still occurs with IM 6.9.9.40 (Q16 x64 DLL HDRI) on Windows with big sizes...
Could you fix it for the 6.9 branch, too ?

[magick]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick sometime this weekend.

[Alexvb6]

Thanks @Magick !...but seems still buggy

However, I experienced the same issue in IM 7.0.7-28 (Q16 x64 DLL HDRI) on Windows with 24Gb of RAM, when processing big sizes.

WORKS :

Code: Select all

convert ^
-size 2203x2203 xc:white -fill black ^
-draw "roundrectangle 756,756 1398,1398 5,5" ^
c:\-RESULT-OK-notTooBig.miff

DOES NOT WORK :

Code: Select all

convert ^
-size 2203x2203 xc:white -fill black ^
-draw "roundrectangle 756,756 1448,1448 5,5" ^
c:\-RESULT-KO-tooBig.miff

It leads to the following error : :
convert: too many bezier coordinates `' @ error/draw.c/DrawImage/3055.
convert: non-conforming drawing primitive definition `roundrectangle' @ error/dr
aw.c/DrawImage/3401.


Interestingly, it does not seems related to the Width and Height of the roundrectangle (as I would have thought at first sight), that is actually 1448-756 = 692.
If I try to draw a roundrectangle of the same size, but "lower" on the canvas, it WORKS.. strange, what could it be due to ?

WORKS : (when drawn on a different position of the canvas)

Code: Select all

convert ^
-size 2203x2203 xc:white -fill black ^
-draw "roundrectangle 700,700 1392,1392 5,5" ^
c:\-RESULT-KO-tooBig.miff

I (sadly) think that should be fixed anew...

[magick]

Thanks for the use case. We use speculative memory allocation for allocating memory for drawing primitives. We have a flaw in the algorithm such that it aggressively over allocates the memory. We have a solution but cannot push the patch until this weekend.

[Alexvb6]

Hi Magick, I understand. This is sometimes very hard to predict how many pixels/memory/time will be required by a particular processing.
So I understand why you had chosen to use speculative allocation.

I was using this kind of thing in one of my programs, and I ended by replacing it completely, because it was (as you very aptly said it), too aggressive.
But infortunately, IM cannot avoid such an approach, as it is much more evoluated than my programs.

So, can we expect a patch in the next coming days ? Will you drop us just a little line in this thread ?
(This would avoid us to search through all the GitHub tickets)

Thanks for your prompt answer !