On approximately 9/10/2009 10:55 PM, came the following characters from the keyboard of Anthony Thyssen: > On Thu, 10 Sep 2009 19:09:59 -0700 > Glenn Linderman <[email protected]> wrote: > > | Thanks for your response, Fred... I'll try to explain, as you suggest. > | I'm sure I have something wrong, but then again, it seems IM is doing > | something wrong too. Maybe they are related, or maybe not. > | > | On approximately 9/10/2009 9:31 AM, came the following characters from > | the keyboard of Fred Weinhaus: > | > 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 > | > > | > Below 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 image 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. > | > > | > | Below, I will carve up my command, and explain what I think, which may > | not be correct. You can correct me. > | > | > 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. > | > > | > | Yes, I expect the result to be 1159x1515. But I don't expect that > | in.jpg, which is 750x750, will get doubled in size, and consume > | 1500x1500, in each case, and be therefore cropped. Both copies of > | in.jpg should fit, non-overlapping, within 1159x1515, at the positions I > | specified. I think one should be in the upper left corner, and one in > | the lower right corner. > | > | >> 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 > | > | Here's my command, split into pieces, with explanations after the # > | > | convert.exe # run the program > | -density 150 -size 1159x1515 xc:white # make a white canvas of the final > size > | -compose multiply # probably not needed > | ( in.jpg -repage 1159x1515+0+0 ) -compose multiply -flatten # in.jpg to > upper left > | ( in.jpg -repage 1159x1515+409+765 ) -compose multiply -flatten # in.jpg > bottom right > | -compress zip out.tif # save result > | > You method actually has 4 image compositions, and three canvas creations! > It also losses whatever metadata you had in the image (effectivally > stripping it). This may be the cause of your problems! > > In reality you only want 2 image compositions and one canvas creation! > > Try this instead... > > convert.exe \ > -page +0+0 in.jpg \ > -page +409+765 in.jpg \ > -repage 1159x1515 -background white -compose multiply -flatten \ > -compress zip -density 150 out.tif >
Works perfectly. > What you have to remember is that -flatten always creates a canvas of the > current background color the size of the first images virtual canvas. > So you do not need to create that canvas yourself. > But the first image doesn't have the proper size canvas, it is too small (750x750). So I guess in your command above, the -repage, which, as far as I can tell, applies to the second copy of in.jpg, extends the canvas? Or what does? Or since you don't use (), maybe your -repage applies to all the images in the stack? I was using () to try to limit the effect of some of the options, but that may have been somewhat unnecessary for what I was trying to do. > The -page setting saves the 'virtual page' and 'virtual offset' into > any images created after it. While -repage does the same but for image > already in memory. > "image already in memory" -- should that be plural -- all images presently in memory, unless constrained to a subset via use of parentheses? > The above also has the effect that the meta-data of the first image > will be preserved, where in what you have the meta-data will be lost. > Perhaps part of that meta-data was a Photoshop profile with image > resolution! The above will preserve that unless you add -strip. > There is no meta-data of interest. The -density setting overrides the resolution, anyway. Stripping (huge) Photoshop profiles is probably a good thing, for my usage. > The above is actually equivalent in some ways to > > convert.exe in.jpg -background white -compose multiply -extent 1159x1515 \ > in.jpg -geometry +409+765 -compose multiply -composite \ > -compress zip -density 150 out.tif > > BOTH methods preserve that meta data and only use two image compositions. > That is -extent does one image composition too, also generating the > background canvas from the image given so as to preserve its meta data. > > If you know the second image should be in the bottom right corner you can > let IM calculate the offset needed! > > convert.exe in.jpg -background white -compose multiply -extent 1159x1515 \ > in.jpg -gravity SouthEast -compose multiply -composite \ > -compress zip -density 150 out.tif > I could, but I have to calculate one of the canvas size, and/or the 2nd image location in my program that generates this command anyway, so it isn't particularly hard to calculate both of them. The numbers are the easy part. > The second -compose setting isn't really needed, but it is better to > always be given before it is needed, (and reset to 'over' when it isn't). > > > > There are lots of ways to skin a cat, and what method you use depends > on what you want that skin for, and how messy you like the results! Indeed! Well, I've been playing a bit with -size, since that seems to be the option that I had in the original command that produces the erroneous effect in current versions of ImageMagick, but didn't in earlier versions. It appears that with some of the techniques you have proposed, the -size setting isn't needed. But it appears that if it is used, it has a strange effect. I've mostly seen examples of using -size to generate the size of a canvas, as I was doing initially (and seemingly unnecessarily). convert -size 1159x1515 xc:white out.tif produces a white canvas of the size given by the size option. Omit it, and one gets a 1x1 out.tif file. So it is documented to set the width and height of the image. But why does it double the size of in.tif? in.tif is 750x750, and using -size 1159x1515 causes it to double in size. 1159x1515 is not double 750x750. So I played a bit with different size option values... Using your command above that works perfectly, I added various -size options in front, and got some interesting behaviors. Here is a chart: -size 750x750 -- had seemingly no effect on the output -size 10x10 -- in.jpg resized to 94x94 pixels -size 100x100 -- in.jpg resized to about 187x187 pixels (my measurements may be slightly off, a pixel or so) -size 200x200 -- in.jpg resized to about 280x280 pixels -size 300x300 -- in.jpg resized to about 375x375 pixels -size 350x350 -- in.jpg resized to about 375x375 pixels -size 375x375 -- in.jpg resized to about 375x375 pixels -size 376x376 -- in.jpg not resized -size 400x400 -- in.jpg not resized -size 751x751 -- in.jpg resized to 1500x1500 -size 1000x1000 -- in.jpg resized to 1500x1500 -size 1500x1500 -- in.jpg resized to 1500x1500 -size 3001x3001 -- in.jpg resized to 1500x1500 This doesn't seem to have any rhyme nor reason to me. I can see a sort of interesting mathematical pattern, but I would expect one of the following effects of size on an image: 1) set an actual size for the next (or all subsequent) images read in 2) be ignored, for images that have their own size (-resize would be better for images that have a size) 3) scale the image to the specified size, possibly preserving aspect ratio But the chart shows that -size doesn't do any of those things for in.jpg (at least not consistently). _______________________________________________ Magick-users mailing list [email protected] http://studio.imagemagick.org/mailman/listinfo/magick-users
