Whilst working on a custom imagecache action I wanted to use the image stack, ie use parenthesis on the imagemagick command line. I'm working with 5.x-1.2, but I believe this also applies to 6.x and is more likely to be implemented there.
Currently imageapi passes the source and destination filenames *after* the operations eg:
convert -scale 200x200 -tint blue input.png output.png
This is perfectly legal for Imagemagick 5, and Imagemagick 6 supports that legacy syntax. However certain more advanced features require using the version 6 syntax where the input filename comes before the operations:
convert input.png -scale 200x200 -tint blue output.png
Currently if one tries to pass imagemagick-imageapi an imagecache action with a more advanced command like:
$image->ops[] = "\( +clone -modulate 110,0 -fill '#FF00DD' -tint 100 \) +append";
It fails because imagemagick sees the +clone before any images, the command is passed as:
convert \( +clone -modulate 110,0 -fill '#FF00DD' -tint 100 \) +append input.png output.png
When it needs to be sent as:
convert input.png \( +clone -modulate 110,0 -fill '#FF00DD' -tint 100 \) +append output.png
One possible issue with imageapi using IM6 syntax: losing backward compatibility with IM5, I've no idea how important that is. Possibly it would require a version check before allowing 'advanced' actions to be used?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | imageapi_291905.patch | 2.24 KB | drewish |
| #5 | imageapi_imagemagick-291905-im6cl-02.patch | 663 bytes | adrinux |
| #3 | imageapi_imagemagick-291905-im6cl-01.patch | 534 bytes | adrinux |
Comments
Comment #1
drewish commentedi support the change but would like to find out how big a deal the backwards compatibility would be. it looks like 6.x has been out for over a year and a half... i guess we'd need to see what the linux distros have been shipping for the last couple of releases.
Comment #2
adrinux commentedDid some hunting around, these distro's have IM6:
Debian as far back as sarge.
Ubuntu as far back as dapper. (changelog shows the change IM5 > IM6 happening in 2004)
I found Fedora core 3 security updates for IM6 (in 2005), so Fedora's also had it for a few years.
CentOS 4.
FreeBSD also added IM6 in 2004.
Basically all the major distro's seemed to have changed to IM6 in mid 2004 - I'd say that was long enough ago for this not to be a problem. As for cheepo shared hosting, I'm guessing they're not running 4 year old distro's anymore - 2 yrs maybe :)
The only other slight concern is that existing imagecache imagemagick actions will behave differently, but I'd say that was unlikely and easily fixed anyway.
Should I go ahead and create a patch for imageapi_imagemagick.module ? (To the best of my abilities.)
Comment #3
adrinux commentedI was imagining some major reworking to explicitly declare the $source and $dest files when calling convert - then I realised all we really need is to ensure $source is added at the start of the $args array. So this simple one line patch uses array_unshift() to insert $source at the beginning of $args.
Tested and working on 5.x-1.2 but it should apply to 6.x too.
Comment #4
drewish commentedgreat, looks like compatibility shouldn't be a big deal. i'm not above telling people to get their isp to update... and dopry's been on the warpath against php5 so i don't think he'd mind.
haven't had a chance to test this. but it'd be good to add a comment explaining why we're putting the source at the front so it doesn't get "optimized" out later on.
Comment #5
adrinux commentedHere's a patch with a comment.
It may be wise to untangle this $args array and simply pass $source and $dest to convert separately in the long term, for 6.x versions - but my attempt earlier in the week failed, I'm more themer than programmer :)
But I think this approach will suffice for now, especially for 5.x where making such large changes would seem unwise and unnecessary.
Comment #6
drewish commentedi went ahead and tweak this some and committed it to HEAD. i'm not setup to test on 5 right now so perhaps you could give it a look? if it looks good to you mark it RTBC.
Comment #7
adrinux commentedYes, looks much clearer, thanks. But seems to break at least some of the imagecache presets on the site I'm developing, which is a little bizarre. I wont have time to look more closely at why until Monday.
Comment #8
adrinux commentedTurned out to be an EBKAC. I really shouldn't do patch testing late on Friday :(
Today it's working fine of course. Tested against 5.x-1.2 with standard imagecache actions, and my custom action (which uses parenthesis etc), all working fine.
Marking RTBC
Comment #9
drewish commentedgreat, committed to DRUPAL-5.
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.