Create new actions for Imagecache
public
Carlitus@drupal.org - Tue, 2008-03-18 09:53
The imagecache module is awesome now but it has only 3 actions: scale, resize and crop. My proposal for SoC is use imagecache 2.0 and the hook_imagecache_action (http://www.darrelopry.com/story/imagecache-2x-beta) to create new actions like:
- Watermark
- Rounded corners
- Borders
- Insert text
- Insert image
- Rotate
- And so on
There are a lot of new possible actions, you can go to imagemagick options for more action examples: http://www.imagemagick.org/script/command-line-options.php
another idea
i think, it would be better to make an action uploader. So, user can create their costum actions and then upload them to the site....
i think it would be more flexible
yes please
A big YES.
This is how I'd make the project meaty.
Work load
Cool stuff admittedly (my personal favorite would be a seam carving action), but if I understand correctly then most of this is just invoking imagemagick with different options - it's hard for me to see how this could fill the Summer of Code's two or three months of work.
Is there significant work left on the Drupal side of things that can be done by a Summer of Code student? Images (and files) is for sure an area that needs a lot of work, but apart from the work load it also needs to fit into the "big picture" that walkah, quicksketch, dopry and others are working on for getting the important parts of the image/imagefield/imagecache solution into Drupal core.
Good ideas to help those guys out are appreciated.
Yes, seam carving!
I haven't thought in seam carving but this could be a killer action.
Ahh, the work is not only with imagemagick, remember that it needs to work with GD too.
Neurotic web design
I'm all for it
This is a great idea. Especially actions like Watermark, Rounded corners and Borders are highly in demand. I wonder how many new actions could be implemented during the summer?
Cross-posted to the Image group
Hopefully can get some more feedback from those folks. :)
I share some of jpetso's concerns, but I guess we'll wait and see what some of the other folks have to say.
That said, I think this would be absolutely killer functionality. :)
I'm skeptical that there'd
I'm skeptical that there'd be enough for a proper project. You'd be working on the ImageAPI adding new actions, I get the feeling that we'd probably be adding less than useful operations just to fill out the time on the project. Just my $0.02.
IMHO there is a lot of work
IMHO there is a lot of work to do fixing the imageapi imagik module and adding actions.
It would be interesting because if the project doesn't get complete, lets say, only 12 of the actions added, it would be a good start for others to add the rest of the actions as they are needed.
another imagecache wishlist item
...which might be appropriate for rolling into this in order to flesh it into a larger SoC project: remote file support.
I found myself wanting this recently when using FeedAPI to fetch illustrations from blip.tv feeds. It might also be useful for programmatically-retrieved images from, say, image searches or maybe with the Google Chart API. What I'm proposing:
I like the remote idea - I'm
I like the remote idea - I'm wondering if imagecache even needs to download a physical copy of the remote image or if it can just generate the needed transformed version of it on the fly by doing a get of the image, transform, and saving the result to a cache location.
Another idea, make imagecache work with local site files - say images that are part of your theme - that don't reside in the file_directory_path() directory. I never quite understood that limitation. It seems the general URL structure is file_directory_path() . PRESET . target_path which could work for any path local or maybe even remote files as suggested.
Also an AHAH powered form a al Drupal 6 for the presets would be awesome.
Other ideas - sorry for any repeats.
Preset inheritance -so you could make preset B "derived" from A such that the final be is everything in A and B in that order or B and A order.
Cache lifetimes
A away to control the fill color for cropped images - black, white, blue, etc.
Image compositing - sorta like a watermark in implementation but more generic - put image A over B at offset x,y
Image conversions - take imageA.png and resize and save as imageA.jpg
Text effects
Conditional or parameterized presets - something like /imagecache/scale_warp/files/images/banner.png?warp_factor=5 which would use the scale_warp preset but override the warp_factor
and I forgot to add
a BIG +1 on all these additional ideas, particularly preset inheritance and compositing. I wrote a custom GD compositing system for my blog header; it would've been much much easier to use imagecache.
mediamover
go look at the media mover module it does a great job of providing a framework for locating, fetching, and processing local or remote files.
I'd definitely lobby for
I'd definitely lobby for keeping a local copy, if only so that additional derived images (thumb/half-size/banner, whatever) don't incur network load. But I can see that omitting that requirement could keep things considerably simpler while still satisfying most users' needs very well.
One thing I forgot to mention is that there are of course security implications to adding remote file support (both to prevent exploits and DoSing via endless expensive GD operations). Remote fetching should probably only be available through calls properly routed through theme() (which implies a one-off token will need to be added to imagecache URLs), and some filetype checking via GD would probably also be appropriate to ensure that PHP files can't be dumped into /files and run on systems where PHP hasn't been turned off for that directory.
Along these lines it might be worthwhile to make "remote fetch support" an imagecache action so that it's only even available to a preset when it's known it'll be needed.
I see a lot of great ideas
I see a lot of great ideas here but nothing that feels like a solid proposal for a 2.5 month project. Each one individually feels like a DROP task and a SoC project should be more than "here are 12 DROP tasks." The one possible exception is incorporating remote file access, which I agree feels like it is frought with danger from a security standpoint (I don't know enough about the issues involved to comment on whether or not this can be done safely.) Even that seems like it might be a bit light.
If someone can pull everything together into a meaty project I'd love to see it.
At Drupalcon we agreed to
At Drupalcon we agreed to push SimpleTest in each SOC project - add that to the scope of this and that's a lot more meat. It could include tests for existing actions as well.