Rounded Corners Speed-Up Patch for Imagecache Actions

I should not have removed the canarymason tribute comment. I thought his work was the algorithm (which has been replaced), but now i see it was the idea of having independent corners. So, here's the comment back!

Rounding gifs?
What about an additional imagecache action that can turn pngs into gifs, while keeping the transparency?
Possible options:
- some options for how the palette colors are chosen (similar to common graphics programs).
- optional color dithering (usually I hate it, but sometimes it might be a good thing)
- optional transparency dithering (usually I hate it, but whatever)
- transparent palette color applied to pixels with alpha > 63

Maybe there could even be an action that chooses the best possible image format for you.

--------

Boring string keys:
I had been working on some home-grown algorithms using numeric keys, before I stumbled into this one function that returns string keys. At that moment it felt more like an annoyance.
One good thing about numeric keys is that they tell me in which sequence the color arguments go into imagecolorallocatealpha(). And I make fewer typos.
Anyway, use your string keys :)

--------

Maybe this solution could even be ported to imagemagick. The only things the library has to do is reading and writing pixel colors. The _canvasactions_roundedcorners_pixel_opacity does nothing with the image library, it's plain math. I have no experience with imagemagick, so I can't help in that.

"Arbitrary masking" is a good idea, but you should consider that a lot of possible masks are sparse (= only affect a few pixels).

Possible solutions:
- positioning a small mask (brush) in different places along the image.
- using a sparse PHP array $pixels[$x][$y], where only few pixels actually have a value.

What are the use cases you are thinking of?

I also had the idea that your canvasactions_mask has a high memory consumption on big images. I'm not sure, maybe you need to use imagecolordeallocate to free the memory? Just a guess.

Just for fun (or addiction), I made a new patch which should be even faster and more accurate :)
(this depends, if sin and cos and asin are not significantly slower than sqrt)

It's for PHP5 only, due to some OOP with protected object vars.

I don't have any experience with PHP4, so I'm not sure how to make this fully PHP4 compatible. I could replace the "protected" with "var", but that would be a shame, really.

Honestly, I think the previous solution is totally fine.
I just couldn't resist to post the new solution, due to ego issues, you know..

Can you show some examples?
Do you want it to be a strictly one-directional shadow, or more like a glow or halo?

For performance reasons I would suggest to maintain separate algorithms for C, D and E. For E we need to scan the full picture, for C we only operate on the border, and for D we can do a combined rounded corners + shadow solution, which means we don't need to scan the entire image.

C:
- Create an image that is a bit bigger, to give space for the drop shadow.
- Copy the original image into the top left.
- Paint a big part of the shadow by drawing parallel lines
- draw pixels for the rest.

D:
- Create an image that is a bit bigger, to give space for the drop shadow.
- Copy the original image into the top left.
- Paint the most part of the shadow using parallel lines
- use a combined rounded corners + shadow algorithm

E:
- Create an image that is a bit bigger, to give space for the drop shadow.
- Paint it all black (or grey, if you like) and fully transparent (filledrectangle).
- Copy the alpha channel into the new image, shifted by +x / +y. Maybe we need to do this per pixel, i don't know.
- If we had to copy all of the image (not just alpha), we set the color values back to black (or grey) now.
- Run blur on the new image's alpha channel (if that is possible).
- Reduce the overall opacity: $alpha = 127 - floor((127-$alpha) * 0.5); for every pixel, to make the shadow more transparent.
- Copy the old image into the new one, where it belongs (usually top left). Alpha values need to be correctly merged! (see below)

D+E:
- run the normal rounded corners alg. (not D!)
- run D.
(no need to provide this as a unified action)

---------

How to merge colors with alpha values?
(I hope this is correct now)

<?php

foreach (array('red', 'green', 'blue') as $key) {
  $result[$key] = round(1. * (
    $foreground[$key] * (127 - $foreground['alpha']) * 127
    + $background[$key] * $foreground['alpha'] * (127 - $background['alpha']) 
  ) / (
    127 * 127
    - $foreground['alpha'] * $background['alpha']
  ));
}

$result['alpha'] = round(1. * $foreground['alpha'] * $background['alpha'] / 127);
?>

