[drupal-devel] New image.module
Hey all, As promised, I've just committed brand new versions of "my" image.module to my sandbox. A working version for CVS HEAD is at : contributions/sandbox/walkah/image (compatible with the new "image api"). There is also a 4.5 version available in the "45" subdirectory. As I've mentioned in #drupal and briefly on this list, this version comes with a slightly new approach. You may notice that the image.*sql files have been removed. This is because image.module no longer requires it's own tables. Instead, it uses the files table (previously only used by upload.module) to store information about all files (various resolutions) in this table. This has several benefits: First, it greatly simplifies the installation of image.module, but more importantly it keeps better track of each image associated with the node. Where previous image.modules (mine included) relied on naming conventions to keep track of various sizes & resolutions, this image module actually has a record for each size - including it's filesize (making it easy to write a quota.module - for instance). The other major addition (which was previously left out intentionally) is the re-introduction of basic image gallery functionality. This is minimalistic intentionally - and not meant to stifle or otherwise conflict with other initiatives (such as moshe's album.module). A couple things to note: the maintenance of gallery albums is done at ?q=admin/image and should be familiar in style for those of you who have tried HEAD's latest forum.module. Also, the layout no longer uses tables - as I'm sure some of you will enjoy. However, I don't fancy myself much of a designer, so suggestions / recommendations on "default" look and feel are of course very welcome. For those of you that don't like the approach at all - theme('image_album', $albums, $images) :) Now, due to the change in DB storage approach - I have included an 'update-images.php' ... which needs to be run from the root of your drupal installation. I have done testing on this - however, I'm not gonna claim complete perfection here. I'd love to have folks with image.module installations test this out - PLEASE backup your image files and tables first !!!! Moving forward - I'd really like to get this into modules/image as soon as possible so that we (as a community) can use project.module for bug & feature tracking (rather than random emails / IRC chats / etc). Ideally, I'd like this to happen by the time contrib is branched for DRUPAL-4-6 so for 4.6 there will be no confusion of which image.module to use, etc. As there is a 4.5 version as well, I'm willing to move that into the DRUPAL-4-5 branch, but I'd like to get some consensus on that - as I worry it might 'cause more confusion than is really necessary. Again, this is not intended as a final version - lots of people are using image in a lot of interesting ways, I'd be happy to try and accommodate all features, either through "API"-style functions & features or as base functionality in the module - but would like to get some feedback from the community at large as to what people would like to see. Cheers, -- James Walker :: http://www.walkah.net/
James Walker schreef:
As promised, I've just committed brand new versions of "my" image.module to my sandbox. A working version for CVS HEAD is at : contributions/sandbox/walkah/image (compatible with the new "image api"). There is also a 4.5 version available in the "45" subdirectory.
I know, and it rocks! But, after some serious testing I have only 3 little things which are missing: - in image.inc you use ImageCreateTrueColor() which is only present in GD 2.0.. If the function is not resent there is no error message; it just breaks the it.. Please let it fall back the function _ImageCopyResampled() which is somewhere in the Attc of Marco Molinari's Sandbox (http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/marco/fileapi/). - There is a *.po missing for the image.module; - How can we manipulate the way thumbnails and photo's are created? How can i override the standard thumbnail/photo ideas? What if I want to make transparent PNG's of my photographs which are randomly rotated? (Like here: http://frontaal-online.com/fotoalbum/oude-doos) It would be a very nice feature to have! And, that's all! You did a great job on this and I can't thank you enough for this "gift from heaven"... It works like a charm! Yours sincerely, Stefan.
On Mon, 21 Feb 2005 09:07, Stefan Nagtegaal wrote:
James Walker schreef:
As promised, I've just committed brand new versions of "my" image.module to my sandbox. A working version for CVS HEAD is at : contributions/sandbox/walkah/image (compatible with the new "image api"). There is also a 4.5 version available in the "45" subdirectory.
I know, and it rocks! But, after some serious testing I have only 3 little things which are missing: - in image.inc you use ImageCreateTrueColor() which is only present in GD 2.0.. If the function is not resent there is no error message; it just breaks the it.. Please let it fall back the function _ImageCopyResampled() which is somewhere in the Attc of Marco Molinari's Sandbox (http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/marco/fileapi/) . - There is a *.po missing for the image.module; - How can we manipulate the way thumbnails and photo's are created? How can i override the standard thumbnail/photo ideas? What if I want to make transparent PNG's of my photographs which are randomly rotated? (Like here: http://frontaal-online.com/fotoalbum/oude-doos) It would be a very nice feature to have!
And, that's all! You did a great job on this and I can't thank you enough for this "gift from heaven"... It works like a charm!
Yours sincerely,
Stefan.
I haven't had the chance to look at the new module yet, so I don't know how it compares, but I had been messing around with writing my own version to suit my own needs for a while (and as a means to learn php/drupal) until I heard about James' efforts and put it on hold. My version does include some of the things you mention, such as supporting both GD1 and GD2 (among others), autodetecting which libraries are available, setting background colour for rotation (but I think this was in the old module?), different thumbnail policies, and different image scaling policies (these last two currently only at a site or module level, but I intended to extend it to the individual image or node level and the api allows for it). You can find the code at http://www.layt.net/john/projects/graphic, feel free to borrow any code you might like the look of. I'll have a look at James' work next weekend to see if it meets my needs (or if I need to borrow his upload code for mine :-). Cheers! John. P.S. Loved the photos on your site, reminded me of my old marching band days :-)
On Thu, 17 Feb 2005 14:33:49 -0500, James Walker <walkah@walkah.net> wrote:
The other major addition (which was previously left out intentionally) is the re-introduction of basic image gallery functionality. This is minimalistic intentionally - and not meant to stifle or otherwise conflict with other initiatives (such as moshe's album.module). A couple things to note: the maintenance of gallery albums is done at ?q=admin/image and should be familiar in style for those of you who have tried HEAD's latest forum.module. Also, the layout no longer uses
I'm not really satisfied with being restricted to a separate vocabulary for image galleries. I am able to use another vocabulary for images but the "Image Galleries" vocabulary is not removable from the node creation form and /image *only* looks for galleries in its hardcoded vocabulary. It might be better to not force this vocabulary. It would also be nice to have some "taxonomy on the fly" capability but I suppose this is better handled in a album/gallery module. Another confusing thing is that I don't see an option to view images at other dimensions. I've added a third dimension to /admin/settings/image but no other size options are displayed on any image view that I've seen. Otherwise, this module is working nicely. Great work. I'm just testing it on Drupal cvs and haven't tried upgrading an existing gallery so have nothing to report there.
Moving forward - I'd really like to get this into modules/image as soon as possible so that we (as a community) can use project.module for bug & feature tracking (rather than random emails / IRC chats / etc). Ideally, I'd like this to happen by the time contrib is branched for DRUPAL-4-6 so for 4.6 there will be no confusion of which image.module to use, etc. As there is a 4.5 version as well, I'm willing to move that into the DRUPAL-4-5 branch, but I'd like to get some consensus on that - as I worry it might 'cause more confusion than is really necessary.
It would be great to have this for 4.6. I think caution is in order though as the upgrade from the existing image module may require quite a bit of testing. Maybe the 4.5 version of the module should be mentioned (more) on Drupal.org to get more testing going.
Op donderdag 17 februari 2005 20:33, schreef James Walker:
Moving forward - I'd really like to get this into modules/image as soon as possible so that we (as a community) can use project.module for bug & feature tracking (rather than random emails / IRC chats / etc). Ideally, I'd like this to happen by the time contrib is branched for DRUPAL-4-6 so for 4.6 there will be no confusion of which image.module to use, etc. As there is a 4.5 version as well, I'm willing to move that into the DRUPAL-4-5 branch, but I'd like to get some consensus on that - as I worry it might 'cause more confusion than is really necessary.
Can the authors and maintainers of the old image.module comment on this please? Cna they tell us if they mind theyr baby to be killed and replaced by this image module? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Op donderdag 17 februari 2005 20:33, schreef James Walker:
Moving forward - I'd really like to get this into modules/image as soon as possible so that we (as a community) can use project.module for bug & feature tracking (rather than random emails / IRC chats / etc). Ideally, I'd like this to happen by the time contrib is branched for DRUPAL-4-6 so for 4.6 there will be no confusion of which image.module to use, etc. As there is a 4.5 version as well, I'm willing to move that into the DRUPAL-4-5 branch, but I'd like to get some consensus on that - as I worry it might 'cause more confusion than is really necessary.
Can the authors and maintainers of the old image.module comment on this please? Cna they tell us if they mind theyr baby to be killed and replaced by this image module?
I was a maintainer of image.module for a while last fall. James showed me his version in October and I've been working with it since then. James' version is much cleaner and simpler than the current one. A strong +1 from me on replacing the existing image.module -- with the caveat that I haven't looked at his most recent version (with the adaptations for image.inc). -Eric
Eric Scouten wrote:
I was a maintainer of image.module for a while last fall. James showed me his version in October and I've been working with it since then. James' version is much cleaner and simpler than the current one. A strong +1 from me on replacing the existing image.module -- with the caveat that I haven't looked at his most recent version (with the adaptations for image.inc).
Follow up: Last night I converted one of my sites to James' latest image.module and the upgrade script worked flawlessly. I say the sooner the switchover happens, the better. -Eric
Simon Lindsay wrote:
Eric Scouten wrote:
Follow up: Last night I converted one of my sites to James' latest image.module and the upgrade script worked flawlessly. I say the sooner the switchover happens, the better.
Do you know if it works with the img_assist module?
Yep. The latest incarnation of img_assist in CVS HEAD grabs all image metadata within the files table. Since James' image module and upload module store file data in the same place, img_assist now works with both of them at the same time. Matt
After having studied more and more of the new image(-api|.module), i have some concerns, which are: - We currently assume that everybody has at least GD 2.0, which is a bad thing imo. Imo we should move the GD 2.0 functions like image_gd_(settings|resize|rotate|crop|open|close) into a separate image.gd2.inc and make a image.gd1.inc file. just like we did for the ImageMagick, which currently lives in silence under Walkah's Sandbox... I thought a little more about the fact how we should be able to override the standard way how thumbnails/photo's are generated. (Think about how to accomplish something like this: http://frontaal-online.com/fotoalbum/oude-doos). In my opinion this _really_ is a theme issue, so it would be nicef there could be a way how we can deal with this in that place.. But, I'm sure that this needs more thought.. In the meanwhile everybody is free to rewrite and modify a image.$name.inc file which does exactly what you want.. Still, I think that's not quite optimal... I am looking forward to your answers and opinions about this... Stefan
Op zondag 27 februari 2005 13:28, schreef Stefan Nagtegaal: > After having studied more and more of the new image(-api|.module), i > have some concerns, which are: > - We currently assume that everybody has at least GD 2.0, which is a bad > thing imo. > Imo we should move the GD 2.0 functions like > image_gd_(settings|resize|rotate|crop|open|close) into a separate > image.gd2.inc and make a image.gd1.inc file. just like we did for the > ImageMagick, which currently lives in silence under Walkah's Sandbox... We should always offer the most used as default. People on old hosts should just read a little on how to get gd1 running. >[...] > In my opinion this _really_ is a theme issue, so it would be nicef there > could be a way how we can deal with this in that place.. But, I'm sure > that this needs more thought.. Definately not!. * Imagine an MP3: If you want to present only a snippet of that file, you need to edit it. Nothing to do with themes. This case is very similar to what you do in the oude-doos. It is definately an image editing function. * on output editing of images is very bad. Something like your oude-doos should never ve done on-output. > In the meanwhile everybody is free to rewrite and modify a > image.$name.inc file which does exactly what you want.. > Still, I think that's not quite optimal... What is not optimal about it? The method of working, or the module system? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 27-Feb-05, at 7:28 AM, Stefan Nagtegaal wrote:
After having studied more and more of the new image(-api|.module), i have some concerns, which are: - We currently assume that everybody has at least GD 2.0, which is a bad thing imo. Imo we should move the GD 2.0 functions like image_gd_(settings|resize|rotate|crop|open|close) into a separate image.gd2.inc and make a image.gd1.inc file. just like we did for the ImageMagick, which currently lives in silence under Walkah's Sandbox...
We don't actually make any assumptions about GD version. If you'll notice all of the "gd2-only" functions are wrapped by 'function_exists' calls, and fall back on the gd1 versions if not defined. I'm pretty sure this fails gracefully... If you're seeing a *specific* issue with handling under gd1 handling, then I'd be more than happy to patch it. We do however, only include gd* by default (as gd2 is bundled with recent php). imagemagick, etc will be available as well as an extra download.
I thought a little more about the fact how we should be able to override the standard way how thumbnails/photo's are generated. (Think about how to accomplish something like this: http://frontaal-online.com/fotoalbum/oude-doos).
In my opinion this _really_ is a theme issue, so it would be nicef there could be a way how we can deal with this in that place.. But, I'm sure that this needs more thought.. In the meanwhile everybody is free to rewrite and modify a image.$name.inc file which does exactly what you want.. Still, I think that's not quite optimal...
I am looking forward to your answers and opinions about this...
I don't agree. I think alternate 'derivative' generation is better. the main issue is providing hooks that make sense, are easy to use without creating nasty conflicts (i.e. what if 2 modules are installed that try to generate varied thumbnails?). But i think it's better to solve those issues, rather than throwing a bunch of code and processing into themes. -j
James Walker schreef:
On 27-Feb-05, at 7:28 AM, Stefan Nagtegaal wrote:
After having studied more and more of the new image(-api|.module), i have some concerns, which are: - We currently assume that everybody has at least GD 2.0, which is a bad thing imo. Imo we should move the GD 2.0 functions like image_gd_(settings|resize|rotate|crop|open|close) into a separate image.gd2.inc and make a image.gd1.inc file. just like we did for the ImageMagick, which currently lives in silence under Walkah's Sandbox...
We don't actually make any assumptions about GD version. If you'll notice all of the "gd2-only" functions are wrapped by 'function_exists' calls, and fall back on the gd1 versions if not defined. I'm pretty sure this fails gracefully... If you're seeing a *specific* issue with handling under gd1 handling, then I'd be more than happy to patch it. We do however, only include gd* by default (as gd2 is bundled with recent php). imagemagick, etc will be available as well as an extra download.
Well, I have 2 hosts currently.. I tried to run the image.module with a standard image.inc on a host with GD 1.6.2 (http://frontaal-online.com/phpinfo.php) where it is failing to work.. It looks like the function imageCreateTrueColor is known, but is not present nor working.. So, it fails to work.. I still would like to see the image.module split into 3 files. - image.inc - image.gd1.inc & - image.gd2.inc. then we can leave the image.inc in core, so the api is present. But whenever people would like to have image manipulation capabilities, they downoad the image.$toolkit.inc file which matches their needs.
I thought a little more about the fact how we should be able to override the standard way how thumbnails/photo's are generated. (Think about how to accomplish something like this: http://frontaal-online.com/fotoalbum/oude-doos).
In my opinion this _really_ is a theme issue, so it would be nicef there could be a way how we can deal with this in that place.. But, I'm sure that this needs more thought.. In the meanwhile everybody is free to rewrite and modify a image.$name.inc file which does exactly what you want.. Still, I think that's not quite optimal...
I am looking forward to your answers and opinions about this...
I don't agree. I think alternate 'derivative' generation is better. the main issue is providing hooks that make sense, are easy to use without creating nasty conflicts (i.e. what if 2 modules are installed that try to generate varied thumbnails?). But i think it's better to solve those issues, rather than throwing a bunch of code and processing into themes.
-j
I think - looking from your point of view - i do agree with you guys.. Probably, pepole could rewrite the image.$toolkit.inc file for specific needs or advanced image manipulation. Which I did currently at 3 different hosts, and it works awesome! :-) Stefan
Stefan Nagtegaal schreef:
James Walker schreef:
On 27-Feb-05, at 7:28 AM, Stefan Nagtegaal wrote:
After having studied more and more of the new image(-api|.module), i have some concerns, which are: - We currently assume that everybody has at least GD 2.0, which is a bad thing imo. Imo we should move the GD 2.0 functions like image_gd_(settings|resize|rotate|crop|open|close) into a separate image.gd2.inc and make a image.gd1.inc file. just like we did for the ImageMagick, which currently lives in silence under Walkah's Sandbox...
We don't actually make any assumptions about GD version. If you'll notice all of the "gd2-only" functions are wrapped by 'function_exists' calls, and fall back on the gd1 versions if not defined. I'm pretty sure this fails gracefully... If you're seeing a *specific* issue with handling under gd1 handling, then I'd be more than happy to patch it. We do however, only include gd* by default (as gd2 is bundled with recent php). imagemagick, etc will be available as well as an extra download.
Well, I have 2 hosts currently.. I tried to run the image.module with a standard image.inc on a host with GD 1.6.2 (http://frontaal-online.com/phpinfo.php) where it is failing to work.. It looks like the function imageCreateTrueColor is known, but is not present nor working.. So, it fails to work.. I still would like to see the image.module split into 3 files. - image.inc - image.gd1.inc & - image.gd2.inc.
then we can leave the image.inc in core, so the api is present. But whenever people would like to have image manipulation capabilities, they downoad the image.$toolkit.inc file which matches their needs.
okay, I just found out why this isn't working.. From the PHP manual: "|Actually GD <2.0 had imagecreattruecolor, it just didn't work :P|", which explains why it doesn't work as expected.. the function_exists() finds the code, so the else clause after the if (function_exists('imageCreateTrueColor')) { get never executed.. I'll come up with a patch soon, to compromise the behaviour.. Though, I still think it's better to have separate files for the gd1 and gd2 image manipulation toolkits.. thoughts??? Stefan
On Mon, 28 Feb 2005 10:20:49 +0100, Stefan Nagtegaal > I'll come up with a patch soon, to compromise the behaviour.. Though, I
still think it's better to have separate files for the gd1 and gd2 image manipulation toolkits..
thoughts???
I disagree with excluding the image toolkits from the distribution. It's good from a page efficiency perspective to make the toolkits modular but requiring end users to download the most common toolkits in order to make a core feature work will likely go over like a lead balloon.
On 27-Feb-05, at 1:48 AM, Eric Scouten wrote:
Eric Scouten wrote:
I was a maintainer of image.module for a while last fall. James showed me his version in October and I've been working with it since then. James' version is much cleaner and simpler than the current one. A strong +1 from me on replacing the existing image.module -- with the caveat that I haven't looked at his most recent version (with the adaptations for image.inc).
Follow up: Last night I converted one of my sites to James' latest image.module and the upgrade script worked flawlessly. I say the sooner the switchover happens, the better.
Glad to hear that, Eric. I'm eager to get some more "successful" reports for the upgrade script. But , yes the full intention is to have this be the 4.6 image.module. -- James Walker :: http://www.walkah.net/
participants (8)
-
Bèr Kessels -
Chris Cook -
Eric Scouten -
James Walker -
John Layt -
Matt Westgate -
Simon Lindsay -
Stefan Nagtegaal