[Typo3-dev] Image Processing API - getting rid of IM

Martin T. Kutschker Martin.no5pam.Kutschker at blackbox.n0spam.net
Thu Sep 9 10:22:42 CEST 2004


Daniel Brün wrote:
> 
>> One approach could be to define sub-APIs for the image-API, so eg I 
>> could do format conversions with GD, but text processing with 
>> ImageMagick, etc
> 
> Yes, that's the way we thought it should be!

I should be able to install multiple "image processors" and choose the 
best one for each specific task. eg if I think GD2 is best at format 
conversion, but my home-made tools is better for something else.

>> The above solution has the disadvantage that chaining of operations 
>> becomes complicated. Possibly a high number of temporary files will be 
>> created.
> 
> The Image-Processing-class keeps an image in memory for multiple 
> operations on it. This can not work with IM though, because IM only 
> operates on files.

Please note that the in-memory formats are incompatible. A GD "object" 
cannot be processed by PHP-ImageMagick or any other PHP extension.

I am talking about chaining commands that involves multiple sub-APIs. In 
ths scenario different implementations may be invoked (GD, ImageMagick, 
GIMP, ...).

I am thinking about an algorithm that chooses the best path for you. 
Either try to keep as much as possible im memory or choose always the 
besst tool.

Though there migh be another case where chaining may be possible by 
issuing one single "does-it-all" shell command (depends on the tool of 
course).

> It would be perfect if GD2 could do all the stuff, so that no IM is 
> needed anymore.

If GD2 did all the stuff, we wouldn't need this API.

>> Anyway I'm all for it. But please let's do stuff right. IMHO there is 
>> no point in being 100% (TS) backwards compatible as the current API is 
>> highly ImageMagick orientated. Better create a new API and make stdimg 
>> (t3lib) a wrapper for the new stuff.
> 
> Well, I don't need backwards compatibility, but Kasper and most other 
> folks on the list will scream if the new solution is not...

We need reasonable backwards compatibility. That means all your TS suff 
should work, but I wouldn't hesitate to find and rewrite all calls to 
the current graphic class in the Core (if necessary).

BTW, I'd choose the Typ3 service mechanism as a basis for the API.

Masi





More information about the TYPO3-dev mailing list