[SOLVED] basic poly question

[bwana]

trying to learn how to use this command but i am failing miserably.

this command
convert [1-3].jpg -poly '1,1 1,1 1,1' out.jpg

gives this output

C:\Users\Stefan\Desktop\test>convert [1-3].jpg -poly '1,1 1,1 1,1' out.jpg
convert.exe: invalid argument for option `-poly': '1,1 @ error/convert.c/ConvertImageCommand/2239.

I have three jpegs in the directory named 1.jpg,etc

Where is the error in my way? And how do i mark this as 'answered' so that the generous respondent gets credit?

[snibgo]

For Windows you either need double quotes, or separate the numbers with commas and no spaces so you don't need quotes at all.

Code: Select all

convert [1-3].jpg -poly "1,1 1,1 1,1" out.jpg
convert [1-3].jpg -poly 1,1,1,1,1,1 out.jpg

Dunno how to change the title of the topic. Probably hit "edit", or something.

[fmw42]

Yes, just edit your first post at the very top of the topic and change the title.

Please read the options page documents again. You need to be sure the sum of weights = 1. Otherwise, the images will be added and you may get a very white image.

"A weighted sum of each image provided all weights add to unity and all exponents=1. If the the weights are all equal to 1/(number of images), then this is equivalent to -evaluate-sequence mean."


see http://www.imagemagick.org/script/comma ... s.php#poly

[bwana]

using this line
convert %d.jpg[1-5] -poly ".1,1 .2,1 .3,1 .2,1 .1,1" out.jpg

gives a nice sequence of images with progressively increasing and decreasing darkeness. However, the background is taking on a creme color. even using -background none doesnt avoid this. although -auto-level after the poly command does. why does the background change colr if my individual jpgs are just white? is it because the weightings are so low that the white is dimmed? if that's the case, why am i getting a creme color and not gray. looking at the histogram of the the two methods (one without and one with the auto-level command) you can see the differences
no auto level
image http://i.imgur.com/Irry3Pg.png
histogram http://i.imgur.com/8iUOn6f.png

with auto level
image http://i.imgur.com/e9Tg4F7.png
histogram http://i.imgur.com/6v8ZoZa.png


Also tried to play with exponent with this line
convert %d.jpg[1-3] -poly ".3,1 .3,4 .3,8" out.jpg

but i get all three images combined equally
http://i.imgur.com/L6ooxVp.png

I thought increasing the exponent would make the image have more weight (=darker)?

[fmw42]

Your weights still do not add up to 1.

Positive exponents raise the image to a positive power which should emphasize the darker areas of the image, because the input output transfer curve starts at a low slope near 0 and gets steeper as it gets closer to 1. Thus the whole graph is below a slope=1 going from 0 to 1.

Try the following

convert rose: rose: -poly "0.5,1 0.5,1" show:

should look just like the rose image.

And

convert rose: rose: -poly "0.5,2 0.5,2" show:

will be the rose image but darker due to the positive exponent. This would be like using

convert rose: -function polynomial "1,0,0" show:


It seems from this that -poly is working fine.

[bwana]

tnx fmw42
aha, I think the issue is that i am starting with b&w images. since the exponent is applied first, this has no effect on the resulting appearrance. after all, black to any exponent is still black. However, that said, the histograms of the two results using this code:
convert [1-3].jpg -poly "0.4,1 0.3,1 0.3,1" out.jpg
convert [1-3].jpg -poly "0.4,4 0.3,4 0.3,4" out2.jpg

are slightly different. The image input histograms are all identical and look like this:
http://i.imgur.com/mC2xUuD.png

the two output histograms are slightly different:
http://i.imgur.com/RIIWSTc.png
http://i.imgur.com/PRwee8l.png

First of all, the white pixel count is gone when compared to the input histogram. Since the coefficients add to 1, i do not understand why that should be.
Second, peaks appear at levels 153 and 181. why should that happen? There was nothing there to begin with?
Thirdly, in the first histogram, there is a low level of pixels between the peak at 181 to 255
in the second, there are many fewer pixels in this band. Why?

I realize that poly is working properly but I am trying to understand it quantitatively and appreciate your replies.

[fmw42]

Can you post links to your input image or at least the 3 channels you are using? It is hard to know what is happening without being able to test with your images. You can post them to some free image hosting service and put links to them here.

[bwana]

http://i.imgur.com/Ge061cz.jpg
http://i.imgur.com/XafJZq5.jpg
http://i.imgur.com/Squi1WX.jpg

[fmw42]

If you look at the verbose information for each of those images, you will see the histogram shows that they are 8-bit gray and not binary. Each numeral character is anti-aliased which produces the shades of gray other than black and white.

Therefore if you raise them to a power the graylevels will change. Furthermore you are combining them where they do not overlap. Thus the characters will show more gray because they are getting mixed with 2/3 white and 1/3 of the dark character. That is what I get from

convert 1.jpg 2.jpg 3.jpg -poly "0.3333,1 0.3333,1 0.3333,1" show:


If I raise them to a power of 10,

convert 1.jpg 2.jpg 3.jpg -poly "0.3333,10 0.3333,10 0.3333,10" show:

They will only be a little darker, because you are still mixing the darkened character with 2/3 white and 1/3 the darkened character

[bwana]

that explains why the histograms change the way they do.
when i delete the background so it is transparent leaving only a black numeral, poly now generates a completely black background. Obviously, poly is finding no value for the background and assigns it a value of 0 (=black)

tnx muchly, fmw42.

[fmw42]

that explains why the histograms change the way they do.
when i delete the background so it is transparent leaving only a black numeral, poly now generates a completely black background. Obviously, poly is finding no value for the background and assigns it a value of 0 (=black)

tnx muchly, fmw42.

Transparent color has a black background. I suspect that -poly like most other IM functions do not process the alpha channel (transparency). Some IM functions are channel sensitive so you can add -channel rgba before the function and it will process the alpha channel the same as the other channels.

What did you expect would happen when combining two or more images each with different alpha channels?


This seems to show that there may be a bug in alpha processing with -poly.

This is just making the image transparent where white:

convert logo: -transparent white show:


This does the same and applies -poly as a no-op, e.g. wt=1 and exponent=1. But it has preserved the white and made the rest transparent.


convert logo: -transparent white -poly "1,1" show:

This does the same

convert logo: -transparent white -channel rgba -poly "1,1" show:


I will report the possible bug. I do not think it was given much consideration when -poly was implemented.


This seems to show that it uses just the alpha channel of the first image. Compare the results from these. The last one results in no alpha channel.


convert logo: logo: -transparent white -poly "0.5,1 0.5,1" show:
convert \( logo: -transparent white \) logo: -poly "0.5,1 0.5,1" show:
convert logo: \( logo: -transparent white \) -poly "0.5,1 0.5,1" show:

[anthony]

More than likely -poly ignores channels not selected with -channel

And alpha should be treated as just a channel of data unless a 'alpha blend' is in effect.
As IMv6 does not enable alpha channel by default, alpha of the first image will be preserved.

In many operations in IMv6 that means the special 'sync' flag is specified in the channel flags (on by default), without it alpha is just another channel an no blending (or synchronization of pixel value changes when normalizing or auto-leveling, which is what introduced that flag)

I am not certain how you set (or unset) the 'alpha blend trait' in IMv7 as yet, as I have been concentrating on CLI interface rather than the operational handling.

[fmw42]

see viewtopic.php?f=3&t=23346