Page 1 of 2

regression

Posted: 2009-09-10T01:30:48-07:00
by perl@nevcal.com
I wrote this as a question on the mailing list, but the more I pondered it, and after finding the old version to prove it is more likely a code change than a data problem, I decided to post this here as a bug.


convert.exe -density 150 -size 1159x1515 xc:white -compose multiply ( in.jpg -repage 1159x1515+0+0 ) -compose multiply -flatten ( in.jpg -repage 1159x1515+409+765 ) -compose multiply -flatten -compress zip out.tif

You can obtain in.jpg from http://nevcal.com/temporary/in.jpg

I can't figure out why the above command seems to double the size of in.jpg when creating out.tif

The density of in.jpg is 150, the density of the first image in the stack is 150.

I expect two full non-overlapping copies of in.jpg, but instead get double size fractional ones.

This worked in earlier versions of ImageMagick, but I upgraded it hoping to fix a different bug... didn't, and this got introduced.

Versions 6.5.5-7 and 6.5.5-8 exhibit this symptom. I don't think that 6.5.4 did, but I uninstalled it.

OK, I found an old 6.3.6 and it works the way I remembered. Probably other versions between also did, but I didn't save them, it seems.

So probably a code change, rather than a problem with the file.

Re: regression

Posted: 2009-09-10T09:39:44-07:00
by fmw42
convert.exe -density 150 -size 1159x1515 xc:white -compose multiply (
in.jpg -repage 1159x1515+0+0 ) -compose multiply -flatten ( in.jpg
-repage 1159x1515+409+765 ) -compose multiply -flatten -compress zip out.tif

I don't really follow this, but it appears that you have the order of images wrong and am missing a -composite or -flatten with the first -compose multiply.

The convert syntax is

convert background overlay -compose method -composite

Above you create a white image, but don't follow with the overlay image until after the -compose multiply and then there is no -composite or you have an out of place -compose multiply after the xc:white and then again after the in.jpg with a -compose multiply -flatten. When you have missed a composite command, you end up with multiple outputs rather than the two images being composited into one image.

see http://www.imagemagick.org/Usage/compose/#compose


Perhaps I am missing something here, but your command does not make sense to me. Perhaps it worked before because IM was more forgiving of errors and ignored the misplaced -compose multiply.

Perhaps you can explain functionally what you are trying to do and what each step corresponds to.

Also you say things are twice as big, but your image is 750x750 but you are usinig a 1159x1515 size white image. So the result will likely be that big.

Re: regression

Posted: 2009-09-10T12:07:47-07:00
by perl@nevcal.com
Thanks for the response, fmw42.

It is true that there is a variety of extraneous stuff in that command, I'm not an IM expert, I just cut-n-paste from examples, without full understanding. And so I appreciate the documentation reference you supplied.

However, -flatten seems to be able to use the -compose setting as well as -composite, so I think the lack of -composite is not a problem, and the extra -compose multiply shouldn't be a problem either.

So after reading a bit of the documentation you pointed at, and some others linked from there, I went on a trip of discovery... deleting stuff from the command to see if it would still work.

I deleted everything before the first (. The command then worked as I expected, but using other images that were not density 150 (like in.jpg is), then the density wouldn't be right, so I added -density back in at the end. Still works.

And yes, the 1159x1515 is more than twice as big as 750x750 like the in.jpg... I expect and obtain out.tif as that size. But still, I see nothing in the command that should double the size of in.jpg, which was also happening with the listed command, and is what I was complaining about... I don't understand how any of the now removed options should double the size of in.jpg.

So this shorter command works in 6.5.5-8:

convert.exe ( in.jpg -repage 1159x1515+0+0 ) ( in.jpg -repage 1159x1515+409+765 ) -compose multiply -flatten -density 150 -compress zip out.tif

Adding back in only the -size 1159x1515 option causes the problem:

convert.exe -size 1159x1515 ( in.jpg -repage 1159x1515+0+0 ) ( in.jpg -repage 1159x1515+409+765 ) -compose multiply -flatten -density 150 -compress zip out.tif

In the original command, I thought the -size option would apply to the xc:white generating the background image. Maybe it did, but maybe it also (correctly or incorrectly) applied to subsequent images. When I first saw this error, I wondered if somehow the -size was carrying over to later operators... but:

1) I couldn't find a way to turn off -size (is there a +size? Google didn't find it, but Google mostly ignores punctuation; the -size documentation didn't mention +size either)

2) I couldn't (and still can't) understand how applying -size 1159x1515 to a 750x750 image would result in the 750x750 image being doubled in size... neither 1159 nor 1515 is a two times 750. But in.jpg, as you see, has a center point defined (which is why I created it for this example), and in out.tif, that center point is exactly +750+750, whereas in in.jpg it was at +375+375. So that demonstrates that in.jpg was doubled, not scaled to the -size option.

So although my command had extraneous options in it, I still don't understand how those options could or should double the size of in.jpg

Can someone explain that to me?

Re: regression

Posted: 2009-09-10T12:13:22-07:00
by fmw42

Re: regression

Posted: 2009-09-10T14:36:28-07:00
by perl@nevcal.com
I'm not sure how those examples of flood fill and background help explain anything about why in.jpg gets doubled in size?

Re: regression

