Legacy ImageMagick Discussions Archive

As of 6.3.1-4, there is some funny bidness along the Border.

Start with our sweet 'rose:' ...

#!/usr/bin/perl -- 
use Image::Magick;
$image = new Image::Magick;
$image->Read("rose:");

... add a border of width 4.

Code: Select all

$image1 = $image->Clone();
$image1->Border(width=>4, color=>'blue'); 
$image1->Write('bordertest-w4.png');

Whoa! The above won't do. I just meant a border of constant thickness 4. Like so, using the 'geometry' version:

Code: Select all

$image2 = $image->Clone();
$image2->Border(geometry => '4x', color=>'blue'); 
$image2->Write('bordertest-4x.png');

Yes, exactly. Now let's try the experiment with 'height'.

Code: Select all

$image3 = $image->Clone();
$image3->Border(height=>8, fill=>'green'); 
$image3->Write('bordertest-h8.png');

Not good. So we'll try 'geometry again'.

Code: Select all

$image4 = $image->Clone();
$image4->Border(geometry => 'x8', color=>'green'); 
$image4->Write('bordertest-x8.png');

What the ...? Well, a zero width border when no width is given does make sense. I approve, but these two 'geometry' versions do not seem consistent.

On the other hand, these are fine and identical:

Code: Select all

$image5 = $image->Clone();
$image5->Border(width=>4, height=>8, color=>'red'); 
$image5->Write('bordertest-w4h8.png');

$image6 = $image->Clone();
$image6->Border(geometry => '4x8', color=>'red'); 
$image6->Write('bordertest-4x8.png');

Here's the lot:

http://sun.cs.lsus.edu/~rmabry/magick/border/

Also, the 'fill' option is mentioned in the PerlMagick doc, but 'color' is presently synonymous - should that be mentioned? What about 'bordercolor' to be consistent with the commandline version? But then there are 'border' and 'borderwidth' that could also be given their commandline meanings...

I presume that the super-elongated versions are not desired but that the answer is to "always specify what you want". Fair enough. And the difference between the 'geometry' versions of width and height, which are like the command line -border option, are not going to change, as 'width' is probably meant to be synonymous with 'borderwidth' in this context. Okay, okay.

On a slightly different front, shouldn't one of the following give a red border? I'm trying -bordercolor, -fill, -background, but all give a border of correct dimensions but a gray color, the background default color.

Code: Select all

convert rose: -border 4x8 -bordercolor red bordertest-cmd-b4x8.png

Code: Select all

convert rose: -border 4x8 -fill red bordertest-cmd-b4x8.png

Code: Select all

convert rose: -border 4x8 -background red bordertest-cmd-b4x8.png

This is Border-ing on tedious, I know... But I was bored-er than usual this evening.

Rick

Your problem has to do with default values. Try

$image1->Border(width=>4, height=>0, color=>'blue');

and you get the expected results. PerlMagick defaults the width and height to the image columns and rows. You can override the default values or we can patch PerlMagick to default the width/height to 0.

magick wrote: Your problem has to do with default values. Try
$image1->Border(width=>4, height=>0, color=>'blue');
and you get the expected results.

Yes, I noted that above (the red borders).

PerlMagick defaults the width and height to the image columns and rows.

"Defaults" in that the geometry field is pre-filled with the width and height, yes. But it doesn't seem deliberately so. Would that be behavior anyone would want?

This is not a problem for me, but I wondered if it should behave differently. As is often the case, if you specify you get what you want.

You can override the default values or we can patch PerlMagick to default the width/height to 0.

Thanks, but don't do it only on my account! To have PerlMagick do something different from the commandline versions seems confusing. I personally think that the default of zero is indeed best, though, when only one of 'width' and 'height' is specified in PerlMagick or when -geometry is given only one vale, as with 8x or x4, as above. I like that "... -border 4 ..." sets the width and height both equal to 4. I think it should be represented in PerlMagick (border => 4), as well.

Hey, when did "-borderwidth" disappear? (I'm using 6.3.1-5 now.) Good riddance, I suppose, as there is no -borderheight either.

Regarding the commandline examples at the end of my long post above, I see that reversing the order of the arguments gives the right result, but this seems illogical to me:

Works:

Code: Select all

convert rose: -bordercolor red -border 4x8 bordertest-cmd-b4x8.png

Doesn't work:

Code: Select all

convert rose: -border 4x8  -bordercolor red bordertest-cmd-b4x8.png

Regardless, one last thing: I'd add (bordercolor => ...) as an option to the PerlMagick version, synonymous with its present "fill" and "color".

Note that -border 4 is that same as -border 4x but different to -border 4x0

Basically if the height is not given the width is copied to the height so that the first works as you intended. If it is given (eg 4x0) then that is what is done. This is not done for the reverse -border x4, and width is taken to be just 0.

As for your last examples.. It is perfectly locigal.

Code: Select all

convert rose: -border 4x8  -bordercolor red bordertest-cmd-b4x8.png

Under IM version 5 it may have worked, but then it may not have. IM version 6 however does things in command line option order (with a little tweek for older IMv5 scripts)
For details see IM exampels, Basics.
http://www.cit.gu.edu.au/~anthony/graph ... k6/basics/

As such what is does do is correct. The -bordercolor is not defined at the time the -border operator is processed, so the default border color is used (a light grey).

The later define is just not used as no operator that uses bordercolor followes.
However if PNG format did have a bordercolor meta-data, then of course 'red' would be saved as the border color for the image

anthony wrote: Note that -border 4 is that same as -border 4x but different to -border 4x0

Yup. But in my needling opinion, -border 4 should be the same as -border 4x4, while -border 4x should be the same as -border 4x0. Either of these is logical:

1) 4x = x4 = 4 = 4x4
2) 4x = 4x0, x4 = 0x4, 4 = 4x4

