-draw circle creates offset circle?

[londoh]

Hi

very new to im, and so maybe I'm being dumb or pedantic or both...

very basic simple exercise: I want to draw a circle in the centre of an image.
I've seen the examples here:
http://imagemagick.org/Usage/draw/#circles

great, wonderful, looks easy.
Then I realised the method isnt exactly what I thought, but I got it after a bit
( viewtopic.php?f=1&t=8443 )

So I think I have the method figured, But...
if we look carefully at the image produced by the first example, the circle isnt actually centered in the image; Its slightly offset.

adjusting the example slightly will show the 'effect' more clearly:
convert -size 100x60 xc: -stroke Firebrick -fill tomato -strokewidth 2 \
-draw 'circle 50,30 50,59' circle_circle.gif

if I understand the method correctly, this should show a 1px margin top and bottom - but it doesnt.
There is a 1px margin at the top but the circle is touching the image edge at the bottom. If we make a 60x60 square it hits the right side as well as the bottom

So how to draw a circle EXACTLY in the middle of an image?

or have I missed the point? (or maybe I am being dumb or pedantic or both!)

l.

[londoh]

well ahumm, I just found this thread:
viewtopic.php?f=1&t=13345&p=45256

For Expert Usage The circle radius is a floating point operation, so you can draw a circle that is say half a pixel smaller that another circle. You may be able to use that to overlay 'stroked' circles of 1 pixel thickness so as to avoid any 'gaps'.

The location of the circles center (or any other coordinate in drawing operations) are also floating point, but are offset by 0.5 units, so that integer locations align with the center of the corresponding pixel.

That is a circle centered at 10,10 is actually centered in the middle of the 10th pixel from the top and left edges, and as such is really located at 10.5,10.5 in image coordinates. This however is generally only important when converting between drawing coordinates and the coordinates used for image distortions.

So... a circle centred at 10,10 is actually NOT centered anywhere near 10,10 at all.
Its center is at some apparently undocumented point, minus half of an x and half a y pixel away.
With all respect, It shouldnt really be necessary to be an expert to place a circle where you'd reasonably expect it to be! But you need to be to work out the offsets for complicated geometry

I post this for anybody else seeking to understand the arcane working of ImageMagick (and myself in a couple weeks when I forget)

to those that know, can I ask please: Is this definitely the answer to my original question???

[ah well - there goes another day]

[anthony]

The -draw command (and many others in IM) use what is calls "Pixel Coordinates". That is a coordinate of 10,10 is the center of the pixel at 10,10.

In this coordinate system 0,0 is the center of the top-left pixel, and w-1,h-1 is the center of the bottom-right corner. The actual edges are located at -0.5,-0.5 and w-0.5,h-0.5


The coordinate system you are thinking of and he one used by -distort is a "image Coordinate system". In this system the edges of the images are at 0,0 and w,h and the center is actually at w/2,h/2

To convert image coordinates to pixel coordinates add 0.5 to all values.

For more info see
Image Coordinates vs Pixel Coordinates
http://www.imagemagick.org/Usage/distor ... oordinates

[anthony]

More ImageMagick Draw Eccentricity

There are a few other points that you should note about draw commands.

The stroke-width works well as floating point values above a value of 1.0, but seems to break down for values less that 1.0. This is due to the implementation algorithm used and not simply because it is wrong.

Basically if you use a stroke-width of zero you could expect that no stroke color will be added. Instead you get a sort of beat pattern where stroke color is at full strength when the line goes through the actual 'center' of the pixel.

What really should happen is the amount of color added to a pixel should reflect the area of the line being drawn, and not the pixels distance from that line. As such what really should happen is that lines of zero width should add no color to the image, while lines of less than 1.0 thickness should never add the full amount of color. However that is NOT what happens

See the examples in... Drawing Lines, with StrokeWidth and Stroke
http://www.imagemagick.org/Usage/draw/#strokewidth

The other problem is that the fill color is not applied up to the center of the stroke line, but 1/2 pixel further. For example in the above example link, you will see that a line drawn with no stroke color (the default) will have a 1 pixel wide 'fill' color added. This is for historical reasons.

What that means is that if you draw two polygons that share an edge, that edge will overlap by 1 pixel as the polygon is 1/2 pixel bigger along all edges that it probably should be!

For example here I try use draw to divide an image into two halves.

Code: Select all

 convert -size 10x10 xc: -draw 'polygon 2,-1 7,10 10,10 10,-1'  left_side.png
 convert -size 10x10 xc: -draw 'polygon 2,-1 7,10 -1,10 -1,-1'  right_side.png

But if you compare these two images show that the two shapes actually overlap by 1 pixel.

The filled areas overlap even though the polygons are supposed to be exactly side-by-side.

STOP PRESS: The above has now been added to IM Usage, Drawing, Pixel Coordinates, and Draw Stroke and Fill Bounds. however it is as yet unformatted.
http://www.imagemagick.org/Usage/draw/#coordinates

[londoh]

Hi Anthony

thanks for the replies and link to the Image Coordinates vs Pixel Coordinates stuff. I hadnt found it yesterday and it clears up some of my incorrect assumptions.

Thank also for the heads up about the other gotchas - I hit the issues with adjacent polygons today!

I havent used IM for maybe 7 or 8 years when I had it auo generating thumbnails for a large site. I remembered being very impressed.
I came back to it hoping to do some stuff with overlays for maps - which need to be fairly accurate (or at least consistently wrong)
Initially IM looked exactly right for the job but just now I'm not sure if I can get my head around the intricacies in the time available.

l.

[anthony]

You can solve the adjacent polygon problem (if needed) by subtracting one polygon from the other to remove the overlap.

For proper templating of various areas, the templates should ADD together (assuming each area is white), so as generate a seamless join that produces exactly white. Templated pieces are actually 'blended' together which is equivelent to ADD. OVER is only correct when you are placing a piece 'over' an actual complete (fully-opaque) background. that is how the 'over' is mathematics is designed.

When testing such joins, multiply the two templates by say 50%, then add them together. If the result is a perfect 50% grey and no other color, you have a correct join.

I have a set of jigsaw puzzle pieces that fails this test, and I will have a real problem fixing the templates to make perfect joins.

See Aligning Two Masked Images
http://www.imagemagick.org/Usage/channels/#aligning

[londoh]

Hi Anthony

thanks for the extra info and links
I still cant get it right and time is against me, but hopefully its close enough that no-one will notice in this setting.

thanks for your help.

l.