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

[Martin T. Kutschker]

Daniel Brün wrote:
> Hi Masi!
> 
>> 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, ...).
> 
> Nonono. You can implement the API with a class that you may call 
> "performance Image Processing" that makes use of GD, IM and GD at the 
> same time.

Of course I could, but doesn't sound too interesting then. We're just 
replacing the GD/ImageMagick-combo dependency with even more dependencies.

That's why I tried to separate the image processing into several "tasks".

You're proposal is probably easier to implement, perhaps I'm just a bit 
overambitious.

>> 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.
> 
> How should an algorithm be able to make that choice? I think the 
> developer makes the choice when developing the class.

Each implementations reports wether it can do a chain (or a part of it) 
in one-sweep (in-memory). The service selector chooses then the fastest 
chain. Though it shouldn't think too hard about it, because the 
optimizer shouldn't suck up more CPU time then the actual image 
processing ;-)

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

No real need for services if you're heading in a one-class to solve it 
all approach. Though I like the implicit ge me the best service feature 
of the service API.

BTW, I think it'd be a good idea to have at least a core set of graphic 
functions and several optional stuff.

Eg. the Typo3 BE relies on image composition for the icons, but doesn't 
need text processing.

Masi