Hi all, I''ve already posted this as a ticket in the Trac system, so maybe this post is unnecessary. On the other hand, it might be not, and I think it might be interesting for this list. I wrote a set of methods/helpers that make it easy to use ImageMagick/RMagick from within Rails. You can use that to resize (or crop, or rotate, or ... basically everything ImageMagick can do) your images on the fly, with only one simple tag in your view and one configuration command in your controller. An example: # in the controller class PhotoController < ApplicationController imagemagick_for "/var/lib/photos" end # in the view <%= imagemagick_tag "presentation.jpg", "resize(100x100)" %>>From the outside, this gives you the image presentation.jpg from/var/lib/photos, resized to fit within 100x100 pixels.>From the inside, the following takes place:The imagemagick_for method in the controller initializes the ImageMagick helper to use the images from /var/lib/photos, and it adds an action called ''imagemagick'' to that controller. This action will handle the requests for processed images. The imagemagick_tag method is similar to the image_tag method. It gives you an <img> tag that points to the ''imagemagick'' action with the given filename and commands. So, all you have to do to be able to resize/rotate/alter your images, is: 1. Install RMagick/ImageMagick; 2. Create a directory where you will store your images; 3. Add imagemagick_for to the controller; 4. Use imagemagick_tag whenever you need a processed image. If you think that''s necessary, you can also enable caching of the processed images. (Create a writable directory to store the cache, and add its path to the imagemagick_for method. That''s all.) Any suggestions? Could this be useful? For a demo, the ticket, the documentation and the code, visit: http://vantulder.net/rails/magick/ Best regards, Gijs van Tulder
Hi Gijs, Gijs van Tulder wrote:> Hi all, > > I''ve already posted this as a ticket in the Trac system, so maybe this > post is unnecessary. On the other hand, it might be not, and I think > it might be interesting for this list.it''s definetely not unnecessary.. eg. I''m not really tracking issues in Trac but watching this email continuously :)> I wrote a set of methods/helpers that make it easy to use > ImageMagick/RMagick from within Rails. You can use that to resize (or > crop, or rotate, or ... basically everything ImageMagick can do) your > images on the fly, with only one simple tag in your view and one > configuration command in your controller. > > An example: > # in the controller > class PhotoController < ApplicationController > imagemagick_for "/var/lib/photos" > end > > # in the view > <%= imagemagick_tag "presentation.jpg", "resize(100x100)" %>Wow that sounds excellent! Are there any chances to release your code as a gem? As a last sidenode, I''d be really curious how many of us are writing a picture gallery with rails :) Maybe we could join our efforts.. (if you''re interested, I show you mine privately) Kristof
Kristof Jozsa <dyn-Lj6TOhj6PqOT9ig0jae3mg@public.gmane.org> writes:> As a last sidenode, I''d be really curious how many of us are writing > a picture gallery with rails :) Maybe we could join our > efforts.. (if you''re interested, I show you mine privately)I''m glad to see Gallery 2.0 come out, but frankly I don''t really trust PHP applications. I''m sure it''s possible to write secure and trustworthy PHP code, I just have been burned several times and I''m tired of the PHP patching treadmill. I didn''t say that to start a PHP flame-fest, but rather to say I really want a good Rails photo gallery. I was part of a team that did one of the photo galleries for Rails day. It''s based on RMagick. Here''s some notes we took before we started: http://www.lathi.net/twiki-bin/view/Main/PhotoDepot although that doesn''t show how much we got done (or didn''t get done). I only mention that as some ideas of what/how to put into a photo gallery. I''d like to see (probably belongs on the Rails wiki) a list of folks who are willing to make their photo galleries publicly available. I think that''d let us see who''s the furthest along or who''s moving in the direction we''d like to go. Overall I agree, I think there are a lot of people interested and working on photo galleries. I think there are probably more individual projects than necessary. I also think it''d be cool to team up on this. -- Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:> So, all you have to do to be able to resize/rotate/alter your images, is: > 1. Install RMagick/ImageMagick; > 2. Create a directory where you will store your images; > 3. Add imagemagick_for to the controller; > 4. Use imagemagick_tag whenever you need a processed image.This is very nice. I assume if you have imagemagick_for "/var/lib/photos" and you call imagemagick_tag "foo/bar/picture.jpg" it handles that correctly? I.E. the picture.jpg is in /var/lib/photos/foo/bar. -- Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
I agree completely, there are probably 20 people doing photo galleries. just think if they all worked together I know the wiki has a spot for oss apps. but shouldnt there be a place to just act as a rails app clearinghouse? Sam On 9/14/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org> wrote:> > Kristof Jozsa <dyn-Lj6TOhj6PqOT9ig0jae3mg@public.gmane.org> writes: > > > As a last sidenode, I''d be really curious how many of us are writing > > a picture gallery with rails :) Maybe we could join our > > efforts.. (if you''re interested, I show you mine privately) > > I''m glad to see Gallery 2.0 come out, but frankly I don''t really trust > PHP applications. I''m sure it''s possible to write secure and > trustworthy PHP code, I just have been burned several times and I''m > tired of the PHP patching treadmill. > > I didn''t say that to start a PHP flame-fest, but rather to say I > really want a good Rails photo gallery. I was part of a team that did > one of the photo galleries for Rails day. It''s based on RMagick. > Here''s some notes we took before we started: > > http://www.lathi.net/twiki-bin/view/Main/PhotoDepot > > although that doesn''t show how much we got done (or didn''t get done). > I only mention that as some ideas of what/how to put into a photo > gallery. I''d like to see (probably belongs on the Rails wiki) a list > of folks who are willing to make their photo galleries publicly > available. I think that''d let us see who''s the furthest along or > who''s moving in the direction we''d like to go. > > Overall I agree, I think there are a lot of people interested and > working on photo galleries. I think there are probably more > individual projects than necessary. I also think it''d be cool to team > up on this. > -- > Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper > doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Doug Alcorn wrote:> Kristof Jozsa <dyn-Lj6TOhj6PqOT9ig0jae3mg@public.gmane.org> writes: > > >>As a last sidenode, I''d be really curious how many of us are writing >>a picture gallery with rails :) Maybe we could join our >>efforts.. (if you''re interested, I show you mine privately) > > > I''m glad to see Gallery 2.0 come out, but frankly I don''t really trust > PHP applications. I''m sure it''s possible to write secure and > trustworthy PHP code, I just have been burned several times and I''m > tired of the PHP patching treadmill.Exactly the same feelings here.. but as a primary reason I started to work on it to get familiar with Rails.> Overall I agree, I think there are a lot of people interested and > working on photo galleries. I think there are probably more > individual projects than necessary. I also think it''d be cool to team > up on this.Well the least I have is free time, so I''d prefer to see someone taking the coordination work. Anyway, here''s a short list what I''ve implemented so far: - browse pictures, paging, configurable row/col size - view picture, display exif information (for jpeg files), add new comment to picture, show comments, rename picture title (these uses ajax) - view pic in original size (a surprising functionality huh :) - optional login allowing functionality like adding comments, renaming, etc. non-logged on ppl are guests - user signup - admin pages with user CRUD - a standalone script capable of scanning a subdir hierarchy, finding image files, creating categories from directory names and resizing/uploading pictures into the gallery - a maintaince script checking for missing files, regenerating resized images if missing, deleting DB entries where original pictures got deleted, etc. - drag&drop picture management for admins (work in progress, deletion is done) that''s about all.. and moving *really* slowly because I work on it 1-2 hours in about every 2 weeks or less.. Kristof ps. oh and the design is almost nonexistent on all pages :)
This is really funny. Over at the Typo list, the same subject came up a few days ago. There are literally 5-10 individual projects going on here. My project, together with one or two people hasn''t really gotten started, but it is good to see that people are interested in this subject. I agree that there are too many projects and would love to see one develop as nicely as Typo has in the last few months. Keith Bingman www.keithbingman.com On Sep 14, 2005, at 2:29 PM, Doug Alcorn wrote:> Kristof Jozsa <dyn-Lj6TOhj6PqOT9ig0jae3mg@public.gmane.org> writes: > > >> As a last sidenode, I''d be really curious how many of us are writing >> a picture gallery with rails :) Maybe we could join our >> efforts.. (if you''re interested, I show you mine privately) >> > > I''m glad to see Gallery 2.0 come out, but frankly I don''t really trust > PHP applications. I''m sure it''s possible to write secure and > trustworthy PHP code, I just have been burned several times and I''m > tired of the PHP patching treadmill. > > I didn''t say that to start a PHP flame-fest, but rather to say I > really want a good Rails photo gallery. I was part of a team that did > one of the photo galleries for Rails day. It''s based on RMagick. > Here''s some notes we took before we started: > > http://www.lathi.net/twiki-bin/view/Main/PhotoDepot > > although that doesn''t show how much we got done (or didn''t get done). > I only mention that as some ideas of what/how to put into a photo > gallery. I''d like to see (probably belongs on the Rails wiki) a list > of folks who are willing to make their photo galleries publicly > available. I think that''d let us see who''s the furthest along or > who''s moving in the direction we''d like to go. > > Overall I agree, I think there are a lot of people interested and > working on photo galleries. I think there are probably more > individual projects than necessary. I also think it''d be cool to team > up on this. > -- > Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper > doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Sam Mayes <codeslave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:> I agree completely, there are probably 20 people doing photo > galleries. just think if they all worked together I know the wiki > has a spot for oss apps. but shouldnt there be a place to just act > as a rails app clearinghouse?The wiki is what we want it to be: http://wiki.rubyonrails.com/rails/show/PhotoApp -- Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
Whats the likelyhood of getting everyone to coordinate? Sam On 9/14/05, Keith Bingman <kbingman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> This is really funny. Over at the Typo list, the same subject came up > a few days ago. There are literally 5-10 individual projects going on > here. My project, together with one or two people hasn''t really > gotten started, but it is good to see that people are interested in > this subject. I agree that there are too many projects and would love > to see one develop as nicely as Typo has in the last few months. > > Keith Bingman > www.keithbingman.com > > On Sep 14, 2005, at 2:29 PM, Doug Alcorn wrote: > > > Kristof Jozsa <dyn-Lj6TOhj6PqOT9ig0jae3mg@public.gmane.org> writes: > > > > > >> As a last sidenode, I''d be really curious how many of us are writing > >> a picture gallery with rails :) Maybe we could join our > >> efforts.. (if you''re interested, I show you mine privately) > >> > > > > I''m glad to see Gallery 2.0 come out, but frankly I don''t really trust > > PHP applications. I''m sure it''s possible to write secure and > > trustworthy PHP code, I just have been burned several times and I''m > > tired of the PHP patching treadmill. > > > > I didn''t say that to start a PHP flame-fest, but rather to say I > > really want a good Rails photo gallery. I was part of a team that did > > one of the photo galleries for Rails day. It''s based on RMagick. > > Here''s some notes we took before we started: > > > > http://www.lathi.net/twiki-bin/view/Main/PhotoDepot > > > > although that doesn''t show how much we got done (or didn''t get done). > > I only mention that as some ideas of what/how to put into a photo > > gallery. I''d like to see (probably belongs on the Rails wiki) a list > > of folks who are willing to make their photo galleries publicly > > available. I think that''d let us see who''s the furthest along or > > who''s moving in the direction we''d like to go. > > > > Overall I agree, I think there are a lot of people interested and > > working on photo galleries. I think there are probably more > > individual projects than necessary. I also think it''d be cool to team > > up on this. > > -- > > Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper > > doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Sam Mayes <codeslave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:> Whats the likelyhood of getting everyone to coordinate? > > On 9/14/05, Keith Bingman <kbingman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> This is really funny. Over at the Typo list, the same subject came up >> a few days ago. There are literally 5-10 individual projects going on >> here. My project, together with one or two people hasn''t really >> gotten started, but it is good to see that people are interested in >> this subject. I agree that there are too many projects and would love >> to see one develop as nicely as Typo has in the last few months.The likelihood of getting everyone to coordinate is zero. All I''m wanting is a central place to list open source Rails photo apps. Let the "market forces" of free software do their thing after that... http://wiki.rubyonrails.com/rails/show/PhotoApp -- Doug Alcorn - http://lathi.net/RubyOnRailsDeveloper doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
Hi, Kristof: A gem is indeed a good idea. I''ve posted it on my website. After installing the gem, you''ll have to add a line requiring that gem to your environment.rb. More info and a download on: http://vantulder.net/rails/magick/ Doug: The first version of the module did not support subdirectories. All images had to be in the directory you gave to imagemagick_for. I''ve updated it, though, so now you can have subdirectories. Your example:> "/var/lib/photos" and you call imagemagick_tag "foo/bar/picture.jpg" > it handles that correctly? I.E. the picture.jpg is in > /var/lib/photos/foo/bar.works now. Adam:> However... does your module support dynamic picture URLs? > > imagemagick_for "/var/images/profile/@profile.id/"You can use the new subdirectory functionality to do that. You can''t specify the dynamic part in the imagemagick_for part, but you can do that in the imagemagick_tag method. In your situation: imagemagick_for "/var/images/profile" and something like <%= imagemagick_tag "@profile.id/image.jpg %> (this will render /var/images/profile/@profile.id/image.jpg) Gijs
Nice work. What if you have images stored in a db though? Regards, Tomas Jogin On 9/14/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi all, > > I''ve already posted this as a ticket in the Trac system, so maybe this > post is unnecessary. On the other hand, it might be not, and I think > it might be interesting for this list. > > I wrote a set of methods/helpers that make it easy to use > ImageMagick/RMagick from within Rails. You can use that to resize (or > crop, or rotate, or ... basically everything ImageMagick can do) your > images on the fly, with only one simple tag in your view and one > configuration command in your controller. > > An example: > # in the controller > class PhotoController < ApplicationController > imagemagick_for "/var/lib/photos" > end > > # in the view > <%= imagemagick_tag "presentation.jpg", "resize(100x100)" %> > > >From the outside, this gives you the image presentation.jpg from > /var/lib/photos, resized to fit within 100x100 pixels. > > >From the inside, the following takes place: > The imagemagick_for method in the controller initializes the > ImageMagick helper to use the images from /var/lib/photos, and it adds > an action called ''imagemagick'' to that controller. This action will > handle the requests for processed images. > > The imagemagick_tag method is similar to the image_tag method. It > gives you an <img> tag that points to the ''imagemagick'' action with > the given filename and commands. > > So, all you have to do to be able to resize/rotate/alter your images, is: > 1. Install RMagick/ImageMagick; > 2. Create a directory where you will store your images; > 3. Add imagemagick_for to the controller; > 4. Use imagemagick_tag whenever you need a processed image. > > If you think that''s necessary, you can also enable caching of the > processed images. (Create a writable directory to store the cache, and > add its path to the imagemagick_for method. That''s all.) > > Any suggestions? Could this be useful? > > For a demo, the ticket, the documentation and the code, visit: > http://vantulder.net/rails/magick/ > > Best regards, > > Gijs van Tulder > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
For quick one page Coldfusion/ASP1.0 style action-in-the-view stuff this is great. But I can''t see this ever making it into the Rails core. It violates MVC (model manipulations should be in the model or the controller (Photos = model in this case, error recovery code in the view is a mess)), and isn''t really Ajax friendly. Still it makes a pretty nice wrapper around RMagick. Any thoughts of just making this callable from a controller? Gijs van Tulder wrote:> Hi all, > > I''ve already posted this as a ticket in the Trac system, so maybe this > post is unnecessary. On the other hand, it might be not, and I think > it might be interesting for this list. > > I wrote a set of methods/helpers that make it easy to use > ImageMagick/RMagick from within Rails. You can use that to resize (or > crop, or rotate, or ... basically everything ImageMagick can do) your > images on the fly, with only one simple tag in your view and one > configuration command in your controller. > > An example: > # in the controller > class PhotoController < ApplicationController > imagemagick_for "/var/lib/photos" > end > > # in the view > <%= imagemagick_tag "presentation.jpg", "resize(100x100)" %> > >>From the outside, this gives you the image presentation.jpg from > /var/lib/photos, resized to fit within 100x100 pixels. > >>From the inside, the following takes place: > The imagemagick_for method in the controller initializes the > ImageMagick helper to use the images from /var/lib/photos, and it adds > an action called ''imagemagick'' to that controller. This action will > handle the requests for processed images. > > The imagemagick_tag method is similar to the image_tag method. It > gives you an <img> tag that points to the ''imagemagick'' action with > the given filename and commands. > > So, all you have to do to be able to resize/rotate/alter your images, is: > 1. Install RMagick/ImageMagick; > 2. Create a directory where you will store your images; > 3. Add imagemagick_for to the controller; > 4. Use imagemagick_tag whenever you need a processed image. > > If you think that''s necessary, you can also enable caching of the > processed images. (Create a writable directory to store the cache, and > add its path to the imagemagick_for method. That''s all.) > > Any suggestions? Could this be useful? > > For a demo, the ticket, the documentation and the code, visit: > http://vantulder.net/rails/magick/ > > Best regards, > > Gijs van Tulder
Excellent. This works great...and will save me a lot of time. Just to be picky: - Would it be possible to have a way that we could change the ''imagemagick'' part of the URL to some other word? - Would it also be possible to alias certain transformations in a config file to acheive a cleaner URL? IE: controller: imagemagick_for ''/var/photos/profile'', :cache=>''/tmp/cache'', :url_prefix => ''photos'' template: <%= imagemagick_tag ''myname.png'', :size => ''small'' %> config: small: resize:(100x50) medium: resize:(320x240) large: resize(640x480) final URL: /photos/small/myname.png == /imagemagick/myname.png?commands=resize(100x50) Just my two cents. Thanks! Adam. On 9/14/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi, > > Kristof: > A gem is indeed a good idea. I''ve posted it on my website. After > installing the gem, you''ll have to add a line requiring that gem to > your environment.rb. More info and a download on: > http://vantulder.net/rails/magick/ > > Doug: > The first version of the module did not support subdirectories. All > images had to be in the directory you gave to imagemagick_for. I''ve > updated it, though, so now you can have subdirectories. Your example: > > > "/var/lib/photos" and you call imagemagick_tag "foo/bar/picture.jpg" > > it handles that correctly? I.E. the picture.jpg is in > > /var/lib/photos/foo/bar. > > works now. > > Adam: > > However... does your module support dynamic picture URLs? > > > > imagemagick_for "/var/images/profile/@profile.id/ <http://profile.id/>" > > You can use the new subdirectory functionality to do that. You can''t > specify the dynamic part in the imagemagick_for part, but you can do > that in the imagemagick_tag method. In your situation: > > imagemagick_for "/var/images/profile" > and something like > <%= imagemagick_tag "@profile.id/image.jpg <http://profile.id/image.jpg>%> > (this will render /var/images/profile/@profile.id/image.jpg<http://profile.id/image.jpg> > ) > > Gijs > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Ok, ignore my last comment, I just read the code and see it''s a dynamic url controller (the static demo page threw me off ;). Please pardon my confusion. Saint Trois wrote:> For quick one page Coldfusion/ASP1.0 style action-in-the-view stuff this > is great. But I can''t see this ever making it into the Rails core. It > violates MVC (model manipulations should be in the model or the > controller (Photos = model in this case, error recovery code in the view > is a mess)), and isn''t really Ajax friendly. > > Still it makes a pretty nice wrapper around RMagick. Any thoughts of > just making this callable from a controller? > > Gijs van Tulder wrote: > >> Hi all, >> >> I''ve already posted this as a ticket in the Trac system, so maybe this >> post is unnecessary. On the other hand, it might be not, and I think >> it might be interesting for this list. >> >> I wrote a set of methods/helpers that make it easy to use >> ImageMagick/RMagick from within Rails. You can use that to resize (or >> crop, or rotate, or ... basically everything ImageMagick can do) your >> images on the fly, with only one simple tag in your view and one >> configuration command in your controller. >> >> An example: >> # in the controller >> class PhotoController < ApplicationController >> imagemagick_for "/var/lib/photos" >> end >> >> # in the view >> <%= imagemagick_tag "presentation.jpg", "resize(100x100)" %> >> >>> From the outside, this gives you the image presentation.jpg from >> >> /var/lib/photos, resized to fit within 100x100 pixels. >> >>> From the inside, the following takes place: >> >> The imagemagick_for method in the controller initializes the >> ImageMagick helper to use the images from /var/lib/photos, and it adds >> an action called ''imagemagick'' to that controller. This action will >> handle the requests for processed images. >> >> The imagemagick_tag method is similar to the image_tag method. It >> gives you an <img> tag that points to the ''imagemagick'' action with >> the given filename and commands. >> >> So, all you have to do to be able to resize/rotate/alter your images, is: >> 1. Install RMagick/ImageMagick; >> 2. Create a directory where you will store your images; >> 3. Add imagemagick_for to the controller; >> 4. Use imagemagick_tag whenever you need a processed image. >> >> If you think that''s necessary, you can also enable caching of the >> processed images. (Create a writable directory to store the cache, and >> add its path to the imagemagick_for method. That''s all.) >> >> Any suggestions? Could this be useful? >> >> For a demo, the ticket, the documentation and the code, visit: >> http://vantulder.net/rails/magick/ >> >> Best regards, >> >> Gijs van Tulder
A new version of the ImageMagick-wrapper is now available. You can now add your own commands, and it is possible change the name of the ''imagemagick'' action. http://vantulder.net/rails/magick/ On 9/15/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> - Would it be possible to have a way that we could change the ''imagemagick'' > part of the URL to some other word?Yes, that''s possible now. Set :action_name in the options hash when calling imagemagick_for.> - Would it also be possible to alias certain transformations in a config > file to acheive a cleaner URL?I was thinking about a way to make your own commands. In the new version, you can do that, and that also means that you can alias transformations like you suggested. After running imagemagick_for, you can now add your own commands, or ''recipes''. These custom recipes can be used like and mixed with normal ImageMagick commands. In your example: # controller imagemagick_for ... imagemagick_recipe :small, "resize(100x100)+border(1,1,f00)" # view <%= imagemagick_tag "picture.jpg", "small" %> A String-recipe is only the simple way of adding recipes, and it is mainly useful if you want to have a shortcut for a series of commands you want to use in many places. Like with the before_ and after_filters, it is also possible to write Proc or Method recipes, which allows you to program with the RMagick commands. Useful if you want difficult transformations, complete with arguments and such. See the documentation for a few examples.> final URL: > /photos/small/myname.png => /imagemagick/myname.png?commands=resize(100x50)Well, not exactly. The final url would be something like: /controller/imagemagick/myname.png?commands=small If you want cleaner urls, you''ll have to write your own routes. (Or is there a way in which imagemagick_for could add the routes for you? Is that be something you''d want? I''m not sure I would, I think I prefer to write my own rules.) On 9/15/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> What if you have images stored in a db though?Well, you can''t use it, I''m afraid. Or is there a good way to make this possible? The problem is that the image has to be available two times: when you display the imagemagick_tag, and when the image is rendered. The first time is not that difficult, you''d just pass the image data from your model to the imagemagick_tag method. But how can you get to it the second time? Is there a uniform way in which the images are stored in the database? So that say, you can do this: imagemagick_for :model=>"Photo", :method=>"image" <%= imagemagick_tag @photo.id %> and then have the imagemagick action request the Photo object with the given id, which has a method ''image'' that returns a blob of the image? Could that be a solution? Regards, Gijs
Gijs -- Thanks for being so responsive to my suggestions. A few comments and other suggestions: <%= imagemagick_tag @user.id.to_s + ''/'' + @picture.id.to_s + ".jpg", ''small'' %> the ''/'' is being escaped. The URL looks like: http://127.0.0.1:3000/user/pics/small/13%2F295.jpg - In an effort to reduce code, could there be a way to declare ''recipes'' in a server-side config file? This way, if two or more controllers use the same ''small'' definition, it''s not duplicated. (Ideally, I want to set recipes in the database and be able edit them in realtime... but I wouldn''t want your code to handle this, only make it possible.) I''d actually love to define the directory, cache dir, and action_name for each controller in a single config file -- but I''d be happy with just having a recipe config file. - Could there be a global option that can be turned on/off so that URLs can only be called with a recipe? ie: /user/pics/small/user.jpg ## this URL is fine /user/pics/resize(320x240+flop)/user.jpg ## this URL fails .. no direct commands! Thanks again, Adam _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> On 9/15/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > What if you have images stored in a db though? > > Well, you can''t use it, I''m afraid. Or is there a good way to make > this possible? > > The problem is that the image has to be available two times: when you > display the imagemagick_tag, and when the image is rendered. The first > time is not that difficult, you''d just pass the image data from your > model to the imagemagick_tag method. But how can you get to it the > second time?It''d be possible if you were able to pass the url_for the action which retrieves the image from the db. Also, what if you have images but they''re not all stored in the same directory? How about a way to pass images with a full path instead of assuming they''re all in the same directory? Regards, Tomas Jogin
Hello again, After playing with the new version for several hours last night I have a few more thoughts: #1. On my production server using lighttpd (and even with webrick,too), sometimes ''render :file'' was trying to send a template if use_cache was turned on and the file existed (that is, the second hit to the image caused a big mess in the log and a broken image). I''m not fully aware of whats going on in the backend -- but would send_file work better? I ended up reverting back to my old image/thumbnail code until this is resolved. #2. It would be very cool if the route trick could be smart about subdirectories. This is what I want my URL to be: /profile/pics/small/39/303/filename.jpg profile = class pics = action_name small = recipe (resize 96x72) 39 = id of class instance 303 = id of picture (and actual filename on server) filename = filename of picture (for download purposes only) And the file is stored: /var/pics/profile/39/303 But the imagemagick_tag can''t handle this... and it doesn''t come so easily when I write my own either. The closest I can get with a route trick is: http://my_site/profile/pics/small/39%2F303/filename.jpg where 39%2F303 = "39/303", the subdirectory and filename of the actual image once appended to the directory root. Having 39/303 will break the route, so I have to use that ugly solution instead. #3. For my site, 5 or 6 models can have pictures -- and each picture will have 2 to 6 various sized thumbnails. I reiterate my desire for a global config where I could set action_name, root directory for images (that can be aware of sub dirs..), cache directory for images, global recipes... and then in each controller I''d only have to set: imagemagick_for, and perhaps some specific recipes. Idea: imagemagick_root = ''/var/pics/:controller/:id/'' I know I''m now getting into a very custom solution here... so consider it just a brain dump. You happened to release this code as I''m about to go live with my site -- which is very image intensive. Currently I generate X # of thumbnails on upload... but if I ever wanted to change their size, I''d have to regenerate all thumbnail images from the source image. If I could merely change config and have it reflected in (almost) realtime, that''d be very cool. #4. Other concern, if I change a recipe and the image is cached -- is your code smart enough to realize it should regenerate the image.. or should I delete the cached images? Adam /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filename On 9/15/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Gijs -- > > Thanks for being so responsive to my suggestions. A few comments and other > suggestions: > > <%= imagemagick_tag @user.id.to_s + ''/'' + @picture.id.to_s + ".jpg", > ''small'' %> > > the ''/'' is being escaped. The URL looks like: > http://127.0.0.1:3000/user/pics/small/13%2F295.jpg > > - In an effort to reduce code, could there be a way to declare ''recipes'' > in a server-side config file? This way, if two or more controllers use the > same ''small'' definition, it''s not duplicated. (Ideally, I want to set > recipes in the database and be able edit them in realtime... but I wouldn''t > want your code to handle this, only make it possible.) I''d actually love to > define the directory, cache dir, and action_name for each controller in a > single config file -- but I''d be happy with just having a recipe config > file. > > - Could there be a global option that can be turned on/off so that URLs > can only be called with a recipe? ie: > > /user/pics/small/user.jpg ## this URL is fine > /user/pics/resize(320x240+flop)/user.jpg ## this URL fails .. no direct > commands! > > > Thanks again, > Adam > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
There''s a new version of the ImageMagick extension available at: http://vantulder.net/rails/magick/ Here follows a relatively long message discussing the changes that were suggested by Tomas and Adam. On 9/16/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > What if you have images stored in a db though? > > It''d be possible if you were able to pass the url_for the action which > retrieves the image from the db.You can now combine the ImageMagick extension with your own action. If you have an action that somehow retrieves an image and sends it, ImageMagick can be coupled to that function using an after_filter. An example: # the controller class Photo < ApplicationController imagemagick_filter_for :display_picture def display_image # this function retrieves the image from the database and # sends it to the browser end end # the view <%= imagemagick_tag :action=>''display_image'', :id=>@photo.id, :commands=>''resize(100)'' %> imagemagick_filter_for adds the imagemagick method to the display_image action (using after_filter). This action gives the image to the imagemagick method, which processes it using the commands found in @params[''commands''] (you can change the name of that parameter). It then sends the updated image. imagemagick_tag accepts a hash of url_for options. All options are for the action, except for the ''commands'' option that is used by imagemagick. With this filter approach, it''s be possible to process images from a database.> Also, what if you have images but they''re not all stored in the same > directory? How about a way to pass images with a full path instead of > assuming they''re all in the same directory?In the last two versions, you can open images in subdirectories of the directory you gave to imagemagick_for. I think that''s enough: one, you don''t want your visitors to view all images on your server, you''ll want to limit that to images in a certain directory; two, if you really want to process all images, you can specify / as the image directory. On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> - In an effort to reduce code, could there be a way to declare ''recipes'' in > a server-side config file?That''s possible now. There is a GlobalRecipes list to which you can add recipes that have to be used in all controllers. It works somewhat like adding Routes: # somewhere in your environment.rb ActionController::Macros::ImageMagick::GlobalRecipes.add do |recipes| recipes.add :customthumbnail, ''resize(100x100)'' recipes.add :myborder, Proc.new { |image| image.border(1, 1, ''#f00") } end The recipes ''customthumbnail'' and ''myborder'' are now available in every controller that uses imagemagick_for.> - Could there be a global option that can be turned on/off so that URLs can > only be called with a recipe? ie:That, too, can be done in the new version. There are three levels of recipes, from high to low: builtin, global and local recipes. You can specify the maximum level in the options hash of imagemagick_for. For example, to allow only local and global recipes, you''d do: # the controller class Photo < ApplicationController imagemagick_for ''/var/lib/photos'', :max_recipe_level=>:global end Now only recipes that are in the global or local RecipeSet may be used. On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> #1. On my production server using lighttpd (and even with webrick,too), > sometimes ''render :file'' was trying to send a template if use_cache was > turned on and the file existed (that is, the second hit to the image caused > a big mess in the log and a broken image).Are you referring to the main Rails cache, or to the cache of imagemagick_for? Anyhow, in this new version render(:file) isn''t used anymore, it''s all render(:text). Even if an image is cached, it is read first and then rendered with render(:text). This was needed to implement the after_filter, but it might also solve your problem.> #2. It would be very cool if the route trick could be smart about > subdirectories. This is what I want my URL to be: > > /profile/pics/small/39/303/filename.jpg > /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filenameThat''s still a problem. I''m not enough at home in the Routes class to know if there''s something to do about that. If you simply send the commands and filename strings to url_for they get escaped, and the routes thing would get upset if they weren''t. If you really want clean urls, you could also do a little more work and go the filter way: Write an action that accepts :object_id, :picture_id and :filename and on with that information opens and sends the image. Then add the imagemagick behaviour as a filter. Something like this: # the controller class Profile < ApplicationController imagemagick_filter_for :pics, def pics filename = ''/var/pics/'' filename += @params[:object_id] + "/" filename += @params[:picture_id] + "/" filename += @params[:filename] render :file=>filename end end # the view <%= imagemagick_tag :action=>''pics'', :object_id=>1, :picture_id=>2, :filename=>''img.jpg'', :commands=>''small'' %> # the route /profile/pics/:commands/:object_id/:picture_id:/:filename # this would give your image the url /profile/pics/small/1/2/img.jpg It''s a little more work, as you have to do the image opening, but it does exactly what you want.> #3. I reiterate my desire for a global config where I could set action_name, > root directory for images (that can be aware of sub dirs..), cache directory > for images, global recipes... and then in each controller I''d only have to > set: imagemagick_for, and perhaps some specific recipes.You can set the global caching, recipes and some other configuration options by changing the DEFAULT_OPTIONS hash: ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:cache] = ''/tmp/cache'' ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:max_recipe_level] = :global In the controller, you still need to set the image directory: imagemagick_for ''/var/lib/photos'' is now the same as imagemagick_for ''/var/lib/photos'', :cache=>''/tmp/cache'', :max_recipe_level=>:global> #4. Other concern, if I change a recipe and the image is cached -- is your > code smart enough to realize it should regenerate the image.. or should I > delete the cached images?No, it wasn''t. It is now a little smarter, in the way that it notices when String-recipes are changed. If you have this: imagemagick_recipe :small, "resize(100x100)" and change that to: imagemagick_recipe :small, "resize(150x150)" you don''t have to empty the cache. For other types of recipes it''s more difficult, as you can''t see what''s in a Proc or Method. I''ve added a version numbering system as a workaround: imagemagick_recipe :small, Proc.new { |img| img.resize!(100, 100) }, ''version1'' change that to: imagemagick_recipe :small, Proc.new { |img| img.resize!(150, 150) }, ''version2'' and you don''t have to clean the cache. It''s not a nice solution, I know, but it works. If you don''t like it, you can always clean the cache by hand. And if you limit yourself to writing String-recipes, you''re fine. Thanks for the suggestions (and for reading this way too long message). You can find the new gems at: http://vantulder.net/rails/magick/ Gijs
Gijs, I''ve finally had a little time to experiment with this again. But before I forget, there was a problem when I tried to implement the filter solution you suggested with my version of rails. Here is the relevant development.log output: NoMethodError (undefined method `md5'' for Digest::MD5:Class): /usr/local/lib/ruby/gems/1.8/gems/actionpack-imagemagick-0.4/lib/image_magick.rb:375:in `imagemagick_after_filter'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-imagemagick-0.4/lib/image_magick.rb:368:in `imagemagick_after_filter'' (Gem install of rails-0.13.1) I googled the problem and found that others have had the same issue when installing Typo: http://rubyforge.org/pipermail/typo-list/2005-August/000376.html My solution: I edited ''image_magick.rb'' - identification = MD5.md5(@response.body).to_s + identification = Digest::MD5.new(@response.body).to_s As for other issues: - I see that you alias resize, change_geometry, etc.. all into one. Is there a way to force a size? ie, if i say 10x10 I really want 10x10 (ie: resize!(10x10) )... if this already works, just give me the heads up. - If I have a 320x320 image..and a recipe says to resize it to 640x480, is there a way to prohibit this? I only want to resize LOWER, not higher. I know this requires additional logic beyond what RMagick offers out of the box -- but how would you suggest we handle it using your module? - Images that don''t exist: If a user hits a URL for ''logo.png'' with recipe ''small'', and for some reason that image doesn''t exist, i''d like it to hit a MISSING_IMAGE_PATH that I define (which would be an image, the same size as the ''small'' recipe indicating that the picture is missing). Thanks Adam On 9/17/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > There''s a new version of the ImageMagick extension available at: > http://vantulder.net/rails/magick/ > > > Here follows a relatively long message discussing the changes that > were suggested by Tomas and Adam. > > > On 9/16/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > What if you have images stored in a db though? > > > > It''d be possible if you were able to pass the url_for the action which > > retrieves the image from the db. > > You can now combine the ImageMagick extension with your own action. If > you have an action that somehow retrieves an image and sends it, > ImageMagick can be coupled to that function using an after_filter. > > An example: > > # the controller > class Photo < ApplicationController > imagemagick_filter_for :display_picture > > def display_image > # this function retrieves the image from the database and > # sends it to the browser > end > end > > # the view > <%= imagemagick_tag :action=>''display_image'', :id=>@photo.id<http://photo.id> > , > :commands=>''resize(100)'' %> > > imagemagick_filter_for adds the imagemagick method to the > display_image action (using after_filter). This action gives the image > to the imagemagick method, which processes it using the commands found > in @params[''commands''] (you can change the name of that parameter). It > then sends the updated image. > > imagemagick_tag accepts a hash of url_for options. All options are for > the action, except for the ''commands'' option that is used by > imagemagick. > > With this filter approach, it''s be possible to process images from a > database. > > > > Also, what if you have images but they''re not all stored in the same > > directory? How about a way to pass images with a full path instead of > > assuming they''re all in the same directory? > > In the last two versions, you can open images in subdirectories of the > directory you gave to imagemagick_for. I think that''s enough: one, you > don''t want your visitors to view all images on your server, you''ll > want to limit that to images in a certain directory; two, if you > really want to process all images, you can specify / as the image > directory. > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > - In an effort to reduce code, could there be a way to declare ''recipes'' > in > > a server-side config file? > > That''s possible now. There is a GlobalRecipes list to which you can > add recipes that have to be used in all controllers. It works somewhat > like adding Routes: > > # somewhere in your environment.rb > ActionController::Macros::ImageMagick::GlobalRecipes.add do |recipes| > recipes.add :customthumbnail, ''resize(100x100)'' > recipes.add :myborder, Proc.new { |image| image.border(1, 1, ''#f00") } > end > > The recipes ''customthumbnail'' and ''myborder'' are now available in > every controller that uses imagemagick_for. > > > > - Could there be a global option that can be turned on/off so that URLs > can > > only be called with a recipe? ie: > > That, too, can be done in the new version. There are three levels of > recipes, from high to low: builtin, global and local recipes. You can > specify the maximum level in the options hash of imagemagick_for. For > example, to allow only local and global recipes, you''d do: > > # the controller > class Photo < ApplicationController > imagemagick_for ''/var/lib/photos'', :max_recipe_level=>:global > end > > Now only recipes that are in the global or local RecipeSet may be used. > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > #1. On my production server using lighttpd (and even with webrick,too), > > sometimes ''render :file'' was trying to send a template if use_cache was > > turned on and the file existed (that is, the second hit to the image > caused > > a big mess in the log and a broken image). > > Are you referring to the main Rails cache, or to the cache of > imagemagick_for? Anyhow, in this new version render(:file) isn''t used > anymore, it''s all render(:text). Even if an image is cached, it is > read first and then rendered with render(:text). This was needed to > implement the after_filter, but it might also solve your problem. > > > > #2. It would be very cool if the route trick could be smart about > > subdirectories. This is what I want my URL to be: > > > > /profile/pics/small/39/303/filename.jpg > > /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filename > > That''s still a problem. I''m not enough at home in the Routes class to > know if there''s something to do about that. If you simply send the > commands and filename strings to url_for they get escaped, and the > routes thing would get upset if they weren''t. > > If you really want clean urls, you could also do a little more work > and go the filter way: Write an action that accepts :object_id, > :picture_id and :filename and on with that information opens and sends > the image. Then add the imagemagick behaviour as a filter. Something > like this: > > # the controller > class Profile < ApplicationController > imagemagick_filter_for :pics, > > def pics > filename = ''/var/pics/'' > filename += @params[:object_id] + "/" > filename += @params[:picture_id] + "/" > filename += @params[:filename] > > render :file=>filename > end > end > > # the view > <%= imagemagick_tag :action=>''pics'', :object_id=>1, :picture_id=>2, > :filename=>''img.jpg'', :commands=>''small'' %> > > # the route > /profile/pics/:commands/:object_id/:picture_id:/:filename > > # this would give your image the url > /profile/pics/small/1/2/img.jpg > > It''s a little more work, as you have to do the image opening, but it > does exactly what you want. > > > > #3. I reiterate my desire for a global config where I could set > action_name, > > root directory for images (that can be aware of sub dirs..), cache > directory > > for images, global recipes... and then in each controller I''d only have > to > > set: imagemagick_for, and perhaps some specific recipes. > > You can set the global caching, recipes and some other configuration > options by changing the DEFAULT_OPTIONS hash: > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:cache] > ''/tmp/cache'' > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:max_recipe_level] > = :global > > In the controller, you still need to set the image directory: > > imagemagick_for ''/var/lib/photos'' > > is now the same as > > imagemagick_for ''/var/lib/photos'', :cache=>''/tmp/cache'', > :max_recipe_level=>:global > > > > > #4. Other concern, if I change a recipe and the image is cached -- is > your > > code smart enough to realize it should regenerate the image.. or should > I > > delete the cached images? > > No, it wasn''t. It is now a little smarter, in the way that it notices > when String-recipes are changed. If you have this: > > imagemagick_recipe :small, "resize(100x100)" > > and change that to: > > imagemagick_recipe :small, "resize(150x150)" > > you don''t have to empty the cache. For other types of recipes it''s > more difficult, as you can''t see what''s in a Proc or Method. I''ve > added a version numbering system as a workaround: > > imagemagick_recipe :small, Proc.new { |img| img.resize!(100, 100) }, > ''version1'' > > change that to: > > imagemagick_recipe :small, Proc.new { |img| img.resize!(150, 150) }, > ''version2'' > > and you don''t have to clean the cache. It''s not a nice solution, I > know, but it works. If you don''t like it, you can always clean the > cache by hand. And if you limit yourself to writing String-recipes, > you''re fine. > > > Thanks for the suggestions (and for reading this way too long message). > > You can find the new gems at: http://vantulder.net/rails/magick/ > > Gijs > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I don''t know if you guys saw it, but I posted an imagemagick extension for file_column to this list. Might be a good way to get stuff done without sacrificing MVC. Kyle Maxwell On 9/21/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Gijs, > > I''ve finally had a little time to experiment with this again. But before I > forget, there was a problem when I tried to implement the filter solution > you suggested with my version of rails. > > Here is the relevant development.log output: > > NoMethodError (undefined method `md5'' for Digest::MD5:Class): > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-imagemagick-0.4/lib/image_magick.rb:375:in > `imagemagick_after_filter'' > /usr/local/lib/ruby/gems/1.8/gems/actionpack- > imagemagick-0.4/lib/image_magick.rb:368:in `imagemagick_after_filter'' > > > (Gem install of rails-0.13.1) > > I googled the problem and found that others have had the same issue when > installing Typo: > > http://rubyforge.org/pipermail/typo-list/2005-August/000376.html > > > My solution: I edited ''image_magick.rb'' > > - identification = MD5.md5(@response.body).to_s > + identification = Digest::MD5.new(@response.body ).to_s > > As for other issues: > > - I see that you alias resize, change_geometry, etc.. all into one. Is there > a way to force a size? ie, if i say 10x10 I really want 10x10 (ie: > resize!(10x10) )... if this already works, just give me the heads up. > > - If I have a 320x320 image..and a recipe says to resize it to 640x480, is > there a way to prohibit this? I only want to resize LOWER, not higher. I > know this requires additional logic beyond what RMagick offers out of the > box -- but how would you suggest we handle it using your module? > > - Images that don''t exist: If a user hits a URL for ''logo.png'' with recipe > ''small'', and for some reason that image doesn''t exist, i''d like it to hit a > MISSING_IMAGE_PATH that I define (which would be an image, the same size as > the ''small'' recipe indicating that the picture is missing). > > Thanks > Adam > > > > > > > > > > On 9/17/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > There''s a new version of the ImageMagick extension available at: > > http://vantulder.net/rails/magick/ > > > > > > Here follows a relatively long message discussing the changes that > > were suggested by Tomas and Adam. > > > > > > On 9/16/05, Tomas Jogin < tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > What if you have images stored in a db though? > > > > > > It''d be possible if you were able to pass the url_for the action which > > > retrieves the image from the db. > > > > You can now combine the ImageMagick extension with your own action. If > > you have an action that somehow retrieves an image and sends it, > > ImageMagick can be coupled to that function using an after_filter. > > > > An example: > > > > # the controller > > class Photo < ApplicationController > > imagemagick_filter_for :display_picture > > > > def display_image > > # this function retrieves the image from the database and > > # sends it to the browser > > end > > end > > > > # the view > > <%= imagemagick_tag :action=>''display_image'', :id=>@photo.id, > > :commands=>''resize(100)'' %> > > > > imagemagick_filter_for adds the imagemagick method to the > > display_image action (using after_filter). This action gives the image > > to the imagemagick method, which processes it using the commands found > > in @params[''commands''] (you can change the name of that parameter). It > > then sends the updated image. > > > > imagemagick_tag accepts a hash of url_for options. All options are for > > the action, except for the ''commands'' option that is used by > > imagemagick. > > > > With this filter approach, it''s be possible to process images from a > database. > > > > > > > Also, what if you have images but they''re not all stored in the same > > > directory? How about a way to pass images with a full path instead of > > > assuming they''re all in the same directory? > > > > In the last two versions, you can open images in subdirectories of the > > directory you gave to imagemagick_for. I think that''s enough: one, you > > don''t want your visitors to view all images on your server, you''ll > > want to limit that to images in a certain directory; two, if you > > really want to process all images, you can specify / as the image > > directory. > > > > > > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > - In an effort to reduce code, could there be a way to declare ''recipes'' > in > > > a server-side config file? > > > > That''s possible now. There is a GlobalRecipes list to which you can > > add recipes that have to be used in all controllers. It works somewhat > > like adding Routes: > > > > # somewhere in your environment.rb > > > ActionController::Macros::ImageMagick::GlobalRecipes.add do > |recipes| > > recipes.add :customthumbnail, ''resize(100x100)'' > > recipes.add :myborder, Proc.new { |image| image.border(1, 1, ''#f00") } > > end > > > > The recipes ''customthumbnail'' and ''myborder'' are now available in > > every controller that uses imagemagick_for. > > > > > > > - Could there be a global option that can be turned on/off so that URLs > can > > > only be called with a recipe? ie: > > > > That, too, can be done in the new version. There are three levels of > > recipes, from high to low: builtin, global and local recipes. You can > > specify the maximum level in the options hash of imagemagick_for. For > > example, to allow only local and global recipes, you''d do: > > > > # the controller > > class Photo < ApplicationController > > imagemagick_for ''/var/lib/photos'', :max_recipe_level=>:global > > end > > > > Now only recipes that are in the global or local RecipeSet may be used. > > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > #1. On my production server using lighttpd (and even with webrick,too), > > > sometimes ''render :file'' was trying to send a template if use_cache was > > > turned on and the file existed (that is, the second hit to the image > caused > > > a big mess in the log and a broken image). > > > > Are you referring to the main Rails cache, or to the cache of > > imagemagick_for? Anyhow, in this new version render(:file) isn''t used > > anymore, it''s all render(:text). Even if an image is cached, it is > > read first and then rendered with render(:text). This was needed to > > implement the after_filter, but it might also solve your problem. > > > > > > > #2. It would be very cool if the route trick could be smart about > > > subdirectories. This is what I want my URL to be: > > > > > > /profile/pics/small/39/303/filename.jpg > > > > /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filename > > > > That''s still a problem. I''m not enough at home in the Routes class to > > know if there''s something to do about that. If you simply send the > > commands and filename strings to url_for they get escaped, and the > > routes thing would get upset if they weren''t. > > > > If you really want clean urls, you could also do a little more work > > and go the filter way: Write an action that accepts :object_id, > > :picture_id and :filename and on with that information opens and sends > > the image. Then add the imagemagick behaviour as a filter. Something > > like this: > > > > # the controller > > class Profile < ApplicationController > > imagemagick_filter_for :pics, > > > > def pics > > filename = ''/var/pics/'' > > filename += @params[:object_id] + "/" > > filename += @params[:picture_id] + "/" > > filename += @params[:filename] > > > > render :file=>filename > > end > > end > > > > # the view > > <%= imagemagick_tag :action=>''pics'', :object_id=>1, :picture_id=>2, > > :filename=>''img.jpg'', :commands=>''small'' %> > > > > # the route > > > /profile/pics/:commands/:object_id/:picture_id:/:filename > > > > # this would give your image the url > > /profile/pics/small/1/2/img.jpg > > > > It''s a little more work, as you have to do the image opening, but it > > does exactly what you want. > > > > > > > #3. I reiterate my desire for a global config where I could set > action_name, > > > root directory for images (that can be aware of sub dirs..), cache > directory > > > for images, global recipes... and then in each controller I''d only have > to > > > set: imagemagick_for, and perhaps some specific recipes. > > > > You can set the global caching, recipes and some other configuration > > options by changing the DEFAULT_OPTIONS hash: > > > > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:cache] > = ''/tmp/cache'' > > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:max_recipe_level] > > = :global > > > > In the controller, you still need to set the image directory: > > > > imagemagick_for ''/var/lib/photos'' > > > > is now the same as > > > > imagemagick_for ''/var/lib/photos'', :cache=>''/tmp/cache'', > > :max_recipe_level=>:global > > > > > > > > > #4. Other concern, if I change a recipe and the image is cached -- is > your > > > code smart enough to realize it should regenerate the image.. or should > I > > > delete the cached images? > > > > No, it wasn''t. It is now a little smarter, in the way that it notices > > when String-recipes are changed. If you have this: > > > > imagemagick_recipe :small, "resize(100x100)" > > > > and change that to: > > > > imagemagick_recipe :small, "resize(150x150)" > > > > you don''t have to empty the cache. For other types of recipes it''s > > more difficult, as you can''t see what''s in a Proc or Method. I''ve > > added a version numbering system as a workaround: > > > > imagemagick_recipe :small, Proc.new { |img| img.resize!(100, 100) }, > > ''version1'' > > > > change that to: > > > > imagemagick_recipe :small, Proc.new { |img| img.resize!(150, 150) }, > > ''version2'' > > > > and you don''t have to clean the cache. It''s not a nice solution, I > > know, but it works. If you don''t like it, you can always clean the > > cache by hand. And if you limit yourself to writing String-recipes, > > you''re fine. > > > > > > Thanks for the suggestions (and for reading this way too long message). > > > > You can find the new gems at: > http://vantulder.net/rails/magick/ > > > > Gijs > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Kyle Yes, I saw it... but I''m dealing with a fairly custom solution where each model can have many pics. Can file_column support multiple pics per model, multiple thumbnails per pic (custom sizes per model) and http uploads all without me breaking a sweat? Adam On 9/21/05, Kyle Maxwell <kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:> > I don''t know if you guys saw it, but I posted an imagemagick extension > for file_column to this list. Might be a good way to get stuff done > without sacrificing MVC. > > Kyle Maxwell > > On 9/21/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Gijs, > > > > I''ve finally had a little time to experiment with this again. But before > I > > forget, there was a problem when I tried to implement the filter > solution > > you suggested with my version of rails. > > > > Here is the relevant development.log output: > > > > NoMethodError (undefined method `md5'' for Digest::MD5:Class): > > > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-imagemagick-0.4 > /lib/image_magick.rb:375:in > > `imagemagick_after_filter'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack- > > imagemagick-0.4/lib/image_magick.rb:368:in `imagemagick_after_filter'' > > > > > > (Gem install of rails-0.13.1) > > > > I googled the problem and found that others have had the same issue when > > installing Typo: > > > > http://rubyforge.org/pipermail/typo-list/2005-August/000376.html > > > > > > My solution: I edited ''image_magick.rb'' > > > > - identification = MD5.md5(@response.body).to_s > > + identification = Digest::MD5.new(@response.body ).to_s > > > > As for other issues: > > > > - I see that you alias resize, change_geometry, etc.. all into one. Is > there > > a way to force a size? ie, if i say 10x10 I really want 10x10 (ie: > > resize!(10x10) )... if this already works, just give me the heads up. > > > > - If I have a 320x320 image..and a recipe says to resize it to 640x480, > is > > there a way to prohibit this? I only want to resize LOWER, not higher. I > > know this requires additional logic beyond what RMagick offers out of > the > > box -- but how would you suggest we handle it using your module? > > > > - Images that don''t exist: If a user hits a URL for ''logo.png'' with > recipe > > ''small'', and for some reason that image doesn''t exist, i''d like it to > hit a > > MISSING_IMAGE_PATH that I define (which would be an image, the same size > as > > the ''small'' recipe indicating that the picture is missing). > > > > Thanks > > Adam > > > > > > > > > > > > > > > > > > > > On 9/17/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > There''s a new version of the ImageMagick extension available at: > > > http://vantulder.net/rails/magick/ > > > > > > > > > Here follows a relatively long message discussing the changes that > > > were suggested by Tomas and Adam. > > > > > > > > > On 9/16/05, Tomas Jogin < tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > What if you have images stored in a db though? > > > > > > > > It''d be possible if you were able to pass the url_for the action > which > > > > retrieves the image from the db. > > > > > > You can now combine the ImageMagick extension with your own action. If > > > you have an action that somehow retrieves an image and sends it, > > > ImageMagick can be coupled to that function using an after_filter. > > > > > > An example: > > > > > > # the controller > > > class Photo < ApplicationController > > > imagemagick_filter_for :display_picture > > > > > > def display_image > > > # this function retrieves the image from the database and > > > # sends it to the browser > > > end > > > end > > > > > > # the view > > > <%= imagemagick_tag :action=>''display_image'', :id=>@photo.id<http://photo.id> > , > > > :commands=>''resize(100)'' %> > > > > > > imagemagick_filter_for adds the imagemagick method to the > > > display_image action (using after_filter). This action gives the image > > > to the imagemagick method, which processes it using the commands found > > > in @params[''commands''] (you can change the name of that parameter). It > > > then sends the updated image. > > > > > > imagemagick_tag accepts a hash of url_for options. All options are for > > > the action, except for the ''commands'' option that is used by > > > imagemagick. > > > > > > With this filter approach, it''s be possible to process images from a > > database. > > > > > > > > > > Also, what if you have images but they''re not all stored in the same > > > > directory? How about a way to pass images with a full path instead > of > > > > assuming they''re all in the same directory? > > > > > > In the last two versions, you can open images in subdirectories of the > > > directory you gave to imagemagick_for. I think that''s enough: one, you > > > don''t want your visitors to view all images on your server, you''ll > > > want to limit that to images in a certain directory; two, if you > > > really want to process all images, you can specify / as the image > > > directory. > > > > > > > > > > > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > - In an effort to reduce code, could there be a way to declare > ''recipes'' > > in > > > > a server-side config file? > > > > > > That''s possible now. There is a GlobalRecipes list to which you can > > > add recipes that have to be used in all controllers. It works somewhat > > > like adding Routes: > > > > > > # somewhere in your environment.rb > > > > > ActionController::Macros::ImageMagick::GlobalRecipes.add do > > |recipes| > > > recipes.add :customthumbnail, ''resize(100x100)'' > > > recipes.add :myborder, Proc.new { |image| image.border(1, 1, ''#f00") } > > > end > > > > > > The recipes ''customthumbnail'' and ''myborder'' are now available in > > > every controller that uses imagemagick_for. > > > > > > > > > > - Could there be a global option that can be turned on/off so that > URLs > > can > > > > only be called with a recipe? ie: > > > > > > That, too, can be done in the new version. There are three levels of > > > recipes, from high to low: builtin, global and local recipes. You can > > > specify the maximum level in the options hash of imagemagick_for. For > > > example, to allow only local and global recipes, you''d do: > > > > > > # the controller > > > class Photo < ApplicationController > > > imagemagick_for ''/var/lib/photos'', :max_recipe_level=>:global > > > end > > > > > > Now only recipes that are in the global or local RecipeSet may be > used. > > > > > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > #1. On my production server using lighttpd (and even with > webrick,too), > > > > sometimes ''render :file'' was trying to send a template if use_cache > was > > > > turned on and the file existed (that is, the second hit to the image > > caused > > > > a big mess in the log and a broken image). > > > > > > Are you referring to the main Rails cache, or to the cache of > > > imagemagick_for? Anyhow, in this new version render(:file) isn''t used > > > anymore, it''s all render(:text). Even if an image is cached, it is > > > read first and then rendered with render(:text). This was needed to > > > implement the after_filter, but it might also solve your problem. > > > > > > > > > > #2. It would be very cool if the route trick could be smart about > > > > subdirectories. This is what I want my URL to be: > > > > > > > > /profile/pics/small/39/303/filename.jpg > > > > > > /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filename > > > > > > That''s still a problem. I''m not enough at home in the Routes class to > > > know if there''s something to do about that. If you simply send the > > > commands and filename strings to url_for they get escaped, and the > > > routes thing would get upset if they weren''t. > > > > > > If you really want clean urls, you could also do a little more work > > > and go the filter way: Write an action that accepts :object_id, > > > :picture_id and :filename and on with that information opens and sends > > > the image. Then add the imagemagick behaviour as a filter. Something > > > like this: > > > > > > # the controller > > > class Profile < ApplicationController > > > imagemagick_filter_for :pics, > > > > > > def pics > > > filename = ''/var/pics/'' > > > filename += @params[:object_id] + "/" > > > filename += @params[:picture_id] + "/" > > > filename += @params[:filename] > > > > > > render :file=>filename > > > end > > > end > > > > > > # the view > > > <%= imagemagick_tag :action=>''pics'', :object_id=>1, :picture_id=>2, > > > :filename=>''img.jpg'', :commands=>''small'' %> > > > > > > # the route > > > > > /profile/pics/:commands/:object_id/:picture_id:/:filename > > > > > > # this would give your image the url > > > /profile/pics/small/1/2/img.jpg > > > > > > It''s a little more work, as you have to do the image opening, but it > > > does exactly what you want. > > > > > > > > > > #3. I reiterate my desire for a global config where I could set > > action_name, > > > > root directory for images (that can be aware of sub dirs..), cache > > directory > > > > for images, global recipes... and then in each controller I''d only > have > > to > > > > set: imagemagick_for, and perhaps some specific recipes. > > > > > > You can set the global caching, recipes and some other configuration > > > options by changing the DEFAULT_OPTIONS hash: > > > > > > > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:cache] > > = ''/tmp/cache'' > > > > > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:max_recipe_level] > > > = :global > > > > > > In the controller, you still need to set the image directory: > > > > > > imagemagick_for ''/var/lib/photos'' > > > > > > is now the same as > > > > > > imagemagick_for ''/var/lib/photos'', :cache=>''/tmp/cache'', > > > :max_recipe_level=>:global > > > > > > > > > > > > > #4. Other concern, if I change a recipe and the image is cached -- > is > > your > > > > code smart enough to realize it should regenerate the image.. or > should > > I > > > > delete the cached images? > > > > > > No, it wasn''t. It is now a little smarter, in the way that it notices > > > when String-recipes are changed. If you have this: > > > > > > imagemagick_recipe :small, "resize(100x100)" > > > > > > and change that to: > > > > > > imagemagick_recipe :small, "resize(150x150)" > > > > > > you don''t have to empty the cache. For other types of recipes it''s > > > more difficult, as you can''t see what''s in a Proc or Method. I''ve > > > added a version numbering system as a workaround: > > > > > > imagemagick_recipe :small, Proc.new { |img| img.resize!(100, 100) }, > > > ''version1'' > > > > > > change that to: > > > > > > imagemagick_recipe :small, Proc.new { |img| img.resize!(150, 150) }, > > > ''version2'' > > > > > > and you don''t have to clean the cache. It''s not a nice solution, I > > > know, but it works. If you don''t like it, you can always clean the > > > cache by hand. And if you limit yourself to writing String-recipes, > > > you''re fine. > > > > > > > > > Thanks for the suggestions (and for reading this way too long > message). > > > > > > You can find the new gems at: > > http://vantulder.net/rails/magick/ > > > > > > Gijs > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Gijs Another thing, jpegs don''t work with render :file -- whereas pngs do. render :file => "/tmp/i_am_a_png.png" ## works fine render :file => "/tmp/i_am_a_jpg.jpg" ## trys to send the file as a template... without fail. doesnt autodetect jpeg? I''m using the filter method -- so I can''t use send_file Any solution to this? Adam On 9/17/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > There''s a new version of the ImageMagick extension available at: > http://vantulder.net/rails/magick/ > > > Here follows a relatively long message discussing the changes that > were suggested by Tomas and Adam. > > > On 9/16/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > What if you have images stored in a db though? > > > > It''d be possible if you were able to pass the url_for the action which > > retrieves the image from the db. > > You can now combine the ImageMagick extension with your own action. If > you have an action that somehow retrieves an image and sends it, > ImageMagick can be coupled to that function using an after_filter. > > An example: > > # the controller > class Photo < ApplicationController > imagemagick_filter_for :display_picture > > def display_image > # this function retrieves the image from the database and > # sends it to the browser > end > end > > # the view > <%= imagemagick_tag :action=>''display_image'', :id=>@photo.id<http://photo.id> > , > :commands=>''resize(100)'' %> > > imagemagick_filter_for adds the imagemagick method to the > display_image action (using after_filter). This action gives the image > to the imagemagick method, which processes it using the commands found > in @params[''commands''] (you can change the name of that parameter). It > then sends the updated image. > > imagemagick_tag accepts a hash of url_for options. All options are for > the action, except for the ''commands'' option that is used by > imagemagick. > > With this filter approach, it''s be possible to process images from a > database. > > > > Also, what if you have images but they''re not all stored in the same > > directory? How about a way to pass images with a full path instead of > > assuming they''re all in the same directory? > > In the last two versions, you can open images in subdirectories of the > directory you gave to imagemagick_for. I think that''s enough: one, you > don''t want your visitors to view all images on your server, you''ll > want to limit that to images in a certain directory; two, if you > really want to process all images, you can specify / as the image > directory. > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > - In an effort to reduce code, could there be a way to declare ''recipes'' > in > > a server-side config file? > > That''s possible now. There is a GlobalRecipes list to which you can > add recipes that have to be used in all controllers. It works somewhat > like adding Routes: > > # somewhere in your environment.rb > ActionController::Macros::ImageMagick::GlobalRecipes.add do |recipes| > recipes.add :customthumbnail, ''resize(100x100)'' > recipes.add :myborder, Proc.new { |image| image.border(1, 1, ''#f00") } > end > > The recipes ''customthumbnail'' and ''myborder'' are now available in > every controller that uses imagemagick_for. > > > > - Could there be a global option that can be turned on/off so that URLs > can > > only be called with a recipe? ie: > > That, too, can be done in the new version. There are three levels of > recipes, from high to low: builtin, global and local recipes. You can > specify the maximum level in the options hash of imagemagick_for. For > example, to allow only local and global recipes, you''d do: > > # the controller > class Photo < ApplicationController > imagemagick_for ''/var/lib/photos'', :max_recipe_level=>:global > end > > Now only recipes that are in the global or local RecipeSet may be used. > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > #1. On my production server using lighttpd (and even with webrick,too), > > sometimes ''render :file'' was trying to send a template if use_cache was > > turned on and the file existed (that is, the second hit to the image > caused > > a big mess in the log and a broken image). > > Are you referring to the main Rails cache, or to the cache of > imagemagick_for? Anyhow, in this new version render(:file) isn''t used > anymore, it''s all render(:text). Even if an image is cached, it is > read first and then rendered with render(:text). This was needed to > implement the after_filter, but it might also solve your problem. > > > > #2. It would be very cool if the route trick could be smart about > > subdirectories. This is what I want my URL to be: > > > > /profile/pics/small/39/303/filename.jpg > > /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filename > > That''s still a problem. I''m not enough at home in the Routes class to > know if there''s something to do about that. If you simply send the > commands and filename strings to url_for they get escaped, and the > routes thing would get upset if they weren''t. > > If you really want clean urls, you could also do a little more work > and go the filter way: Write an action that accepts :object_id, > :picture_id and :filename and on with that information opens and sends > the image. Then add the imagemagick behaviour as a filter. Something > like this: > > # the controller > class Profile < ApplicationController > imagemagick_filter_for :pics, > > def pics > filename = ''/var/pics/'' > filename += @params[:object_id] + "/" > filename += @params[:picture_id] + "/" > filename += @params[:filename] > > render :file=>filename > end > end > > # the view > <%= imagemagick_tag :action=>''pics'', :object_id=>1, :picture_id=>2, > :filename=>''img.jpg'', :commands=>''small'' %> > > # the route > /profile/pics/:commands/:object_id/:picture_id:/:filename > > # this would give your image the url > /profile/pics/small/1/2/img.jpg > > It''s a little more work, as you have to do the image opening, but it > does exactly what you want. > > > > #3. I reiterate my desire for a global config where I could set > action_name, > > root directory for images (that can be aware of sub dirs..), cache > directory > > for images, global recipes... and then in each controller I''d only have > to > > set: imagemagick_for, and perhaps some specific recipes. > > You can set the global caching, recipes and some other configuration > options by changing the DEFAULT_OPTIONS hash: > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:cache] > ''/tmp/cache'' > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:max_recipe_level] > = :global > > In the controller, you still need to set the image directory: > > imagemagick_for ''/var/lib/photos'' > > is now the same as > > imagemagick_for ''/var/lib/photos'', :cache=>''/tmp/cache'', > :max_recipe_level=>:global > > > > > #4. Other concern, if I change a recipe and the image is cached -- is > your > > code smart enough to realize it should regenerate the image.. or should > I > > delete the cached images? > > No, it wasn''t. It is now a little smarter, in the way that it notices > when String-recipes are changed. If you have this: > > imagemagick_recipe :small, "resize(100x100)" > > and change that to: > > imagemagick_recipe :small, "resize(150x150)" > > you don''t have to empty the cache. For other types of recipes it''s > more difficult, as you can''t see what''s in a Proc or Method. I''ve > added a version numbering system as a workaround: > > imagemagick_recipe :small, Proc.new { |img| img.resize!(100, 100) }, > ''version1'' > > change that to: > > imagemagick_recipe :small, Proc.new { |img| img.resize!(150, 150) }, > ''version2'' > > and you don''t have to clean the cache. It''s not a nice solution, I > know, but it works. If you don''t like it, you can always clean the > cache by hand. And if you limit yourself to writing String-recipes, > you''re fine. > > > Thanks for the suggestions (and for reading this way too long message). > > You can find the new gems at: http://vantulder.net/rails/magick/ > > Gijs > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
not sure about the full capabilities of file_column.. but i do think it supports multiple images.. you just need a column for each image in your db.. not sure if thats the best solution. On 9/21/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Kyle > > Yes, I saw it... but I''m dealing with a fairly custom solution where each > model can have many pics. Can file_column support multiple pics per model, > multiple thumbnails per pic (custom sizes per model) and http uploads all > without me breaking a sweat? > > Adam > > > > On 9/21/05, Kyle Maxwell <kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote: > > I don''t know if you guys saw it, but I posted an imagemagick extension > > for file_column to this list. Might be a good way to get stuff done > > without sacrificing MVC. > > > > Kyle Maxwell > > > > On 9/21/05, Adam Roth < adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Gijs, > > > > > > I''ve finally had a little time to experiment with this again. But before > I > > > forget, there was a problem when I tried to implement the filter > solution > > > you suggested with my version of rails. > > > > > > Here is the relevant development.log output: > > > > > > NoMethodError (undefined method `md5'' for Digest::MD5:Class): > > > > > > /usr/local/lib/ruby/gems/1.8/gems/actionpack- > imagemagick-0.4/lib/image_magick.rb:375:in > > > `imagemagick_after_filter'' > > > /usr/local/lib/ruby/gems/1.8/gems/actionpack- > > > imagemagick-0.4/lib/image_magick.rb:368:in `imagemagick_after_filter'' > > > > > > > > > (Gem install of rails-0.13.1) > > > > > > I googled the problem and found that others have had the same issue when > > > installing Typo: > > > > > > > http://rubyforge.org/pipermail/typo-list/2005-August/000376.html > > > > > > > > > My solution: I edited ''image_magick.rb'' > > > > > > - identification = MD5.md5(@response.body).to_s > > > + identification = Digest:: MD5.new(@response.body ).to_s > > > > > > As for other issues: > > > > > > - I see that you alias resize, change_geometry, etc.. all into one. Is > there > > > a way to force a size? ie, if i say 10x10 I really want 10x10 (ie: > > > resize!(10x10) )... if this already works, just give me the heads up. > > > > > > - If I have a 320x320 image..and a recipe says to resize it to 640x480, > is > > > there a way to prohibit this? I only want to resize LOWER, not higher. I > > > know this requires additional logic beyond what RMagick offers out of > the > > > box -- but how would you suggest we handle it using your module? > > > > > > - Images that don''t exist: If a user hits a URL for '' logo.png'' with > recipe > > > ''small'', and for some reason that image doesn''t exist, i''d like it to > hit a > > > MISSING_IMAGE_PATH that I define (which would be an image, the same size > as > > > the ''small'' recipe indicating that the picture is missing). > > > > > > Thanks > > > Adam > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/17/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > There''s a new version of the ImageMagick extension available at: > > > > http://vantulder.net/rails/magick/ > > > > > > > > > > > > Here follows a relatively long message discussing the changes that > > > > were suggested by Tomas and Adam. > > > > > > > > > > > > On 9/16/05, Tomas Jogin < tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > What if you have images stored in a db though? > > > > > > > > > > It''d be possible if you were able to pass the url_for the action > which > > > > > retrieves the image from the db. > > > > > > > > You can now combine the ImageMagick extension with your own action. If > > > > you have an action that somehow retrieves an image and sends it, > > > > ImageMagick can be coupled to that function using an after_filter. > > > > > > > > An example: > > > > > > > > # the controller > > > > class Photo < ApplicationController > > > > imagemagick_filter_for :display_picture > > > > > > > > def display_image > > > > # this function retrieves the image from the database and > > > > # sends it to the browser > > > > end > > > > end > > > > > > > > # the view > > > > <%= imagemagick_tag :action=>''display_image'', :id=>@ photo.id, > > > > :commands=>''resize(100)'' %> > > > > > > > > imagemagick_filter_for adds the imagemagick method to the > > > > display_image action (using after_filter). This action gives the image > > > > to the imagemagick method, which processes it using the commands found > > > > in @params[''commands''] (you can change the name of that parameter). It > > > > then sends the updated image. > > > > > > > > imagemagick_tag accepts a hash of url_for options. All options are for > > > > the action, except for the ''commands'' option that is used by > > > > imagemagick. > > > > > > > > With this filter approach, it''s be possible to process images from a > > > database. > > > > > > > > > > > > > Also, what if you have images but they''re not all stored in the same > > > > > directory? How about a way to pass images with a full path instead > of > > > > > assuming they''re all in the same directory? > > > > > > > > In the last two versions, you can open images in subdirectories of the > > > > directory you gave to imagemagick_for. I think that''s enough: one, you > > > > don''t want your visitors to view all images on your server, you''ll > > > > want to limit that to images in a certain directory; two, if you > > > > really want to process all images, you can specify / as the image > > > > directory. > > > > > > > > > > > > > > > > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > - In an effort to reduce code, could there be a way to declare > ''recipes'' > > > in > > > > > a server-side config file? > > > > > > > > That''s possible now. There is a GlobalRecipes list to which you can > > > > add recipes that have to be used in all controllers. It works somewhat > > > > like adding Routes: > > > > > > > > # somewhere in your environment.rb > > > > > > > > ActionController::Macros::ImageMagick::GlobalRecipes.add do > > > |recipes| > > > > recipes.add :customthumbnail, ''resize(100x100)'' > > > > recipes.add :myborder, Proc.new { |image| image.border(1, 1, > ''#f00") } > > > > end > > > > > > > > The recipes ''customthumbnail'' and ''myborder'' are now available in > > > > every controller that uses imagemagick_for. > > > > > > > > > > > > > - Could there be a global option that can be turned on/off so that > URLs > > > can > > > > > only be called with a recipe? ie: > > > > > > > > That, too, can be done in the new version. There are three levels of > > > > recipes, from high to low: builtin, global and local recipes. You can > > > > specify the maximum level in the options hash of imagemagick_for. For > > > > example, to allow only local and global recipes, you''d do: > > > > > > > > # the controller > > > > class Photo < ApplicationController > > > > imagemagick_for ''/var/lib/photos'', :max_recipe_level=>:global > > > > end > > > > > > > > Now only recipes that are in the global or local RecipeSet may be > used. > > > > > > > > > > > > On 9/16/05, Adam Roth <adamjroth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > > #1. On my production server using lighttpd (and even with > webrick,too), > > > > > sometimes ''render :file'' was trying to send a template if use_cache > was > > > > > turned on and the file existed (that is, the second hit to the image > > > caused > > > > > a big mess in the log and a broken image). > > > > > > > > Are you referring to the main Rails cache, or to the cache of > > > > imagemagick_for? Anyhow, in this new version render(:file) isn''t used > > > > anymore, it''s all render(:text). Even if an image is cached, it is > > > > read first and then rendered with render(:text). This was needed to > > > > implement the after_filter, but it might also solve your problem. > > > > > > > > > > > > > #2. It would be very cool if the route trick could be smart about > > > > > subdirectories. This is what I want my URL to be: > > > > > > > > > > /profile/pics/small/39/303/filename.jpg > > > > > > > > > /:controller/:action_name/:recipe_name/:object_id/:picture_id:/:filename > > > > > > > > That''s still a problem. I''m not enough at home in the Routes class to > > > > know if there''s something to do about that. If you simply send the > > > > commands and filename strings to url_for they get escaped, and the > > > > routes thing would get upset if they weren''t. > > > > > > > > If you really want clean urls, you could also do a little more work > > > > and go the filter way: Write an action that accepts :object_id, > > > > :picture_id and :filename and on with that information opens and sends > > > > the image. Then add the imagemagick behaviour as a filter. Something > > > > like this: > > > > > > > > # the controller > > > > class Profile < ApplicationController > > > > imagemagick_filter_for :pics, > > > > > > > > def pics > > > > filename = ''/var/pics/'' > > > > filename += @params[:object_id] + "/" > > > > filename += @params[:picture_id] + "/" > > > > filename += @params[:filename] > > > > > > > > render :file=>filename > > > > end > > > > end > > > > > > > > # the view > > > > <%= imagemagick_tag :action=>''pics'', :object_id=>1, :picture_id=>2, > > > > :filename=>''img.jpg'', :commands=>''small'' %> > > > > > > > > # the route > > > > > > > > /profile/pics/:commands/:object_id/:picture_id:/:filename > > > > > > > > # this would give your image the url > > > > /profile/pics/small/1/2/img.jpg > > > > > > > > It''s a little more work, as you have to do the image opening, but it > > > > does exactly what you want. > > > > > > > > > > > > > #3. I reiterate my desire for a global config where I could set > > > action_name, > > > > > root directory for images (that can be aware of sub dirs..), cache > > > directory > > > > > for images, global recipes... and then in each controller I''d only > have > > > to > > > > > set: imagemagick_for, and perhaps some specific recipes. > > > > > > > > You can set the global caching, recipes and some other configuration > > > > options by changing the DEFAULT_OPTIONS hash: > > > > > > > > > > > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:cache] > > > = ''/tmp/cache'' > > > > > > > > ActionController::Macros::ImageMagick::DEFAULT_OPTIONS[:max_recipe_level] > > > > = :global > > > > > > > > In the controller, you still need to set the image directory: > > > > > > > > imagemagick_for ''/var/lib/photos'' > > > > > > > > is now the same as > > > > > > > > imagemagick_for ''/var/lib/photos'', :cache=>''/tmp/cache'', > > > > :max_recipe_level=>:global > > > > > > > > > > > > > > > > > #4. Other concern, if I change a recipe and the image is cached -- > is > > > your > > > > > code smart enough to realize it should regenerate the image.. or > should > > > I > > > > > delete the cached images? > > > > > > > > No, it wasn''t. It is now a little smarter, in the way that it notices > > > > when String-recipes are changed. If you have this: > > > > > > > > imagemagick_recipe :small, "resize(100x100)" > > > > > > > > and change that to: > > > > > > > > imagemagick_recipe :small, "resize(150x150)" > > > > > > > > you don''t have to empty the cache. For other types of recipes it''s > > > > more difficult, as you can''t see what''s in a Proc or Method. I''ve > > > > added a version numbering system as a workaround: > > > > > > > > imagemagick_recipe :small, Proc.new { |img| img.resize! (100, 100) > }, > > > > ''version1'' > > > > > > > > change that to: > > > > > > > > imagemagick_recipe :small, Proc.new { |img| img.resize!(150, 150) }, > > > > ''version2'' > > > > > > > > and you don''t have to clean the cache. It''s not a nice solution, I > > > > know, but it works. If you don''t like it, you can always clean the > > > > cache by hand. And if you limit yourself to writing String-recipes, > > > > you''re fine. > > > > > > > > > > > > Thanks for the suggestions (and for reading this way too long > message). > > > > > > > > You can find the new gems at: > > > http://vantulder.net/rails/magick/ > > > > > > > > Gijs > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- - Ramin http://www.getintothis.com/blog
So it came down to mime-type. This works: imagemagick_filter_for :pix, :cache => ''/tmp/cache'' def pix filename = ''/tmp/'' + @params[:object] + "/" + @params[:object_id] + "/" + @params[:picture_id] @response.headers["Content-type"] = "image/jpeg" render :file => filename end However -- how can I get this to use the cached image? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi Kyle,> I don''t know if you guys saw it, but I posted an imagemagick extension > for file_column to this list.Yes, I''ve seen it. (Not before sending my initial message, though. I did a search for imagemagick on gmane, but it didn''t give me any results. Perhaps it had an old index back then.) I think that whether you want to use render-on-upload or render-on-display depends on your needs. As you said, render-on-upload is probably a little faster and less cpu intensive, whereas render-on-display is perhaps a little slower. But on the other hand, render-on-display allows you to defer the decision on the image size to when you actually need them, whereas render-on-display requires you to think about the sizes you need before uploading the images. If you later want to change or add a size, you''ll have to re-render all your existing images if you''ve gone for render-on-upload. Thus, render-on-upload is a little bit faster, render-on-display is a little bit more flexible. Whether you need that flexibility or would rather choose the speed, depends on the needs of your project (and on how often you change your mind about the image size). For example, I''m using the render-on-display method (although not in Rails, but in PHP) in a cms I''ve built for a school. Images are uploaded in their original form, and then resized to the different sizes I need. I find it really convenient that I can just change the image size in the templates and it works, instead of having to bother with re-rendering every existing image to fit the new size. And except for the first-time rendering, there is no noticeable delay in loading the images. (But then, the site is not too busy, with only a 1000 students, the teachers and some parents. It might be different for a larger site.) So if you''re like me and tend to change your mind quite often, I think that the render-on-display works very well, provided that your site isn''t too busy. If you don''t need the flexibility or really need the speed, go for render-on-upload.> Might be a good way to get stuff done without sacrificing MVC.I don''t really understand that, I''m afraid. (But my idea of MVC might be wrong, so please correct me if you think that''s the case.) How would MVC be sacrificed? You could argue that determining how you want to display the image is something you should do in the view, not in the model. Thus, the image size is part of the view. And if that''s true, you should put the image-rendering business in the controller or the view. (Just like applying textilize or markdown to a text is that you''d do in the view, not in the model.) Render-on-display would the way to go. Even stronger, you could say that applying ImageMagick in the model, i.e. render-on-upload, goes directly against MVC. Downsizing the images just because your HTML template needs them that way, is comparable to escaping HTML entities in your model because you want to display them as HTML in a later stage. Both the image size and the HTML escaping are things that should be moved to the view. I don''t really want to go with this stronger version. I think that there can be valid reasons to put the rendering in the model. For example, if you''ve made it your model definition that user images should be exactly 400x200 pixels, you could do the processing in the model. But I don''t like the idea of doing it just because your views need them that way. Or even worse, having the images in three different sizes, because your views need a thumbnail, a small version and a large version. To me, that''s a bit like keeping three different versions of the same text, such as an HTML, a text and a PDF version. But then, my perceptions of MVC might be wrong, and anyway I think there''s something to say for both methods. Best regards, Gijs On 9/21/05, Kyle Maxwell <kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:> I don''t know if you guys saw it, but I posted an imagemagick extension > for file_column to this list. Might be a good way to get stuff done > without sacrificing MVC. > > Kyle Maxwell
On 9/23/05, Gijs van Tulder <gvtulder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I think that whether you want to use render-on-upload or > render-on-display depends on your needs.Why not do both? That''s what I do in php now. I have a function that generates a thumbnail of an image, and I call it on newly uploaded images for the common sizes I use. But I also have another function I call to display a thumbnail, and it checks if that thumbnail size exists, and if it doesn''t it calls the generate thumbnail function first. This way I cache the common sizes I need on upload, but also have the flexibility to request any new sizes when I want them (very useful for designing templates, to check which size works best). And even if the thumbnail size didn''t exist the first time it was requested in a display, it is cached so it will be available when it is requested again. - Isaac
Hi Gijs, newbie question about installation: on Textdrive I have to install your lib with the source, can''t use the gem. so I tried adding the files to vendor/ and requiring the files by name in environment.rb: require ''image_magick'' require ''image_magick_macro_helper'' restarted apache, but the helper methods don''t get recognized... am I installing this incorrectly? in my powerbook I got it working fine after installing the gem. many thanks for writing this, by the way. your lib and file_column together solve almost all of my problems of image handling in the project I''m working on. - Oliver On Sep 14, 2005, at 5:43 PM, Gijs van Tulder wrote:> A gem is indeed a good idea. I''ve posted it on my website. After > installing the gem, you''ll have to add a line requiring that gem to > your environment.rb. More info and a download on: > http://vantulder.net/rails/magick/
Hi Oliver,> newbie question about installation: on Textdrive I have to install > your lib with the source, can''t use the gem. so I tried adding the > files to vendor/ and requiring the files by name in environment.rb: > > require ''image_magick'' > require ''image_magick_macro_helper'' > > restarted apache, but the helper methods don''t get recognized... am I > installing this incorrectly?Yes, you are doing it correctly, you only miss the last step. After you''ve required the modules, you should also include them in the Rails base classes. Put the following in your environment.rb (after the requires): ActionController::Base.class_eval do include ActionController::Macros::ImageMagick end ActionView::Base.class_eval do include ActionView::Helpers::ImageMagickMacroHelper end This loads the methods of the extension in the ActionController and ActionView classes. In the gem, there is a third file (imagemagick_helper.rb) that does this. Perhaps I should supply that with the other two files. :) Hope that helps, Gijs
thanks Gijs! that did it ps the third file would be great ;) On Sep 24, 2005, at 5:35 PM, Gijs van Tulder wrote:> Yes, you are doing it correctly, you only miss the last step. After > you''ve required the modules, you should also include them in the Rails > base classes. Put the following in your environment.rb (after the > requires): > > ActionController::Base.class_eval do > include ActionController::Macros::ImageMagick > end > ActionView::Base.class_eval do > include ActionView::Helpers::ImageMagickMacroHelper > end > > This loads the methods of the extension in the ActionController and > ActionView classes. > > In the gem, there is a third file (imagemagick_helper.rb) that does > this. Perhaps I should supply that with the other two files. :) > > Hope that helps,
hi Gijs, may I ask for your help once more, I thought I had it working on textdrive, but I''m actually getting 404s for the images now, though they have the right permissions and get served normally when accessing them directly. works fine locally. the log says ''routing error'' this time, without any other errors (so the lib seems to be loaded fine). in my environment configs for development and production I have different constants for local and remote filesystem paths, so that I have: imagemagick_for MYPATH + /path/to/jpeg I triple checked the remote path... what could I be doing wrong? thanks oliver On Sep 24, 2005, at 5:35 PM, Gijs van Tulder wrote:> Hi Oliver, > > >> newbie question about installation: on Textdrive I have to install >> your lib with the source, can''t use the gem. so I tried adding the >> files to vendor/ and requiring the files by name in environment.rb: >> >> require ''image_magick'' >> require ''image_magick_macro_helper'' >> >> restarted apache, but the helper methods don''t get recognized... am I >> installing this incorrectly? >> > > Yes, you are doing it correctly, you only miss the last step. After > you''ve required the modules, you should also include them in the Rails > base classes. Put the following in your environment.rb (after the > requires): > > ActionController::Base.class_eval do > include ActionController::Macros::ImageMagick > end > ActionView::Base.class_eval do > include ActionView::Helpers::ImageMagickMacroHelper > end > > This loads the methods of the extension in the ActionController and > ActionView classes. > > In the gem, there is a third file (imagemagick_helper.rb) that does > this. Perhaps I should supply that with the other two files. :) > > Hope that helps, > > Gijs >
hey gijs, sorry to bother you again... I''m still stuck with this, have tried different solutions, tried asking on #rubyonrails, txd forum and txt support, no luck. if you could guide me to troubleshoot, I''d greatly appreciate it! been stuck with this for 10 days now. I''m sure it''s something silly, I must be blind or something. I installed the helpers on my textdrive account using the vendor/ directory. I have the patch code you sent me in place, and I have a constant set on environments/development and production.rb that sets the full path to public/ locally and on textdrive. and then I use imagemagick_for MYPATH + /path/to/image_dir (wrote it wrong last time) which works fine on my local setup, but I get 404s for the processed images on the remote server. The static path to the images serve the imgs just fine... MYPATH on textdrive is set to /home/username/web/ public (I have the rails directories in /web as per TxD recommendation) as opposed to my last message, the rails log doesn''t show any errors. at least this shows rails is loading the helpers correctly, or else it would throw an exception for the missing methods right? but no routing error... just a 404 in the apache log newbie hell... :P - Oliver On Sep 25, 2005, at 10:13 PM, oliver barnes wrote:> hi Gijs, > may I ask for your help once more, > I thought I had it working on textdrive, but I''m actually getting > 404s for the images now, though they have the right permissions and > get served normally when accessing them directly. works fine > locally. the log says ''routing error'' this time, without any other > errors (so the lib seems to be loaded fine). > > in my environment configs for development and production I have > different constants for local and remote filesystem paths, so that > I have: > > imagemagick_for MYPATH + /path/to/jpeg > > I triple checked the remote path... what could I be doing wrong? > > thanks > oliver > > > > On Sep 24, 2005, at 5:35 PM, Gijs van Tulder wrote: > > >> Hi Oliver, >> >> >> >>> newbie question about installation: on Textdrive I have to install >>> your lib with the source, can''t use the gem. so I tried adding the >>> files to vendor/ and requiring the files by name in environment.rb: >>> >>> require ''image_magick'' >>> require ''image_magick_macro_helper'' >>> >>> restarted apache, but the helper methods don''t get recognized... >>> am I >>> installing this incorrectly? >>> >>> >> >> Yes, you are doing it correctly, you only miss the last step. After >> you''ve required the modules, you should also include them in the >> Rails >> base classes. Put the following in your environment.rb (after the >> requires): >> >> ActionController::Base.class_eval do >> include ActionController::Macros::ImageMagick >> end >> ActionView::Base.class_eval do >> include ActionView::Helpers::ImageMagickMacroHelper >> end >> >> This loads the methods of the extension in the ActionController and >> ActionView classes. >> >> In the gem, there is a third file (imagemagick_helper.rb) that does >> this. Perhaps I should supply that with the other two files. :) >> >> Hope that helps, >> >> Gijs >> >> > >