Legacy ImageMagick Discussions Archive

hi all of you

i have a png file ,and i want to change the file right side to transparency in gradients.

ori. file :


and i want:


how can i do this.


thanks.

try something like though it may not be the most efficient.


size=`convert 460.png -format "%wx%h" info:`
convert 460.png \( -clone 0 -alpha extract \) \
\( -size $size gradient: -rotate -90 -threshold 20% -blur 20x65535 -level 0x50% \) \
\( -clone 1 -clone 2 -compose multiply -composite \) \
-delete 1,2 -compose copy_opacity -composite 460_grad.png

Adjust the threshold level and/or the first part of the blur.

very thanks

i want to change both side, how?

i try this code, but it not work

Fade transparency on both sides but not top and bottom.

Set a virtual-pixel with transparency on sides but not top and bottom, the blur just alpha channel.
You can then layer adjust the transparency.

This is ALOMST like the examples in IM examples, Thumbnails, Soft and Blurred Edges
http://www.imagemagick.org/Usage/thumbnails/#soft_edges
But using a different virtual pixel setting "VerticalTile"
http://www.imagemagick.org/Usage/misc/#vertical_tile

I'll use the built in rose: image so people can try it... WARNING: the -level in current IMv6 above is buggy and fails. I have reported this.


You may also like to look at IM Examples, Photo Handling, Overlaping Photos
http://www.imagemagick.org/Usage/photos/#overlap

thanks all of you

anthony wrote:

Code: Select all

  convert rose:  -alpha set -background None -virtual-pixel VerticalTile  \
          -channel A -blur 0x8  -level 50%,100% +channel  soft_sides.png

All I get is a transparent image?

Is that due to -level problems? What is wrong with -level?

Yes. That was the result I got, and it is because of the bug. The command is correct.


If you use -level 0,100% the operation should be a no-op but instead my tests should it is comming out negated. It did not do this before.

From previous examples of this -level in IMv6 is being actually being applied to alpha values (0=transparent, 1=opaque). The forumla given is ths correct. That is expanding 50% transparency at the edges (from the alpha channel blur) to full transparency while leaving 100% opaque parts 100% opaque, but that is not what is happening due to the bug.

The above example, IS correct, (works with IMv7 alpha test build too)

I'll go in and have a look at IMv6 -level tonight, and see if I can figure out where it is being negated.
Yeap found the fault, Also found that it was using matte values for 'palette' images, fixing that too.

It is now fixed next release, or an SVN IMv6 build.

Note that the gradient is a blur feathering, as such the curve is more of a sigmiodal curve falling quite sharply to zero at the edges. A -sigmoidal contrast can make it less sharp.

Better still look at the other link, which adds a linear gradient...
http://www.imagemagick.org/Usage/photos/#overlap
Or apply the distance gradient feather to this virtual pixel method.
http://www.imagemagick.org/Usage/thumbnails/#soft_edges
Either will avoid ths bug, and also work just as well.

The trick is the 'virtual-pixel' setting that use used to give the image transparent sides, while keeping top and bottom fully-opaque.

Note that the gradient is a blur feathering, as such the curve is more of a sigmiodal curve falling quite sharply to zero at the edges. A -sigmoidal contrast can make it less sharp.

You can make the gradient linear by changing -blur 0x8 to -blur 24x65535

The 24 is only approximate as r is about 3*sigma.

The VERY large sigm, makes the gaussian blur practically linear (just a square of constant values)
See More about this in Convolve, Mean or Average Filtering using Shape Kernels
http://www.imagemagick.org/Usage/convolve/#mean

In this case the radius (square radius) is the size of the linear gradient produced, after the edge values is 'leveled' to approach zero instead of 50%.

Note as a optimization, a linear morphology gradient will be twice as fast, as you don't need the second vertical 'blur' of the alpha channel.