I am use GraphicsMagick 1.1.15

all work with standart image style.

I am try ImageCache Actions 7.1.1 for watermark

and recive this error:
User error: ImageMagick error 1: gm convert: Unrecognized option (-compose).

i am try ImageCache Actions dev verssion:

and now:
gm convert: Unrecognized gravity type (None).

CommentFileSizeAuthor
#28 imagecache_actions-graphics-magick-compatibility-2005228-28.patch1.68 KBb-prod

Comments

dman’s picture

dman commented
Project: ImageMagick » ImageCache Actions

This probably belongs over here in Imagcache Actions.
The imagemagick layer just provides an API - the command comes from 'watermark'

I HAVE seen something a little like this on one wacky version number of the magick libs, but can't recall the number. I think I just upgraded the library rather than debug it for too long at the time.
I'm not aware of any advantage in using graphicksmagic or compatibility issues, but there is a fine chance they exist.
If the current version is 1.3.16-1.1, then 1.1.15 may be quite old... hm. 2009-04-02 is not TOO old, but not fresh either.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Version: 7.x-1.0 » 7.x-1.x-dev
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

I ignore the "Unrecognized option (-compose)" part for now and would like to focus on the "Unrecognized gravity type (None)"part. This was just added (in the dev release) to solve another bug (#1999140: Canvas effects using imagemagick might fail due to earlier -gravity settings). To solve, there are a few options.

- Use Forget instead of None if that is known by gm.
- Only use it if gravity has actually been set before (how to check?)

@protools: can you do a gm convert -list gravity in a command shell and post the results over here?

protools’s picture

protools commented 
#gm convert -list gravity
gm convert: Unrecognized list type (gravity).

7.x-1.1+18-dev

and i upgrade to GraphicsMagick 1.3.16 - same result

gm convert -gravity None '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose src-over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

maybe help http://www.graphicsmagick.org/GraphicsMagick.html#details-gravity

my config:

Version information
GraphicsMagick 1.3.16 2012-06-23 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2012 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
  Thread Safe              yes
  Large Files (> 32 bit)   yes
  Large Memory (> 32 bit)  yes
  BZIP                     yes
  DPS                      no
  FlashPix                 no
  FreeType                 yes
  Ghostscript (Library)    no
  JBIG                     yes
  JPEG-2000                yes
  JPEG                     yes
  Little CMS               yes
  Loadable Modules         yes
  OpenMP                   yes (200505)
  PNG                      yes
  TIFF                     yes
  TRIO                     no
  UMEM                     no
  WMF                      yes
  X11                      no
  XML                      yes
  ZLIB                     yes

Host type: amd64-portbld-freebsd9.1

Configured using the command:
  ./configure  '--without-perl' '--enable-shared' '--enable-static' '--with-ltdl-include=/usr/local/include' '--with-ltdl-lib=/usr/local/lib' '--without-fpx' '--without-dps' '--with-threads' '--enable-openmp' '--disable-openmp-slow' '--without-x' '--with-quantum-depth=8' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd9.1' 'build_alias=amd64-portbld-freebsd9.1' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -march=nocona -msse -msse2 -msse3' 'LDFLAGS= -L/usr/local/lib -pthread' 'CPPFLAGS=-I/usr/local/include' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -march=nocona -msse -msse2 -msse3'

Final Build Parameters:
  CC       = cc -std=gnu99
  CFLAGS   = -fopenmp -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -march=nocona -msse -msse2 -msse3 -Wall -D_THREAD_SAFE
  CPPFLAGS = -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libxml2
  CXX      = c++
  CXXFLAGS = -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -march=nocona -msse -msse2 -msse3 -D_THREAD_SAFE
  LDFLAGS  = -L/usr/local/lib -pthread -L/usr/local/lib -L/usr/local/lib
  LIBS     = -ljbig -llcms2 -ltiff -lfreetype -ljasper -ljpeg -lpng15 -lwmflite -llzma -lbz2 -lxml2 -lz -lm -lgomp -lpthread
fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented

Thanks for your response. can you try Forget instead of None? I'll see if the default of NorthWest is a valid default for the cases where I "reset" the gravity to None.

protools’s picture

protools commented

try Forget instead of None where ?

dman’s picture

dman commented

You posted 

gm convert -gravity None '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose src-over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

so ...
try

gm convert -gravity Forget '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose src-over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

I don't see 'Forget' listed in the GM docs though (thanks for the link).. NorthWest is probably the better fallback.

protools’s picture

protools commented

in command line i try:

gm convert -gravity Forget '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose src-over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

result: gm convert: Unrecognized gravity type (Forget).

gm convert -gravity NorthWest '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose src-over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

result: gm convert: Unrecognized compose operator (src-over).

dman’s picture

dman commented

I can't find src-over in either graphicsMagick OR imageMagick reference

Could be it's just wrong and IM was failing silently but defaulting to 'over'

protools’s picture

protools commented

maybe this help:

http://www.imagemagick.org/Usage/compose/#watermark

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented

I will have another look at it: http://www.imagemagick.org/script/compose.php:

The following alpha blending (Duff-Porter) compose methods are available:
...
src-over The source is composited over the destination. this is the default alpha blending compose method, when neither the compose setting is set, nor is set in the image meta-data.
...
Any of the 'Src-*' methods can also be specified without the 'Src-' part. For example the default compose method can be specified as just 'Over'.

So, using just over (if that works in GM) will be better.

@protools: can you do a last test with GM:
gm convert -gravity NorthWest '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

@protools: -watermark seems to look more like masking, not composing 2 colored images.

Note to ourselves: always add link to IM documentation to IM toolkit specific functions.

protools’s picture

protools commented

incorrect syntax i find this post:
http://stackoverflow.com/questions/12300866/graphicsmagick-position-item...

The following ImageMagick command should work:

convert \
-composite \
-geometry +10+20 \
-gravity southwest \
background.png \
logo.png \
result.png

For GraphicsMagick this needs to change to:

gm \
composite \
-geometry +10+20 \
-gravity southwest \
logo.png \
background.png \
result.png

I try:

gm                   \
   composite         \
  -geometry +10+20   \
  -gravity southwest \
   '/www/mysite/public/watermark.gif' \
   '/www/mysite/public/node.jpg'    \
   '/www/mysite/public/node_water.jpg'

and i have good result

dman’s picture

dman commented

Once again I'm confused. Fecking IM docs say different things at
http://www.imagemagick.org/Usage/compose/
http://www.imagemagick.org/script/compose.php

If "over" works on its own across both versions I guess that's the better choice. Makes total sense. It's annoying that GM doesn't follow the IM precedent though, and I don't know how many of these quirks we need to follow...
fietserwin has it under control here.

And yeah, the IM -watermark is unrelated to our 'overlay'. It's just that to make a 'watermark' is a common way that the overlay is used and I added the label so people could find what they thought they were looking for.

protools’s picture

protools commented

when i try gm convert -gravity NorthWest '/www/mysite/public/ibanner.gif' -geometry +0+449 -compose over -composite -quality '75' '/www/mysite/public/node.jpg' '/www/mysite/public/node.jpg'

gm convert: Unrecognized option (-composite).

gm convert and gm composite - is different command

http://www.graphicsmagick.org/GraphicsMagick.html

dman’s picture

dman commented

If GM treats the same arguments differently than IM, then that puts it right into the 'unsupported' camp.
Until someone wants to make a fork of the module dedicated to just this.
I am seeing a slippery slope in supporting a knock-off version if it doesn't do backwards(sideways?)-compatability

protools’s picture

protools commented

If "over" works on its own across both versions I guess that's the better choice. Makes total sense.

I think this is the best way

GM has better performance and better choce in big progect

Maybe little module for wotermarking ? :) I really need :)

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Status: Postponed (maintainer needs more info) » Active

