fast code to add rounded corners

[fmw42]

Might there be a virtual canvas left behind each corner. Have you tried adding +repage before writing to .mpc?

[NicolasRobidoux]

@Fred: Thank you!

Code: Select all

convert -size 16x16 xc:none -draw "fill white rectangle 0,0 15,15 fill black circle 15,15 15,0" -background white -alpha shape +repage -strip RoundCorner8NW.mpc
convert -size 16x16 xc:none -draw "fill white rectangle 0,0 15,15 fill black circle 0,15   0,0" -background white -alpha shape +repage -strip RoundCorner8NE.mpc
convert -size 16x16 xc:none -draw "fill white rectangle 0,0 15,15 fill black circle 15,0   0,0" -background white -alpha shape +repage -strip RoundCorner8SW.mpc
convert -size 16x16 xc:none -draw "fill white rectangle 0,0 15,15 fill black circle 0,0   15,0" -background white -alpha shape +repage -strip RoundCorner8SE.mpc
convert RogerRabbit.mpc \
RoundCorner8NW.mpc -gravity northwest -composite \
RoundCorner8NE.mpc -gravity northeast -composite \
RoundCorner8SW.mpc -gravity southwest -composite \
RoundCorner8SE.mpc -gravity southeast -composite \
-quality 70 FramedRogerRabbit.jpg

ls -al RoundCorner8NWmpc
-rw-rw-r-- 1 nicolas nicolas 271 2012-03-15 19:45 RoundCorner8NW.mpc

[NicolasRobidoux]

And, while I am on the topic of speed, I may as well mention that on my machine (Intel Core i3) ImageMagick/libomp/gcc sets the default number of threads to 4 (the recommended number for this chip), but that the key step runs faster with

Code: Select all

MAGICK_THREAD_LIMIT=2 convert RogerRabbit.mpc RoundCorner8NW.mpc -gravity northwest -composite RoundCorner8NE.mpc -gravity northeast -composite RoundCorner8SW.mpc -gravity southwest -composite RoundCorner8SE.mpc -gravity southeast -composite -quality 70 FramedRogerRabbit.jpg

that is, with two less threads than the chip recommended default. This is doing benchmarks with convert -bench 100. If I set the thread limit directly and use the *nix time command a bunch of times (this keeps runs "more separate") as well as take the minimum run time (to factor out disk I/O of other processes somewhat) instead of the average like -bench essentially does, MAGICK_THREAD_LIMIT=3 comes out slightly ahead. (See viewtopic.php?f=1&t=20510#p81969.)

P.S. Tests with a later revision of 7.0.0 and a quieter machine suggests that the default (MAGICK_THREAD_LIMIT=4, on this machine) wins.

[anthony]

From your examples I gather tha tyou are saying that re-drawing the corners is faster than flipping and floping.

also reading prepared MPC files is faster that fliping and flopping using parenthesis?

Now that I find interesting!

[NicolasRobidoux]

From your examples I gather tha tyou are saying that re-drawing the corners is faster than flipping and floping

I actually don't know. See below. But it would not surprise me.

also reading prepared MPC files is faster that fliping and flopping using parenthesis?
Now that I find interesting!

Warning: I never include the time it takes to prepare the .mpc mask files because for my target use they are recycled for every incoming original image, and are put in ramdisk. That is: they are "hoisted out of the loop."
If you are going to use them only once, I have no clue whether .mpc is better than .mpr is better than parentheses. I did not perform this comparison because it's not relevant to my client. But I suspect that parentheses (possibly without flip/flop, that is, drawing directly each mask, B/C these tasks can run concurrently) win.

[NicolasRobidoux]

...Basically I divided the operations into 'setup' or 'initialization' operations set, and then a 'apply to image' operations set...

I figured as much: You're going for "transparent and standardized code structure" and I'm going for speed at all cost.