Posted: 2009-09-10T18:03:49-07:00
by fmw42
perl@nevcal.com wrote:I'm not sure how those examples of flood fill and background help explain anything about why in.jpg gets doubled in size?
It does not. It simply avoids erroneous IM commands. I was responding to the examples you sent me by private email. Unless you sent the wrong examples, it looked like you were trying to remove the black background on the logo-like image. You did not explain in your email to me as far as I could tell how the examples corresponded to your command line and to your problem. So I was suggesting what I thought was a more direct approach to removing the background (making it transparent) by referring you to another simple approach with examples of how that worked. I am still confused by your example above and thing the multiple images of a larger size are due to the missing composite and apparently (to me) erroneous ordering of images and commands in your command line. If you can explain your command line, perhaps some one can help, if you want to pursue the composite/flatten approach rather than using the floodfill approach. If so, please clarify further about your command line.

Re: regression

Posted: 2009-09-10T18:47:18-07:00
by perl@nevcal.com
Some confusion here... I didn't send you anything by private email, as far as I know. Maybe that was for a different thread?

Re: regression

Posted: 2009-09-10T20:31:28-07:00
by fmw42
I believe you are misusing -flatten. it uses -page and not -repage. and the -page comes before the images. see http://www.imagemagick.org/Usage/layers/#flatten

I think this might be what you want.

convert -size 1159x1515 xc:white \
-page +0+0 in.jpg \
-page +409+765 in.jpg -compose multiply -flatten \
-density 150 -compress zip out.tif

Re: regression

Posted: 2009-09-10T21:06:12-07:00
by perl@nevcal.com
OK, now I see that you are Fred Weinhaus from the imagemagick mailing list. And I did send you something there, which was copied privately.

I haven't used this discourse server forum until Anthony pointed me here because of my checkerboard filled rectangle bug, so I haven't learned who is who, with different names, etc.

And still, even if I'm misusing -flatten....

1) It worked in earlier versions of ImageMagick

2) It fails in the current versions.

That smacks of a bug, a regression, or an intentional change... but I don't know which.

And also, I see nothing that explains why in.jpg would get doubled in size, even if I am misusing -flatten.

Re: regression

Posted: 2009-09-10T21:28:41-07:00
by fmw42
I don't see the doubling. Also if it worked before, it is likely that IM was not trapping illegal arguments well and you just lucked out. I will defer to the IM folks on this.

I sent you my examples to see what you think is doubled as I don't see any doubling of the in.jpg in the composite flattened image. Your out.tif may be larger than you want by a factor of 2 if you are printing it because you used -density 150 which is twice the nominal of 72. Other than than, I don't see any problems with what was created from the commands that I used. The pixel sizes of the in.jpg areas in the flattened image are still 750x750 pixels.

convert -size 1159x1515 xc:white \
-page +0+0 in.jpg \
-page +409+765 in.jpg \
-compose multiply -flatten \
-density 150 -compress zip out.tif

or

convert -size 1159x1515 xc:white \
-page +0+0 in.jpg \
-page +409+765 in.jpg \
-compose multiply -flatten out2.tif

Perhaps I still misunderstand your issue. Can you provide an example where it works the way you want and where it does not.

Re: regression

Posted: 2009-09-10T21:34:45-07:00
by perl@nevcal.com
Looks like this is possibly another Windows-only bug?

My output file is different than the one Fred sent me. I hadn't thought to provide out.tif, but here is one from Fred's command, that is the same as the one produced by my original command, above.

http://nevcal.com/temporary/out.tif

Re: regression

Posted: 2009-09-10T21:37:49-07:00
by perl@nevcal.com
I wonder if there is a test suite that is run regularly on Windows, and if the Windows output is compared to the Unix output? Both issues I've had recently seem to be Windows only, and hopefully I'll remember in the future that the most helpful people on this forum and mailing list mostly run Unix, and not to expect their output to be the same as mine....

Re: regression

Posted: 2009-09-10T21:43:40-07:00
by fmw42
There should be no reason you are getting a different output if you are using the same version of IM and there are no other conflicts. How did you install? From binary or source. If from binary did you see at http://www.imagemagick.org/script/binar ... hp#windows

"If you have any problems, install the Visual C++ 2008 Redistributable Package (x86) or Visual C++ 2008 Redistributable Package (x64). 64-bit Windows requires both packages (x86 & x64)."

if from source see
http://www.imagemagick.org/script/insta ... hp#windows
http://www.imagemagick.org/script/advan ... lation.php


also be sure you don't have multiple versions installed that are in conflict

Perhaps some windows user can verify my command line examples above?

Re: regression

Posted: 2009-09-10T22:00:03-07:00
by fmw42
Looks like this is possibly another Windows-only bug?

My output file is different than the one Fred sent me. I hadn't thought to provide out.tif, but here is one from Fred's command, that is the same as the one produced by my original command, above.

http://nevcal.com/temporary/out.tif
This is not the file I sent.

Here is one I made.

convert -size 1159x1515 xc:white \
-page +0+0 in.jpg \
-page +409+765 in.jpg \
-compose multiply -flatten \
-density 150 -compress zip out.tif

http://www.fmwconcepts.com/misc_tests/out.tif

So is this what you want or what you think is wrong?

Re: regression

Posted: 2009-09-10T23:20:21-07:00
by perl@nevcal.com
The file is the one I generated from the command you provided, which is the same as the one I generated from the command I first provided, which shows the bug.

The output files you sent me, and the file you posted here, are what I would consider to be the correct output of the command. It is what my command used to generate with older versions of ImageMagick, and it is what your command produces for you, and your version of ImageMagick.

I installed from Windows binaries, at the location you mentioned.