Seb, would you mind to share with us the main guidelines for an ImageMagick-Zope implementation like yours? :) I think you're right on the subject of setting up separate processes. I'd use Photoshop if there was a straight method to Photoshop from Zope and viceversa, in Windows. But there's not, and at this very moment it's neccesary to deal with OLE automation controllers, prior to any Zope acquaintance. Although the farm idea is perfectly suited for an intense image-processing environment, I prefer to store new image sizes (like in ZPhoto and Photo) and only process once for every new image. I think that Marc's ImageTag hotfix and Photo/ZPhoto products might need to be merged in the standard image object: A standard image may or not contain its own other resized versions, as a user's choice, AND a standard image's tag methods should be able to custom-resize it on the fly, using PIL (in the medium term I expect PIL to workout its quality issues). What does the list think about this? :) Ausum Seb wrote:
I too use ImageMagick. Its quality is excellent, and it handles a huge variety of image formats (e.g. PSDs, PhotoCD...).
You'll have a hard time tracking down PyMagick. However, as Shane has pointed out, is there a compelling reason for using python wrappers around native code anyway? If you use popen2 or similar modules, you get to start the conversion in a separate process, and connect to its input/output/error streams using pipes. With (potentially) intensive processes like thumbnailing a Photoshop image of unknown size, aren't you better off doing it in a separate process anyway? You could even farm off conversion routines to a separate box.
seb