Proportional watermark

[n0_namer]

I tried this variant. It takes a height of the watermark.png but I need to take a height of the input.png.

[fmw42]

In IM 7, this gets 1/5 of the input image height and resizes the watermark image to that size.

Code: Select all

magick input.png -set option:wmh "%[fx:h/5]" ( watermark.png -resize x%[wmh] ) -gravity center -composite result.png

[n0_namer]

Works perfect. Thanks, snibgo.

[fmw42]

I am not snibgo

[fghhfg]

A version:

Code: Select all

magick input.png ( watermark.png -resize x%[fx:u[0].h/5] ) -gravity center -composite result.png

this is wrong, but it is faster than b version.

B version:

Code: Select all

magick input.png -set option:wmh "%[fx:h/5]" ( watermark.png -resize x%[wmh] ) -gravity center -composite result.png

now I want to speedup, so I use "-sample" instead of "-resize".
The"-sample" of B version is still faster than the "-sample" of A version. (x1.55 times)

For this reason, you may want to use the wrong version if possible...

the "Image Stack" or "-set" cost a lot of speed...
How do I speedup on corrected version?

my code (IM7):

Code: Select all

find a -type f -name "*.jpg" -print0 | xargs -0 -n1 -P8 -I {} magick {} -set option:wmh %[fx:w/2] ( mark2.png -sample %[wmh]x ) -gravity east -compose dissolve -define compose:args=60 -composite {}

[GeeMack]

How do I speedup on corrected version?

I don't know much about the internals, but if there's something about setting and reading a variable that slows the command, you could try writing the FX calculation as an inline argument to the "-resize" operation. A command like this should give you the result you're looking for. You'll have to test it yourself for speed comparison.

Code: Select all

magick input.png watermark.png -resize "x%[fx:t?u[0].h/5:u[0].h]" -gravity center -composite result.png

The FX expression there will only resize the second image in the stack, which is the watermark. Otherwise it leaves the size unchanged.

[fghhfg]

ternary operator, nice try, but it has same speed as `"Image Stack" + "-set"`

OK, I accept this result.

Now I believe the reason b version spend few time just because it deals few pixels.

nothing wrong inside IM.

I find xnconvert faster than IM though.