[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