Was trying to add a simple border. 

$presets = array();
$presets['bordertest'] = array (
  'presetname' => 'bordertest',
  'actions' => 
  array (
    0 => 
    array (
      'weight' => '0',
      'module' => 'imagecache_canvasactions',
      'action' => 'canvasactions_definecanvas',
      'data' => 
      array (
        'RGB' => 
        array (
          'HEX' => '7a8df0',
        ),
        'under' => 1,
        'exact' => 
        array (
          'width' => '',
          'height' => '',
          'xpos' => 'center',
          'ypos' => 'center',
        ),
        'relative' => 
        array (
          'leftdiff' => '10',
          'rightdiff' => '10',
          'topdiff' => '10',
          'bottomdiff' => '10',
        ),
      ),
    ),
  ),
);

Throws 
    * warning: imagesx(): supplied argument is not a valid Image resource in /home/xxx/public_html/sites/all/modules/imagecache_actions/watermark.inc on line 23.
    * warning: imagesy(): supplied argument is not a valid Image resource in /home/xxx/public_html/sites/all/modules/imagecache_actions/watermark.inc on line 24.
    * warning: imagesx(): supplied argument is not a valid Image resource in /home/xxx/public_html/sites/all/modules/imagecache_actions/watermark.inc on line 28.
    * warning: imagesy(): supplied argument is not a valid Image resource in /home/xxx/public_html/sites/all/modules/imagecache_actions/watermark.inc on line 29.


ImageAPI	6.x-1.4
ImageAPI GD2	6.x-1.4	
ImageAPI ImageMagick	6.x-1.4
ImageCache	6.x-2.0-beta8
Imagecache Canvas Actions	6.x-1.2

Comments

dman’s picture

dman commented
Status: Active » Needs review

