strokeDashArray BUG?

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
tgiles

strokeDashArray BUG?

Post by tgiles »

Libary: Magick++ (C++ API) V6.2.6
System/Kernel:
SuSE_9.1_ia64
Linux dvlra1a 2.6.5-7.252.1-rtgfx #1 SMP Mon Mar 20 18:27:59 PST 2006 ia64 ia64 ia64 GNU/Linux
-------------------------------------------------

I have an app I've written that is drawing grid lines (major/minor) using different dash patterns. Every so often (I cannot figure out any repeatable pattern), I get strange results when drawing these grid lines, with lines being drawn from the top left corner of the image across the image diagonally. I've finally come up with a code snippet that reliable reproduces this bug on my system... any help in fixing this would be much appreciated... Thanks! I can send output images illustrating this bug if desired - just let me know. -Todd

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

Code: Select all

#include <Magick++.h>

using namespace Magick;

typedef struct { 
  char color[64];
  int  width;
  float opacity;
  double dash[10];
} LineDescription;

static Image * _pImg = NULL;

static void SetLineStyle(LineDescription & line)
{
  Color clear(0,0,0,TransparentOpacity);
  _pImg->fillColor(clear);
  Color line_color(line.color);
  line_color.alpha(1.0 - line.opacity);
  _pImg->strokeColor(line_color);
  _pImg->strokeWidth(line.width);
  line.dash[0] <= 0.0 ? 
	_pImg->strokeDashArray(NULL) :
	_pImg->strokeDashArray(line.dash);
}

int main(void)
{
  _pImg = new Image(Geometry(640,640),"black");

  system("rm test.jpg");

  int major_gap = 50;
  int minor_gap = 10;

  LineDescription major;
  strncpy(major.color,"white",64);
  major.width = 1;
  major.opacity = 0.6;
  major.dash[0] = 0.5;
  major.dash[1] = 2.5;
  major.dash[2] = 0.0;

  LineDescription minor;
  strncpy(minor.color,"gray",64);
  minor.width = 1;
  minor.opacity = 0.4;
  minor.dash[0] = 0.5;
  minor.dash[1] = 1.5;
  minor.dash[2] = 0.0;

  SetLineStyle(minor);

  for(int col = minor_gap; col < 640; col += minor_gap)
	{
	  _pImg->draw(DrawableLine(col, 0, col, 640));
	}

  for(int row = minor_gap; row < 640; row += minor_gap)
	{
	  _pImg->draw(DrawableLine(0, row, 640, row));
	}


  SetLineStyle(major);

  for(int col = major_gap; col < 640; col += major_gap)
	{
	  _pImg->draw(DrawableLine(col, 0, col, 640));
	}

  for(int row = major_gap; row < 640; row += major_gap)
	{
	  _pImg->draw(DrawableLine(0, row, 640, row));
	}

  _pImg->write("test.jpg");

  system("display test.jpg &");

  return 0;
}
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: strokeDashArray BUG?

Post by magick »

We are aware there is a bug in rendering dashed strokes. There is currently no ETA when the problem will be fixed.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: strokeDashArray BUG?

Post by anthony »

You can see more details of this bug at the bottom of the 'known minor bugs' page...
http://www.imagemagick.org/Usage/bugs/testing/
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
tgiles

Re: strokeDashArray BUG?

Post by tgiles »

I'm not sure this is the same bug... I've now been able to reproduce this with just the convert command (i.e. not using the C++ API). It appears that it may be related to drawing lines starting from column 0 (or row 0). For details (including pictures), please take a look at my blog post today:

http://todd.gileszone.com/2007/06/13/im ... array-bug/

Thanks,

-Todd
tgiles

Re: strokeDashArray BUG?

Post by tgiles »

One more data point --- I have been able to reproduce other strange behavior with the dashed lines, but not as reliably as the tests I've included here (e.g. --- not starting at row/col 0 and still able to have diagonal lines, along with various parts of the image getting shaded). Hopefully the info I've passed along is helpful to whomever ends up debugging / fixing these issues with dashed lines.

Thanks,

-Todd
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: strokeDashArray BUG?

Post by anthony »

I too have seen this bug, but have never been about to reliably reproduce it in a such a simple example. I have only seen in it very complex examples, and as soon as I try to simplify it the problem disappears.

I have also seen cases where a find 'half dash' was just not drawn as the end of the line drawing sequence was reached. I believe that was fixed, and that may have introduced this 'new' bug.

Of course now there is an example, the bug can be fixed. Chrisy?

I noticed your dashed arrays use floating point numbers. Was this to overcome the bug I mentioned above?

That bug appeared to be a bounds error, but may be a round off error due to float to interger (pixel coordinate) errors. Or it could be the dashes are being draw with round endcaps that are extending the 'on' part of the dashed line one more pixel than it should. That is the dashed line may need to shorten by .5 to include accound for endcaps.

It may be that SVG does the same thing (is it documented?) in which can my bug is not an error, but a misinterpretation of what dasharray represents at the pixel level.

Comments?
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
tgiles

Re: strokeDashArray BUG?

Post by tgiles »

anthony wrote:I noticed your dashed arrays use floating point numbers. Was this to overcome the bug I mentioned above?
Yes --- I used floating point numbers to get the spacing I desired... for example, to get a single pixel seperated by some arbitrary space, use 0.5 for the first "on" portion of the dash array, then some number for the spacing of the single pixels. I noticed that using an array of 1 3 didn't give me one pixel followed by 3 "off" - but 0.5 3.5 effectively did... so I started subtracting 0.5 from the "on" and adding it to the "off" to get the desired affect.
Post Reply