Zend is a well known Framework for PHP and generally fits well into any Drupal-friendly environment. ODW has some legacy Cocoon applications that provide java-based image manipulations, including extracting and highlighting images. In our current operating environment, the java approach is not ideal. Although there are options to integrate Zend directly into Drupal, it adds to the complexity of the Drupal installation and our preference is to keep the application standalone at this point.
The use of Zend taps into the GD graphics library via PHP, an efficient option in our environment. Still, GD doesn't require Zend, where it becomes necessary is for a native implementation of Lucene. Highlights are placed on images based on coordinates stored in a Lucene index and the solution needs to be able to invoke Lucene queries efficiently. Although the Zend Lucene library support is somewhat dated (2.x), our use in this case is relatively simple.
I followed the common approach for creating a skeleton application:
git clone git://github.com/zendframework/ZendSkeletonApplication.git ImgWorks
And then worked from there. If you download the distribution and do something like:
cd ImgWorks
curl -s https://getcomposer.org/installer | php
The needed pieces will hopefully fall into place.
The layout of the application is largely defined in ImgWorks/module/ImgHl/config/module.config.php. There are current four outputs from the application based on four actions:
- img - highlight search terms on specified region of image
- json - return coordinates in json for search terms in specified region
- cut - extract specified region of image
- ol - provide tiles in response to OpenLayers 3.x requests
The URL pattens all use action/site/collection/reel/page/w/h but vary slightly depending on whether a query is being processed (img and json). The cut action uses x and y parameters for specifying the starting coordinates of the rectangle that will be extracted. The OpenLayers tiles are typically 256x256 but here the height and width of the source image are passed in. This leads to URLs that look like this:
- img - http://mysite.org/ImgWorks/imghl/img/ink/newspapers/bmerchant/03_1871/BM-1871-03-24-03/600/400/town
- json - http://mysite.org/ImgWorks/imghl/json/ink/newspapers/bmerchant/03_1871/BM-1871-03-24-03/600/400/town
- cut - http://mysite.org/ImgWorks/imghl/cut/ink/newspapers/bmerchant/03_1871/BM-1871-03-24-03/600/400?x=200&y=300
- ol - http://mysite.org/ImgWorks/imghl/ol/ink/newspapers/bmerchant/03_1871/BM-1871-03-24-03/3000/6000
The action is specified after the route (imghl), and in these examples:
- site - ink
- collection - newspapers
- reel - 03_1871 (reflecting our newspaper focus, a reel is equivalent to a set
- page - BM-1871-03-24-03 (this is the image name)
- 600 - width (of resulting image)
- 400 - height (of resulting image)
- 3000 - width (of source image - OpenLayers only)
- 6000 - height (of source image - OpenLayers only)
- town - query (not used for cut or ol, the terms are extracted and stemmed to determine highlights)
The business logic is contained in module/ImgHl/src/ImgHl/Controller/ImgHlController.php. The flow is fairly straightforward, it would be worth exploring some different approaches to identifying the best cluster for showing highlights on an image but it's a simple count to determine the most stems in a region for now.
art rhyno ourdigitalworld/cdigs