How to explain that:
- Imagine a 127 x 127 window
- The curtain (foreground) covers an area that is (127 - $foreground['alpha']) wide.
- The shutter (background) covers an area that is (127 - $background['alpha']) high. A part of that is already hidden by the curtain.
- The remaining free area is $foreground['alpha'] wide and $background['alpha'] high.

Why do you want to round things? Use true floats instead, and use round() when going back to 127 format!
(my above example is still lacking a round() .. I'll fix that)

And for the merging:
There are different kinds of merging for different situations.
a) having separate transparent layers on top of each other. This is what I explained.
b) having a mask to manipulate the image. This is what you would do if you have the rounded corner mask. Sometimes your mask is just one alpha channel, sometimes it's rgb or rgba, sometimes you might want a mask with five channels..

I see your point.
I think the best is to work with different names for different concepts:

$transparency = $rgba['alpha'] / 127.0;
$opacity = 1 - $transparency;

I have a new version which is PHP 4.x compatible and can paint a rounded border for the rounded corners.
I did not modify the admin form, just the algorithm - so you would have to modify the admin form yourself.

The algorithm takes a border width and a border color, and the $radii array. It will paint a border on each of the rounded corners and each side, unless both corners on that side have a negative radius.

Example:
If you have $radii = array('tl' => 4, 'tr' => 4, 'bl' => -1, 'br' => -1);, then all sides will get a border except for the bottom.

Unfortunately the latest CVS has double linebreaks everywhere, so I don't want to use it for creating patches. How comes?

I'm on Windows XP.
canvasactions.inc shows double linebreaks in notepad++ and Firefox "view source" and Opera "view source", but not in windows editor.
imagecache_canvasactions.module does not show any double linebreaks.

Notepad++ text search shows you have \r\r\n in that file, while other files have just \r\n for linebreaks.

It was my CVS that didn't work properly.
Here is the current version of canvasactions.inc.

What you need is function canvasactions_roundedcorners_image(), function _canvasactions_roundedcorners_pixel_opacity() and function _canvasactions_sparse_circle_matrix(). You do not need class canvasactions_Circle.

canvasactions_roundedcorners_image() will need some modifications, if you want to allow setting border width and border color in the configuration page.

So what you want is a halo with gradient transparency.. correct?

I was thinking of this when I did the rounded corners patch, though I think it is a bit too much special-case.

What I could imagine is that instead of a fixed border color + border width you would provide a picture where the picture height is the border radius, and the pixel color at [x,y] would represent the border color at a specified point (depending on corner angle x and distance y from the picture. In other words, the picture defining the border would be stretched and bent around the image you want to decorate.

This method would allow different color shades depending on the angle, and it would allow fancy relief effects.

Another (maybe easier) idea would be to have an image defining the exact look of the corners.

Ideally I would like definition images with 5 or more color channels instead of just rgba. The additional channels could define how much of the original image should be preserved, or what to do with the original image's alpha value.

---

Anyway, this is highly specialized stuff, and a module like this can't provide a generic solution for everything.

My suggestion for more specialized things would be that you write your own imagecache action, either with
(1) a custom module, or with
(2) the built-in "custom action" feature. You can define the function in a module or theme, and then call it from within the "custom action" PHP stored in the database.

Having things in the code (ideally, a module) instead of the database is a good idea anyway, as it makes your work easier to deploy and easier to reuse in other projects, and you can pay an external developer to deliver just that, without introducing him into the details of your project.

@dman:
I totally missed the point of your post!
It's a nice way to do borders, and you can repeat the process to get a gradient. It's not exactly the result you would get with a dedicated anti-aliased action, but would look almost like that.

It's more tricky if you want a half-transparent border or gradient - I don't know if the "define canvas" can do that.

Btw, the second "rounded corners" action should have 17px radius, not 16px (and the next one would have 18px, etc).

This issue is ages old. But I remember that some effort went into the patch.

I don't know if there is still a use case for rounded corners nowadays. If not, feel free to close it again.

Oh, and: I am currently not actively using this module on any project.
I was simply playing around with some code and then ran across this.

If you think this is all a waste of time, I can understand.