Thankyou, yes.
What seems to have happened is that imageapi changed its internals :-(
it renamed $image->res to $image->resource.
My processes stopped working.

I've now patched it in dev to try and keep up with imageapi, but this means that imagecache_actions-dev is now only compatible with imageapi later than 2009/02/13 or http://drupal.org/node/396924

Arg. OK, I'll make a new tag to sync with this serious change to imageapi. That REALLY should have been a number release DRUPAL-6.x-2.x.
Of course, I probably shouldn't have been touching the internals of an abstracted API - I didn't know ->res was a private attribute though! It's to do with the toolkit abstraction, I understand :-/

What this means is, I guess....
[
imageapi 6.x-1.4 (and dev and up)
imagecache_actions 6.x-1.4 6.x-1.x-dev 2009-Mar-11
]

[
imageapi 6.x-1.3 (and down)
imagecache_actions 6.x-1.2 (and down)
]

This is painful.

Please test the latest dev from CVS or the imagecache_actions 6.x-1.4 when it becomes available.
THanks for the report. It's certainly a new problem.

sgriffin’s picture

sgriffin commented

Appears to work again. Good job!

sgriffin’s picture

sgriffin commented

This only works for the GD toolkit and errors on ImageAPI ImageMagick toolkit.
Unfortunately, I need ImageAPI ImageMagick to handle processing of larger images that GD throws memory errors with.

dman’s picture

dman commented
Status: Needs review » Postponed

Sorry, there has never been full support for imageMagick here.
This is probably a comparatively easy transform for the imagemagick pipeline to do, so anyone who actually has and uses imagemagick can throw in a patch and I'll OK it. I just can't use or test it myself.

sgriffin’s picture

sgriffin commented

Hmm I wonder if and or how it could be a good idea to specify in the preset which toolkit you would like to use.
"Toolkit override" or something.

pikard’s picture

pikard commented

I have the some problem, with Imagecache6.x-beta8, imageApi1.5
please help!

dman’s picture

dman commented

@pikard
If you have the 'same' problem, the only available solution is to stop using imagemagick and use GD instead.
If you are using imageAPI 1.5 (I didn't know that was out. *sigh*) then I dunno, maybe you could try imagecache_actions-DEV (last updated yesterday) and see what the story is.

sgriffin’s picture

sgriffin commented

Imagemagick is amazingly faster and operations are much simplified. For those who have it installed, perhaps a command line preset helper might be helpful and call it using the shell. Its not too hard actually to roll your own CLI preset.

Build the command with your imagecache preset inputs, to output to the temp directory, use shell_exec, set $image->source to the new file, delete the new file with register_shutdown_function and return true.
A cli helper would handle all these if you only input what you need in one text field, not requiring input and output filenames.

dman’s picture

dman commented

We are supporting "custom" actions for GD for a little while now (and, I guess for imagemagick also, although I've only been able to document the one I can use)

imagecache_customactions Enter PHP code for your custom action. Source image is available in the $image object which contains an $image->info array, and a $image->resource which is the php toolkit object itself. Your code must return an image object of the same structure (see ImageAPI). For convenience, the images current $image->info variables - $width, $height are available in the current scope.

example

// Wave an image
  $amplitude = 10; $period = 10;
  $x=0; $y=0;
// Make a copy of the image twice the size
  $height2 = $height * 2; $width2 = $width * 2;
  $img2 = imagecreatetruecolor($width2, $height2);
  imagecopyresampled($img2, $image->resource, 0, 0, $x, $y, $width2, $height2, $width, $height);
// Wave it
  for($i = 0; $i < ($width2); $i += 2)
    imagecopy($img2, $img2, $x+$i-2, $y+sin($i/$period)*$amplitude, $x+$i, $y, 2, $height2);
// Resample it down again
  imagecopyresampled($image->resource, $img2, $x, $y, 0, 0, $width, $height, $width2, $height2);
  imagedestroy($img2);
return $image;

# code modified from bokehman at http://www.sitepoint.com/forums/showpost.php?p=3655457

An extra paragraph on just what you need to do to make that toolkit do its, um, magick, should be all you need, right?

Note that imageapi does not actually do each imagemagick process one by one, but pipelines the processes onto the commandline and runs them all in one go at the end. It doesn't use temp images or anything. Not that it couldn't if it had to...

I guess any 'custom' process will just be adding something onto that string.
If you've got any examples that can help fill in the gaps (I'm sure it's only 3 lines or so to get define canvas working fully properly via imageapi -but I just don't know) then we can roll them in!

sgriffin’s picture

sgriffin commented

Sounds like a plan, I didn't really understand the process for anything and any attempt to duplicate the code didn't quite work for CLI applications as posted above.
Watermark in imagemagick doesn't need you to define the canvas.
Here's a page I used.
http://www.imagemagick.org/Usage/annotating/
and for borders.
If you have imageapi and imagemagick toolkit installed, do you still need convert installed?
I don't think, it can quite be useful to duplicate basic functions in both toolkits when the methods differ so much.. Thats why I thought perhaps, the choice of toolkits wasn't that great of an idea and it was better to have a choice per preset action, so you don't get a fail like you do when using IM and define canvas currently... and also the fail notice doesn't display anything as to WHY or the requirement of GD. Also as stated previously, I think IM is alot nicer on memory not to mention speed which are both things that drupal quickly eats up.
Of course, the API is meant as an abstraction to prevent needing to fork methods, but in quite a few more complex processes, I think its better to have GD and IM specific presets.

.............
$cmd = 'convert '.$output_image_name.' -bordercolor black -border 1 '.$output_image_name;
shell_exec($cmd); 
$image->source = $output_image_name;
register_shutdown_function('file_delete', $output_image_name);
return true;
will_in_wi’s picture

will_in_wi commented

I created a bug report to request the ability to specify which toolkit to use per preset: #435486: Add the ability to define toolkits per preset

dman’s picture

dman commented

Code-wise, that's not really going to work.
the GD and imagemagick processes are totally different. GD creates an object in PHP memory and passes it around. ImageMagick creates a script of instructions then runs those instructions in one go on the commandline at the end.
gd can't pass imagemagick its memory dump, and vice versa.

to do that, BOTH toolkits would have to open, modify, save a temp image for each step in a preset. That's totally different from current behaviour - and pretty bad way of going about things. ImageAPI currently works because it passes handles around. I can't see it falling back to that one-by-one approach.

However, I do now have imagemagick on a test machine - although not on any live servers. I'm doing a little bit of testing and finding what can be done to make imagemagick work (or at least not break) for some actions.

Djamu’s picture

Djamu commented

I'm having the same problem now on imagecache_actions 5.x-2.3 with imageapi 5.x-1.5

Should I file it separately for 5.x ?

EDIT:

Never mind it, I patched it up myself, if interested drop me a note

dman’s picture

dman commented

Patched to actually WORK with imagemagick in D5? Or just to not break?
If you've figured out the pipeline commandline insertion via imageapi rules, I'm very interested.
If you are saving, modifying and opening again .. that's not a fix I'm keen on.

Djamu’s picture

Djamu commented

I should have elaborated this a little more > I'm D5 with the GD libs ( ImageAPI GD2 ), imagemagick is correctly installed but never really worked for me on Imagecache Actions. ( at least not for the features I'd like to have it )
I'm not a PHP programmer, but do know how to debug stuff, so it was not a big deal to change some things to get imagecache_actions working again

changed a couple of $image->res to $image->resource and $overlay->res to $overlay->resource
to get my shadow thing working again.

Just thought I should mention the problem.

hlopes’s picture

hlopes commented

Hello there,

was trying to define a canvas, but everytime i try to configure it, the image preview disappears and shows just a link.

Also, the configurations go awry and get like this:
Define Canvas left: right: top: bottom: Transparent over image

When it should be like this:
Define Canvas 100x100 (center, center) #8A1A19 under image

All caches are deactivated, and this behaviour happens in two different servers.

In the database, table imagecache_actions field data only gets something like
b:0;

after saving the preset, as opposite to the other example that goes something like:

a:4:{s:3:"RGB";a:1:{s:3:"HEX";s:6:"ffffff";}s:5:"under";i:1;s:5:"exact";a:4:{s:5:"width";s:2:"100";s:6:"height";s:2:"100";s:4:"xpos";s:6:"center";s:4:"ypos";s:6:"center";}}

Any help would be appreciated.

hlopes’s picture

hlopes commented

Got it.

Someway a field in the database table was not updated (or so i guess...)

The field 'data' on table "_imagecache_action" , which was of type 'varchar(255)' should be of type 'text(empty size)'.

This led to a truncate of the settings, hence the b:0;

dman’s picture

dman commented

Glad you could sort it. I looked at it and scratched my head, but couldn't imagine how to replicate. Looked like a preset profile was corrupt, but don't know how.
Sounds like a meta issue I didn't know about if there is a size limitation on the action settings table.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Status: Postponed » Closed (fixed)

Is there still a problem to solve here? Looks like it all works now. If not so, please open a new issue (against a current version) describing just that problem.