Features using this module

• Image galleries (thumbnail creation) : resize/crop
• Banner generator (2.24)
• Teaserliste mit einer Teaserflaeche if text is a generated image

Features to be implemented in approximate order of priority/importance

• Change ImageFilteringDialogHandler into a SaveHandler MGNLIMG-5@jira / MAGNOLIA-2272@jira
• Really enable multi filtering, or at least different filters. The current situation is that the usage of the CropAndResizeFilter is hardcoded.
• Repeatable control (upload n images, upload+crop n images, ...) MME-29@jira
• Allow processing of image without saving dialog first for uploading (i.e currently one needs to open and save the dialog once to upload the image, then a second time for the image to be processed) MGNLIMG-7@jira
• Support filtering images from other sources (DMS): MGNLIMG-15@jira
  • In the case of a text overlay, we must then be able to use document properties to influence the rendering (i.e copyright to be overlayed on the image)
• Support "unselected" set of images: user selects a folder of images from DMS and this is the source for an image gallery, including thumbnails generation
• Filters configuration (/modules/*/imagefilters - or in module config at first if easier)
  • an image filter is named
  • has a set of parameters ("blur", "80%", "red", "opacity:60%", ...)
  • more parameters can be set by author (background image, crop info, ...)
  • do we need a 3rd level of configuration (values in the dialog - as it is currently the case to configure the cropping presets)
• Support both onSave and onDemand generation:
  • onSave is currently implemented
  • onDemand could be implemented using a filter/servlet hooked on /.generated-images with urls in the form of /.generated-images/path/to/content/binary/namedFilterConfiguration...:
    • no parameter should be passed in url to avoid hacks
    • urls should be kept relatively short and easy to generate
    • if both mechanisms supported, there will either be the need to also pass the "configuration path" in the url (path to cropInfo property, for example). Otherwise, we could live with the fact that templaters will need to know which mechanism is used when they write their templates.
  • both mechanisms could potentially store rendered content in either the original content node or a specific workspace. Both have advantages and inconvenients. (external workspace: easy to flush, but also less "visible")

Implementation/technical details

• Code cleanup, see TODOs - some code is not needed since 3.5
• Quickly went through the code and implemented a grayscale filter and a text overlay filter; things to review:
  • how filters are created/configured
  • how filters are mapped to dialogs (i.e how the designer chooses which filters to apply)
  • how controls can influence filters (i.e. enduser chosen values passed to filters)
• Generic filters: http://www.jhlabs.com/ip/filters/index.html provides a nice api which we could reuse for all "effects" type of filters (grayscale, colors, blur, etc) - pretty trivial as all filters have an empty constructor and setters for their specific parameters. (this is what I used for my grayscale p.o.c)

Usage scenario

Designer configures filters or dialogs to generate desired images (grayscale, resized, added border and text overlay) so that authors only have the minimal amount of options. (upload or select a background image, enter the text to overlay)