[TYPO3-dev] Creating an image-processing framework

[Ernesto Baschny [cron IT]]

Michael Stucki schrieb:

> I agree with Martin that the idea is not new, though there is not even a
> concept yet...
> <hint>Use GraphicsMagick! :-)</hint>

Good hint, that just saved me some days ago. I was still using IM 4.2.9
on TYPO3 4.x, and it was no fun (eps/ai support). :)

>> An idea that came to my mind is that a component similar to the DBAL, but
>> for graphics-processing, could help here. I imagine it to be a new
>> service-type, let's call it imageProc. This service implements several
>> subtypes, one for each "supported" image-type (jpeg, gif, png, ai, pdf,
>> tif etc). The service-implementations internally handle what to do when
>> asked for resizing, cropping, rotating, blurring and so on. This would
>> also make it easier to introduce support for new ip-frameworks into TYPO3,
>> e.g. GraphicsMagick (I know, it's already supported... Just an example
>> ;)).
> 
> Would be great! While working on that, there should also be a service that
> uses GDlib only - which may be sometimes slower, but covers almost all
> functionality we are using ImageMagick for...

Hint: look at how we did it in Gallery2 (http://gallery.menalto.com), as
this is the core functionality there and already working for some good
years now.

To sum up how it's done there: All image processing functionality is
controlled by an abstract "GalleryToolkit" API that can be implemented
the way you want. There are implementations called ImageMagickToolkit,
GdToolkit, NetpbmToolkit, etc. The admin can add as many toolkits as he
wants, provided he has the libraries/binaries. Each Toolkit will be able
to handle "their" combination of mime-types and operations/properties.
For example the ImageMagickToolkit is able to perform "thumbnail",
"scale", "crop", "resize", "composite", etc on mime-types it supports
(auto-discovered on Toolkit installation). Then the GDToolkit will be
able to do more or less the same things. Another, JheadToolkit will only
be able to extract certain properties from certain mime-types (Exif-Info
from JPEGs). All those can be combined and cascaded if needed. So I can
also have a Gallery2 installation with "just" GD2 library and no
ImageMagick at all. It will be able to do everything that the GD2
Toolkit is able to produce. Adding more "Toolkits" only adds more
functionality.

This Toolkit concept is already pretty well OO-designed and uses very
common design patterns (factory, etc), which we could borrow.

And also have a look at the ImageMagick toolkit in particular, as it is
able to work pretty well on all possible combinations of ImageMagick and
GraphicsMagick variants without much twists. Of course the very well
thought unit-tests provide that nothing breaks when adding support for
yet another version.

Just one crazy thought: Maybe we could simply "use" gallery2 as our DAM??

>> This would mean that we need to collect the correct configuration for as
>> many ImageMagick-versions as possible, to have a large set of predefined
>> values, so that a high percentage of (new) T3-installations will be
>> covered by the presets.
> 
> Yes. Bernhard Kraft (is he reading this?) has set up an environment with
> different IM versions because he had to test that for the truecolor changes
> in 4.0.

Again, look at Gallery2, we already have all "presets" there, and many
manpower was already inputted there.


Cheers,
Ernesto