[TYPO3-dev] Creating an image-processing framework

[Michael Stucki]

Hi Andreas,

I agree with Martin that the idea is not new, though there is not even a
concept yet...

> one of the things I have always disliked about TYPO3 is the setup -
> especiall the part of configuring image-processing. Each
> ImageMagick-version behaves differently, and there are also bugs in the
> setup-tool so it's a PITA to setup e.g. ImageMagick 6 for use in TYPO3.

Yes. However this is not mainly an achievement of TYPO3 but ImageMagick.
They have changed their API so often that I wouldn't change anything until
we have such a service based system ready.

> Recently, I had to setup a quite a number of installations on one server,
> so I had to repeat all the steps over and over again, and as I said, IM 6
> and T3 are not the best friends, so I really became annoyed...

<hint>Use GraphicsMagick! :-)</hint>

> 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...

> The show-stopper of this would be that the configuration for the different
> ImageMagick versions is carried within the service. So when an admin
> installs TYPO3, the InstallTool will call a class within the services
> parent-class, which will then figure out the ImageMagick/GraphicsMagick
> version and present a preset configuration to the user.
> 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.

> If a version is not found within the presets, the service could try to
> find a similar version (e.g. we don't have 5.5.7, but we have 5.5.6 oder
> 5.5.0) and ask the user to test this preset, adjust it and submit the
> results.

I don't think that this will become a big problem. Just do some research,
find out _when_ the IM API has been changed, and provide "drivers" for
these versions.

So in case there was an API change in 5.1.2 (yes such scenarios are possible
with ImageMagick! ;-)) but no more changes until 5.2.0, then the driver of
5.1.4 would have to use the 5.1.2 driver automatically...

> The advantage of removing direct image-processing functionality from the
> core is that the imageproc-extension could be updated independently, e.g.
> to add new configurations or solve bugs with certain versions.

I think this is not a problem since we have a monthly release cycle. In
fact, the image-processsing _must_ remain in the core as a system
extension...

> So, what do you think of this? I'm excited to hear your comments :)

Great idea, go ahead!

Regards, michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/