though I prefer the latter.

As for your last examples.. It is perfectly locigal.
Code: Select all
convert rose: -border 4x8  -bordercolor red bordertest-cmd-b4x8.png
[...]The -bordercolor is not defined at the time the -border operator is processed, so the default border color is used (a light grey).

I'll argue the reverse is more logical, that it makes no sense to have a border color when there is no border. In the above example, saying there first a border of 4x8 should then allow for the default border color to be used even if no color is specified. The way it is written is most logical: there is a border of size 4x8 and here is its color. This logically equivalent to such things as

Code: Select all

convert -size 40x80 xc:red ...

while the following makes less sense (and actually produces a 1x1 image):

Code: Select all

convert xc:red -size 40x80 ....

Rick

But in my needling opinion, -border 4 should be the same as -border 4x4, while -border 4x should be the same as -border 4x0.

However the test is for if the second number is present of not. Not if the 'x' is present or not.

remember the 'geometry' argument is a very standard argument, and can allow any of these formats...
1
1x2
x2
+3+4
1+3+4
1x2+3+4
1,2,3,4
1/2/3/4
Plus if the symbols % ! @ appears in the result.

Any of these are actually allowed as a 'geometry' specification!
It is already extrememly versitile, and is difficult to make even more so.

Some functions, such as the new -ordered-dither on the other hand need special handling just for that function. Specifically string,1,2,3,... EG a string and up to five positive intergers, with any non-number as a seperator after the string. Not only that what the numbers refer to depends on the current -channel setting making the matching of the right number to the right channel very difficult indeed.

At least with -affine (and the comming -perspective) matrix inputs they have a fixed number of numbers (positive and negative).

OK enough ranting....

You are basically some up to the difference between a setting and a operator. -border is an operator, that is applied. -bordercolor is a setting that could be used by a lot of different operators.

What you say may be true, but any other way and we go back to the bad old days of IM v5 where what operation and setting and what order they work in is completely undefined. At least this way if something goes wrong you can at least know WHY something has gone wrong.

I would like to see all command line options specifically marked as 'setting' or 'operator' but currently this is not done as it takes someone to actually sit down and go though them.

Currenly only one option is neither setting or operator, -geometry which is a setting for "composite" and "montage" but a special resize operator and position setting for "convert" -composite, the only operator in comvert that truely makes use of a gravity defined 'position' setting. A -geometry gravity effected position is why a virtual canvas -page offset (no gravity effected) is not used for Alpha Composition.

All this is of course due to attempts to be as backward compatable as posible. while at the same time pushing -resize for actual image resizing.

It was all this that caused the IM v5 to IM v6 major version change, as was hashed out in the beta testing phase of version 6.0.0, when I first started doing IM examples, an attempted to solve the command line mess of IM v5. Christy was very good to do the overhaul needed to make things 'fully defined', even if it is not 'logical' in your view.

Maybe you can explain why these commands don't produce the expected output, the rose image with a size of 84x46 (it's originally 70x46).

In ImageMagick 6.2.5:

Code: Select all

$ convert rose: -border 10%x0% test-a.jpg
$ identify test-a.jpg

Produces:

Code: Select all

test-a.jpg JPEG 72x46 DirectClass 4kb

While on ImageMagick 6.0.7, this produces:

Code: Select all

test-b.jpg JPEG 84x46 PseudoClass 256c 177 0.000u 0:01

Which also happens to be a pure black image.

But on ImageMagick 5.5.7, the results are:

Code: Select all

test-c.jpg JPEG 84x46+0+0 DirectClass 8-bit 1.3k 0.010u 0:01

This is exactly what I expect...

There are other odd problems like this with border (and frame) which did not occur in 5.x.

I have yet to figure out a good work around, too (short of going back to the old version).

In ImageMagick 6.2.5:
Code: Select all
$ convert rose: -border 10%x0% test-a.jpg
$ identify test-a.jpg

I tryied this in the latest beta, and had a simular result.

the image is the same size as the original but with a single pixel border added to left and right edges. As such I'd say the image is not right.
Looks like you have found a definate bug.

Percentage handles is often needing special treatment, and it is one part I have not exampled in IM examples, do obviously it is not tested regularly to somewhere where someone to note the mistake.

Adding this to the IM Examples 'bugs testing page', and will note it to cristy.

The percentage geometry bug is fixed in ImageMagick 6.3.1-7 Beta. An updated distribution will be available sometime tommorrow.

Verified and IM example added to border operator examples.

Thank you for the quick response and verification that I wasn't doing something wrong.

-lb

Legacy ImageMagick Discussions Archive

Bordering on weird

Bordering on weird