gm composite is currently not possible. The Imagemagick module, that provides the IM toolkit and support for gm, utilizes a hard-coded "gm convert". To solve, we would first need to split off a separate issue in that queue. However, I'm afraid it won't be that easy as using composite instead of convert means that combining other effects becomes kind of impossible. (I guess that gm convert ... composite ... convert ... is not allowed.)

Anyway, setting to active as we have the information from OP. We will have to decide on how to handle this specific case or even supporting GM in general.

dman’s picture

dman commented
Title: Overlay (watermark) Action » Overlay (watermark) Action - GraphicsMagick
Category: bug » feature

To put this into perspective.
Current stats show 53,134 sites using this package. With either GD2 (the vast majority) or ImageMagick proper ( no more than 6116, and the intersection of these sets has to be much smaller )

This is a Feature Request to adjust working code to adapt to an unsupported alternative. GraphicsMagic is looking like an unknown quantity.

This is a bounty issue.

If your business case thinks it's worthwhile to deliberately choose the unknown GraphicsMagick instead of the currently recommended library - then your project may fund the new development and testing of this adaptation. Though I'd actually suggest you instead fund the GraphicsMagic team to make it more compliant with the touchstone library.

This is not to try and extract any support from you to us (I'm not fishing here) - it's to say that
- by choosing a library that has less than 1 % visibility on our install base
you are excluding yourself

Your best decision is to use the working library (IM) - not an unsupported custom branch (GM).
Or get your business to pay the difference. Please make the right call.

I'm a standards freak, and it hurts my head when libraries or APIs claim to follow a standard ( "be feature-compatible" ) but then ... don't.
It's not our problem, and we shouldn't have to pay hours of testing time just to support incomplete or wrong implementations.

PLEASE use something we know can work OR choose to bounty your own feature request.

Though we love a little challenge, fietserwin and I both have better things to spend time on than the <1% of cases that don't want to use the known-good solutions.

Sorry if this sounds harsh - but really : 283,000 downloads vs one... : this is an edge case - and you've chosen to make it difficult for yourself. We can't be responsible for your chosen replacements inconsistencies.
The easy answer is DDTT

I DO think that his debugging process has helpfully exposed a few assumptions (always fun) - but it's beyond the point where it's the fault of the imagemagick commands, and now where GM is an incomplete clone of IM.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented

You are right, but until the -compose problem came up, it was also an issue about the recent change in #1999140: Canvas effects using imagemagick might fail due to earlier -gravity settings using a non-documented (at least I can't find it) but (at least on Windows) listed gravity specification as well as the src-over versus over difference. I'm willing to look into that but do indeed see the gm convert versus gm composite as a rather fundamental (and AFAICS unsolvable) compatibility problem between GM and IM.

- I will ask the imagemagick toolkit in how far they want to officially support the gm fork as well.
- The usage statistics are quite interesting and put use of IM versus GD in perspective but I'm afraid that also has to do with our lack of good and complete support for IM (even stated so on our project page).

dman’s picture

dman commented

Yeah, some interesting debugging HAS turned up, and I really do appreciate that.

And argumentum ad populum isn't my favorite rhetorical device .. but "standards" - even if that "standard" is only the example set by IM - is a strong place to stand.

If we can work around the gravity thing without also breaking - thats a good thing. Probably also more stable for back-compatibility if that's an issue (IM on hosted servers IS likely to be from lasts decade)

The other stufff you'd have to push back and petition on imagemagick.module project, and even then ...

at the time I started supporting IM at all, it was 15% usage. (estimated) and always have had that disclaimer that it was up to folk who used it to fix problems they found.
- IM support on low-end hosts was JUST-NOT-THERE.
- IM support on medium-level hosts was possible, but anyone who made the choice to use IM and had a reason to do so was probably
- on their own server and knew that they needed better-performance image processing
and those folk also had the clout to do an upgrade when needed.

I support those problem-solvers. But choosing IM at all means you think you know better than GD.

(In other news, I should stop doing forum support after half a bottle of rum)

protools’s picture

protools commented

I don't want to dispute. Shovel is used more often than nanotechnology, Drupal 6 more often than Pressflow, but it is not an argument to settle.

ImageMagick module support GM and standart imagecache style all works.

Ok. I need only one little sings - wotermarking presset with GM tools.
Can I do it with http://drupal.org/project/im_raw ?

Thanks for you help.

I can pay. Contact me if you can do it.

dman’s picture

dman commented

I'm in favor of supporting a couple of HOOKs at our end to allow intelligent switching depending on the library used,
And that's the natural way to extend this request. But not to take on support for it.

That means a GM library extension could be derived pretty easily.

THOUGH - it's really a case for a stand-alone image processing library the same shape as imagecache.module - which is allowed to be a stub to imagecache actions performed by imagecache_actions as currently work in places we know they work.

I'm not sure, but so far it sounds like the change needs to be made by either patching imagemagick.module or replacing it. (I'd replace it, as it feels that IM and GM are different beasts)

