Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have product images with 1 item and different amount of white space around it.
I need to make all images to look the same (product in the center and some padding) and for this I need to be able to auto crop images based on background color to bring them to same look.
When cropped, further manipulations are performed with other actions.
So, is there a way to auto crop based on color with imagecache_actions (without writing custom action)?
Comments
Comment #1
dman CreditAttribution: dman commentedThis feature is not supported natively, no. There is probably an algorithm that can do it in gd if you can find it - and yes, that would be a custom action.
It is however already available in ImageMagick.
http://www.imagemagick.org/Usage/crop/#trim
A VERY simple customaction in ImageMagick looks like
I just tested that and it does work!! At least on a pure PNG with transparent background. JPEG-encoded "white" may or may not work depending on how pure it appears to be. It looks like the ImageMagic
-fuzz 1%
option has anticipated that. See if you can get the results you want with that.This will not be available in GD unless you can do a search and find an existing code example that can be re-purposed to do this.
Comment #2
dman CreditAttribution: dman commentedmaybe http://stackoverflow.com/questions/1669683/crop-whitespace-from-image-in...
Comment #3
alex.skrypnykI have created a simple module that performs autocrop.
http://drupal.org/sandbox/alex.designworks/1549888
Comment #4
dman CreditAttribution: dman commentedThanks for linking.
Looks like a pretty good GD solution.
Comment #5
fietserwinalex.designworks: Are you interested in merging your sandbox into this module? I am asking for GD and imagemagick support and support in the issue queue, especially for issues regarding your effect.
I will do the same with my text effect sandbox project.
In my vision we should strive for 1 module that provides additional effects. This to:
- Make it easier to find for site builders. Currently there is the well known imagecache_actions (many downloads) and a handful of projects defining 1 effect and very few downloads.
- Reduce the module load on sites. This also means that the current structure of imagecache_actions needs to be revised
- Reduce code load on normal page requests where image building will not get called (99.9% or more on typical sites).
- Prefer cooperation over competition.
- Make it easy to add additional effects. We should define a simple plugin structure, so that effect implementers only need to care about image handling, not Drupal module creation, sandbox project promotion, etc.
Comment #6
alex.skrypnyk@fietserwin
Merging modules would be the right thing to do.
I'm 100% agree with all your reasons for merging (you did not have to convince me :) ))
I just have a performance issue with the current algorithm - it takes too much time to find proper areas. It should be properly rewritten - that is why it is a sandbox module (didn't have much time for optimization).
But anyway, please let me know what is the process of merging.
Comment #7
fietserwinThanks for your quick and positive feedback. However, for now, I am focusing on getting a 7.x-1.0 version out that contains all (easy) changes needed to clean up the issue queue and get the module in a working state. So I am setting all issues that will not be incorporated into the 7.x-10.0 version to postponed. I will contact you when I start working on a next version.
If you already have some ideas about the plugin structure or would like to think about it, that would be great.
Comment #8
AdamGerthel CreditAttribution: AdamGerthel commentedI just tried alex's sandbox module and it works very well and is quite useful. It seems that the performance was improved in a recent commit as well in #2161775: Refactor: performance and coding standards
Perhaps it's time for a merge with ImageCache Actions?
Comment #9
fietserwinI'm still open for that. D8 will give us the plugin structure and (as such) lazy loading, so I dropped my plans to do that in D7. A port to D8 will take a lot of time, so more maintainers would be welcomed.
@alex.designworks: are you still interested?