dman’s picture

dman commented

Addendum -
It looks like imagecache_raw is the equivalent of imagecache_actions:customactions.
And probably has the same issues we discuss here about not being able to change the actual invocation - which seems to be the issue.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented

im_raw will run into the same problem: in GM, -compose is not an option of gm convert but a separate tool. I could not find much information about it, but this thread may contain a way to do compositing within gm convert: http://sourceforge.net/p/graphicsmagick/discussion/250738/thread/a48fadf4

If that turns out to be working, I guess you can use im_raw, and/or we may be able to make some changes that keep both IM and GM satisfied.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Issue summary: View changes

fix

loze’s picture

loze commented
Issue summary: View changes

2 years later, has anyone made any progress with getting image overlays to work with GraphicsMagick? I am still unable to make this work with the latest version.

thanks.

b-prod’s picture

b-prod commented
Status: Active » Needs review
StatusFileSize
new imagecache_actions-graphics-magick-compatibility-2005228-28.patch1.68 KB

This patch is a starting point to handle compatibility with Graphic Magick and makes canvas overlay work as expected.

Question: should this be handled by Image Cache Actions module (seems reasonable, as this module defines the canvas related actions in behalf of Image Magick module) or should the Image Magick module take care of the conversion of the options (not sure, since Image Magick is only a wrapper for the libraries)?

b-prod’s picture

b-prod commented

Note: you need to clear the cache to get the new implemented hook to be recognized.