Takaka: Eclipse, Image Processing Plug-in

Publisher’s version / Version de l'éditeur:

Vous avez des questions? Nous pouvons vous aider. Pour communiquer directement avec un auteur, consultez la

première page de la revue dans laquelle son article a été publié afin de trouver ses coordonnées. Si vous n’arrivez pas à les repérer, communiquez avec nous à PublicationsArchive-ArchivesPublications@nrc-cnrc.gc.ca.

Questions? Contact the NRC Publications Archive team at

PublicationsArchive-ArchivesPublications@nrc-cnrc.gc.ca. If you wish to email the authors directly, please see the first page of the publication for their contact information.

https://publications-cnrc.canada.ca/fra/droits

L’accès à ce site Web et l’utilisation de son contenu sont assujettis aux conditions présentées dans le site LISEZ CES CONDITIONS ATTENTIVEMENT AVANT D’UTILISER CE SITE WEB.

2007 International Conference on Image Processing, Computer Vision, and

Pattern Recognition (ICPV07) [Proceedings], 2007

READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS WEBSITE. https://nrc-publications.canada.ca/eng/copyright

NRC Publications Archive Record / Notice des Archives des publications du CNRC :

https://nrc-publications.canada.ca/eng/view/object/?id=1452addf-8fdb-42c7-a8b1-cf8fe736cbb6

https://publications-cnrc.canada.ca/fra/voir/objet/?id=1452addf-8fdb-42c7-a8b1-cf8fe736cbb6

NRC Publications Archive

Archives des publications du CNRC

This publication could be one of several versions: author’s original, accepted manuscript or the publisher’s version. / La version de cette publication peut être l’une des suivantes : la version prépublication de l’auteur, la version acceptée du manuscrit ou la version de l’éditeur.

Access and use of this website and the material on it are subject to the Terms and Conditions set forth at

Takaka: Eclipse, Image Processing Plug-in

Takaka: Eclipse Image Processing Plug-in

Glen Newton

National Research Council Canada Ottawa, Ontario Canada

glen.newton@nrc-cnrc.gc.ca

Dwight Deugo

deugo@scs.carleton.ca

ABSTRACT

The Takaka Eclipse plug-in is an Eclipse plug-in based image processing tool addressing more advanced image processing requirements, such as those needed by the scientific, engineering, and medical (STM) image processing community. Using its own internal plug-in architecture for extending its functionality, the Takaka image processing system is based on the Java Advanced Imaging (JAI) API from Sun, which supports a rich array of formats, representations, color models, sampling models and the image processing capabilities needed in STM image processing. The Takaka Eclipse plug-in uses the Takaka architecture to offer a proof-of-concept Eclipse image processing plug-in, leveraging the rich functionality offered by the JAI through Takaka.

Keywords

Eclipse, Plug-in, Image Processing, Java, Pipeline, Java Advanced Imaging.

1. INTRODUCTION

Tools such as Photoshop, the GIMP or ImageMagick are commonly used by users to manipulate their digital photographs. Many of the functions of these tools use image processing to achieve the results users require, such as image sharpening, smoothing, red-eye correction, speckle removal, and various visual special effects, all relying on underlying image processing methods and algorithms.

Image processing in the scientific, medical and engineering (STM) domains have requirements which are very different and are more demanding than users manipulating their digital photographs. Images in these domains are often generated using specialized or advanced sensors, with greater spatial and spectral resolution. Often researchers and scientists have functionality requirements which are quite different from casual users of image viewing/manipulation software. Unfortunately, in the Open Source Software (OSS) milieu, the image processing needs of these users and image data are not well supported.

1.1 Problem

OSS image processing applications and toolkits are primarily oriented to a simpler sub-set of image formats, representations, sampling models, color models and user needs. Image formats and color models are limited to those supported by the mainstream image formats:

8-bit gray level images

8-bit color with look-up-table (LUT) images 24-bit color images (RGB)

32-bit color (RGB plus 8-bit alpha overlay)

However, for STM image processing, greater flexibility is required due to the greater range in formats, representations, sampling models, color models and the need for external non- image datasets. For example, modern remote sensing has moved from multispectral imaging (a small number of bands, such as seven bands for Landsat [1]) to what is known as hyperspectral imaging [2] that can involve hundreds of image bands. This

information can also be represented with larger than 8-bit integers or with floating point values, which are not handled easily or not at all by mainstream image formats or image manipulation systems. For example, [3] use 168 bands, 12 bits each, of the AVIRIS [4] sensor's 220 bands to classify mineral type in Nevada. In [5], future military scenarios where hyperspectral imagery and its image processing are described. Vineyard conditions are assessed using hyperspectral imagery in [6], and in [7] multispectral imagery is used in landscape and cultural heritage analysis. Other non-remote sensing examples include detecting bruises, surface defects and contamination on apples [8] and the estimation of wetlands ammonia levels [9].

1.2 Goals

The primary goal of our approach is to investigate how Eclipse can be used as a platform for providing an effective and flexible Open Source image processing tool for researchers in the STM domains using Java Advanced Imaging as the image processing engine.

1.3 Objectives

The objective of our approach was to develop a prototype that includes the integration of the underlying JAI image processing with an Eclipse plug-in. This plug-in offers

straightforward functionality, including image import, export and the implementation of a number of exemplary image processing filters. The plug-in provides a simple but usable user interface and operate on a significant subset of standard/popular image formats. The plug-in is also extensible so as to allow users to add new filters and import and export capabilities. It is also desirable for the software layer - which wraps the JAI and whose interfaces are exposed and used by the Eclipse plug-in - to be created so as to itself be extensible and to allow re-use in other environments.

1.4 Outline

In the following sections we provide a background to review related Open Source software and projects (including related Eclipse plug-ins), an examination of the Java Advanced Imaging software, and a brief review of existing image

processing/manipulation plug-in architectures. Next our Approach section describes our design and discusses our implementation

decisions. Then the Results section goes over the issues discovered and addressed in our implementation. In our conclusion we discuss how our goals and objectives have been met and reviewing future work in this area.

2. BACKGROUND

2.1 Related OSS

There are a number of related OSS projects to our work. These fall in to two broad categories: end-user applications and toolkits for use by programmers. ImageMagick [10] and Netpbm [11] are the mainstays of OSS image processing/graphics file manipulation, and have their roots in the 1980s and early 1990s. These are both primarily command-line tools in the Unix tradition, whose most recent incarnations are written in C++. APIs for other languages exist for both projects. ImageMagick has more functionality and is supported by a parent company. Netpbm is a little more spartan in its operation and functionality. Both of these tools come standard with many Linux distributions and often form important parts of other more user-friendly applications. The GNU Image Manipulation Program (GIMP) [12] is a more recent application, and is seen by many to be an OSS alternative to Adobe Photoshop. It offers a graphical interface for the direct manipulation of raster images. Its implementation includes a plug-in architecture, and many of its plug-ins use image processing in their implementation. One GIMP plug-in, Gluas [13], is a test-bed for image processing. It provides a Lua [14]

programming language interpreter allowing users to write image processing code and test it inside of GIMP.

More directly related to Takaka, ImageJ [15] is a GPL Java image processing application inspired by the NIH Image [16], a Macintosh--only application. ImageJ is an end-user graphical application specifically addressing scientific image processing, and includes macros and a plug-in architecture [17]. According to the website, there are over 200 macros and 300 plug-ins available for ImageJ. ImageJ data types includes 8-bit grayscale or indexed color, 16-bit unsigned integer, 32-bit floating-point and three band 8-bit (RGB color) images. It can read GIF, JPEG, BMP, DICOM, FITS, PNG, PGM and ASCII, and can write GIF, JPEG, BMP and ASCII image formats. Its image processing capabilities are derived from an underlying ad hoc image processing toolkit implemented by the same authors.

2.1.1 Related Eclipse Plug-ins

There are two Eclipse plug-ins which are related to our approach: MyEclipse Java Image Editor/Preview [18] is a commercial Eclipse plug-in which offers simple image viewing and manipulation, oriented to the casual user. Perhaps more closely related is [19] and [20] that describe an Eclipse plug-in that provides a pipelined module system for image processing (and other scientific processing). Except for the publications cited and some brief mentions on a small number of web sites, an actual download or detailed description of this plug-in could not be found at the time of this writing.

2.2 Java Advanced Imaging

Java Advanced Imaging (JAI) is a Java image processing toolkit first released by Sun in 1999 [21]. The JAI is an extensive, powerful, high performance, interoperable, cross platform, extensible, object-oriented image processing which also includes facilities for distributed processing and the ability to take advantage of hardware acceleration. Compatible with the AWT/Swing and building in the Java2D imaging model, the JAI introduces several new and powerful concepts, such as tiling and deferred execution, which offer significant run-time

optimizations. For some platforms (Solaris, Windows, Linux) the JAI includes native libraries which it can also use to increase performance.

The JAI has storage types for images (byte (8-bit), short (16- bit), unsigned short (16-bit), int (32-bit), float, and double), a number of different sample models (component, float component, banded, pixel interleaved, single pixel packed, multi-pixel packed), five different color models (direct, index, component, packed, float double) and over 30 color spaces, including the device independent CIE [1] color space, the Kodak PhotoCD color space, as well as the more common RGB and gray scale color spaces.

2.3 Image Processing/Manipulation Plug-in

Srchitectures

Photoshop and the GIMP both use plug-in architectures for extension. Photoshop is a C++ based plug-in architecture, which is rather complex and quite powerful, if not too object oriented, and includes facilities for user interactions and state callbacks. The GIMP plug-in architecture is C based, and is significantly simpler in its design and the functionality it offers in comparison to that of Photoshop.

ImageJ also uses a plug-in architecture for extension. It defines two interfaces:

1. Plug-in: for plug-ins that do not require an image for input.

2. Plug-inFilter for plug-ins that require an image for input.

While designed and implemented in a more object oriented than either the GIMP or PhotoShop plug-in architecture, ImageJ

appears to have a number of methods that reveal a strong non object oriented influence. For example, the integer value returned by the setup() method is used to determine on what type(s) of images an ImageJ plug-in can operate. A more object oriented solution might be to use sub-classing or interface implementation (i.e. extends HandlesEightBitGrayImages).

3. APPROACH

Initially, it was thought that the Eclipse plug-in would be implemented with a thin abstraction layer over the JAI . However, it was realized that in order to have the ability to change either the back end image processing engine or the front- end user interface, or both, as well as to meet the objective of supporting re-use - an plug-in architecture would be a better design choice. This would allow for easy extensibility and interoperability while allowing image processing plug-in implementors the full power of theJAI API.

The Eclipse plug-in architecture was evaluated as a possible plug-in layer. The design - while quite general - does not offer the functionality needed in an image processing plug-in architecture. Instead, an image processing plug-in architecture was proposed: the Takaka Image Processing system.

3.1 Design

The design phase consists of three main stages: 1. Takaka plug-in architecture

2. Takaka SWT prototype 3. Eclipse GUI design

3.1.1 Takaka Plug-in Architecture

The Takaka image processing system looks to provide the appropriate architecture to address the needs of STM image processing. There is a number of use cases identified that an STM image processing plug-in architecture should address:

1. Create an image or image set, by reading it from a file system or by creating it from some software method (i.e. synthetically generated image).

2. Write image or image set to the file system or other persistent store.

3. Create an arbitrary dataset, by reading it from a file system or other persistent store, or by creating it from some software method (i.e.) synthetically generated dataset).

4. Write an arbitrary dataset to the file system or other persistent store.

5. Generate information or statistics about an image 6. Generate information or statistics about a dataset 7. Apply a transformation to one or more images, and zero or more datasets, generating zero or more images and zero or more datasets (but at least one of either).

For the initial Takaka version, the design and implementation scope was limited to the read, write and filter image processing - only functionality (use cases 1, 2, 7), deferring image statistics use case (5), the dataset oriented use cases (3, 4, 6), and the dataset parts of use case 7. These initial use cases correspond to the following plug-ins:

Import: this plug-in type produces one or more images, and is meant create the images from image files or algorithms that create synthetic images.

Export Iimage: this plug-in type takes one or more images, an optional data object and exports the image an image format on the filesystem.

Image Filter: this plug-in type takes one or more images, and produces one or more images.

The Java interfaces and classes which implement the Takaka plug-in architecture can be seen in the class diagram in Figure 1. Figure 1, Takaka Class Diagram

The methods defined in the AbstractTakakaPlug-in interface and other Takaka interfaces are influenced by both the GIMP and ImageJ plug-in architecture methods:

void init(Properties p) - this very similar to the GIMP's init() method and the ImageJ int setup(…) method. 

void quit() - this very similar to the GIMP quit() method.



TakakaPlug-inInfo query(…) - while it has a similar method name as the GIMP query() method, the Takaka method is somewhat different from the GIMP method. 

ImageData invoke(Properties p) - this method is similar to the GIMP and ImageJ run(…) methods and is where the real work of the plug-in is performed. The method name run was not used to avoid confusion and name collision with the run methods of the

java.lang.Runnable interface and java.lang.Thread class.

3.1.2 User Interaction

The plug-in architectures of Photoshop, the GIMP, and ImageJ include the ability to interact with a GUI to solicit input from the user. In all three architectures, the user interaction toolkits and the plug-in API are very closely coupled, in some cases to the extent where they cannot be disentangled. In Takaka, the decision was made to have user input as loosely coupled as possible to allow for almost any Java GUI toolkit to be used. Therefore, the user input is abstracted in the interface AbstractUserInput, and any external class implementing this interface is used by Takaka plug-ins which implements the AbstractNeedsUserInput interface. Takaka instantiates and delegates user input to the appropriate AbstractUserInput object, getting the class name from the Properties object that is passed in on the invoke, readIn, writeOut methods of the AbstractFilter, AbstractInput andAbstractOutput interfaces, respectively. There is a convention for the key for this property:

takAbstractUserInputClassKey.[full class name]. So, for class gnu.takaka.imports.readImage which might want to delegate to the gnu.takaka.util.SWTChooser class for user input, the entry in a Properties file might look like:

#

takAbstractUserInputClassKey.\ gnu.takaka.imports.readImage=\ gnu.takaka.util.SwingChooser #

If this property is not set, then the plug-in does not solicit user input and assumes the input values are in the appropriate keys in the Properties object which are specific to the plug-in. If these are not provided, the plug-in operates using its default values.

3.1.3 Takaka Plug-in Provenance

The AbstractTakakaPlug-in interface includes a method: public TakakaPlug-inInfo query(String iso3CharLang); The TakakaPlug-inInfo class has a number of methods, which provide provenance and other information about the plug- in with which it is associated. These methods include

information about the name, date, copyright, version, author, license, help, and parameter properties of the plug-in.

3.1.4 Image Input Validation

Both ImageJ and the GIMP have rather static and limited mechanisms for determining the types of images on which their

plug-ins can operate. ImageJ defines a number of static ints DOES_16, DOES_32, DOES_8C, DOES_8G, DOES_ALL, DOES_RGB, DOES_STACKS which code for 16-bit gray scale images, 32-bit floating point gray scale images, 8-bit color images, 8-bit gray scale, RGB images and image stacks, respectively. Plug-ins can indicate they can operate on more than one of these image types. The GIMP uses strings to indicate image types: RGB, INDEXED or GRAY, with an alpha channel indicated by appending an A to these three.

Takaka takes a different approach. Takaka plug-ins

implement a method, isValidInput which takes an ImageData object and indicates as to whether it can operate on the image(s) that this object contains. This is a richer, more flexible and more precise model than that of the GIMP, ImageJ or PhotoShop. For example, whereas a plug-in in the GIMP or ImageJ can indicate that it can operate on an RGB or 32-bit color image respectively, a Takaka plug-in can indicate much more precisely that it can only operate on a 32-bit image which has a component sample model, a direct color model and a CMYK color space. Clearly the

inheritance or interface implementation solution mentioned in Section 2.3 was not used by Takaka, as the combinatorics even with interfaces would be overwhelming. For the JAI: 6 images types * 7 sample models * 5 color models * 30+ color spaces = 6300+ combinations!

In addition, the Takaka ImageData object can encode any number of different image types, so a plug-in can indicate it needs a certain number of images, each with its particular type/sample model/color model/color space signature.

3.1.5 Takaka SWT Prototype

An SWT stand-alone prototype was implemented to

experiment with, and validate, the SWT toolkit and the Takaka image processing system. This prototype is spartan in its GUI design, as show in Figures 2 and 3, but provides enough functionality to test and validate the Takaka plug-ins, as well as the coupling of the SWT toolkit to the Takaka plug-ins. In implementing the prototype, a major issue surfaced: JAI uses its own image classes internally, but has methods to convert these classes to java.awt.image.BufferedImage. However, SWT uses org.eclipse.swt.graphics.Image class which is not compatible with the java.awt.image.BufferedImage class. Not compatible in the sense that no built-in method exists to easily convert from one to another. With some investigation, a conversion example [22] was found. However, on examination it was found not to scale, as every

combination of

java.awt.image.ColorModel,

java.awt.image.SampleModel and java.awt.image.ColorSpace would have to be implemented to provide a complete conversion solution. Instead, the decision was made to use the

org.eclipse.swt.awt.SWT_AWT, which allows for AWT components to be embedded inside of SWT components, and allow for the direct use of BufferedImages.

3.1.6 Eclipse Plug-in GUI Design

The Eclipse plug-in design used the knowledge gained in the prototype to implement an Eclipse plug-in as an Eclipse view. The design includes the use of modal menus, the ability to repeat the last filter used (functionality discovered in evaluating the prototype), a more easily accessible Undo functionality (as a button instead of on a menu with the filters), as well having separate menus for import, export and filter.

3.2 Technology

 Eclipse v3.2  Linux Suse v10.2  Java JDK v1.5.0\_06  JAI v1.1.2\_01  SWT v3.235

4. RESULTS

Both the prototype (Figures 2, 3) and the Takaka Eclipse Plug-in (Figure 4) are useful starting points for the development of an STM image processing platform. The Takaka image processing system, with its own plug-in architecture, proved to be an effective layer on top of the JAI, allowing for easy

extensibility. Figure 2a, File Menu Figure 2b, Filter Menu

4.1 SWT Prototype

The prototype (Figures 2 and 3) shows a very spartan test implementation showing many of the base objectives for this project, such as reading and writing images, a small list of image

processing filters as well as showing how the Takaka architecture can operate as an effective layer wrapping the JAI.

4.2 Eclipse Takaka Plug-in

The Eclipse plug-in shows the prototype functionality in the form of an Eclipse plug-in view. It implements more image processing filters, using a more user friendly GUI than in the prototype. The Eclipse Takaka plug-in successfully meets the goals of showing how an Eclipse plug-in can be used as a JAI-- based STM image processing tool.

4.3 User Interaction Delegation

Takaka is also successful at abstracting and decoupling GUI toolkits for user input, effectively implementing an additional plug-in system for this functionality.

Figure 1 shows two possible classes for user input each of which implements a chooser both for reading and writing images to the local file system. SWTChooser uses SWT, and

SwingChooser uses Java Swing. Figure 4 shows each used in the prototype, showing the look-and-feel of each (with SWT further delegating to the local windowing environment).

Figure 3a, Loaded Image

Figure 3b, Invert Filter Applied to Image

4.4 Image Processing Methods Implemented

Over twenty image processing are implemented, ranging from simple smoothing and sharpening filters, to more complex methods such as an edge detection filter and the Discrete Cosine Transform filter.

4.5 Issues

The use of org.eclipse.swt.awt.SWT_AWT was not entirely successful. While it solved the SWT Image/AWT BufferedImage compatibility issue, the integration of AWT components with SWT is not seamless and not without minor but annoying GUI problems. The AWT java.awt.Frame, java.awt.Canvas and associated java.awt.ScrollPane used in the implementation seem to not get the resize events when a new and larger BufferedImage is written to the Canvas. It seems that the resize event propagation of the new canvas size to the scroll bars does not take place properly. This appears to be a bug in the implementation of the org.eclipse.swt.awt.SWT_AWT.

Figure 4b, Delegation to SWT Implementation

5. CONCLUSION

The Eclipse Takaka plug-in is successful proof-of-concept of an effective STM image processing system built on the Java Advanced Imaging toolkit. While this implementation is limited in the number of image processing functions implemented, it is a stable and complete design and implementation from which future development can continue. It offers to users an STM image processing application embedded in the comfortable environment offered by Eclipse.

The underlying Takaka image processing plug-in architecture is simple and extensible, and is more flexible than the three image processing plug-in architectures reviewed (PhotoShop, the GIMP

and ImageJ). It is a clean plug-in layer allowing users to avoid the underlying complexity of the JAI API.

5.1 Future Work

5.1.1 Present Implementation

While the present implementation is a reasonable proof-of- concept, it suffers from a number of limitations:



The GUI is quite spartan and limited. A more usable and flexible GUI should be designed and implemented. 

The java.awt.Frame scrollbar issue should be resolved. There are a couple of possible solutions: first, the JAI com.sun.media.jai.widget.DisplayJAI class shows some promise in improved scrollbar accuracy inside of an SWT container; alternatively, the implementation of conversion

from

java.awt.Bufferto,

org.eclipse.swt.graphics.Image for display inside a pure SWT environment should be re--evaluated.



The GUI should also be internationalized. The Takaka architecture supports this, although all of the Takaka filters have only been populated with English-language content.



The image export GUI should support more than just JPEG image format. This is supported already by the JAI and Takaka.



Many of the Takaka filters can have their default values altered, but do not have AbstractUserInput

implementations to provide this functionality. This is why more than one similar implementations of a filter exists, like ScaleFilter and ScaleDoubleFilter, which simply have different default values (0.5 vs 2.0). 

The GUI only supports a linear path, single image model. Takaka supports the combining of two or more image sources to produce one or more images. A new GUI implementation should support this functionality. 

Takaka plug-ins should be implemented as singletons, reducing the object footprint of the framework, but which imposing on developers the need to implement the interfaces in a thread-safe fashion.



Only three of the seven STM image processing use cases mentioned are realized in this project. The other three use cases should have plug-in interfaces designed

for them. 

More complex image processing filters of interest to the STM community need to be implemented, such as a line, circle and generalized Hough transform [1], Fourier transform, area growing, image warping and others.

5.1.2 ImageJ Adapter

An investigation should be made into the usefulness and feasibility of creating an adapter allowing ImageJ plug-ins and/or macros to be used as Takaka plug-ins. This would take advantage of the numerous plug-ins and macros available in the ImageJ community. A less important direction but potentially very fruitful would be to evaluate the cost/benefit of building a JNI-based adapter for eitherGIMP or Photoshop plug-ins.

5.1.3 Complex Image Modalities

Medical and other STM imaging have the need to represent, manipulate and render complex and large image collections. These image collections include medical CT/NMR/PET scans, seismic volumes, stop action photography, video for image analysis, large image mosaics, etc.

The JAI provides for the support of different types of image collections [21]. An abstract superclass called

CollectionImagehas several concrete subclasses which represent common image collection types: ImagePyramid for image pyramids which allow for multiple resolution representations of (usually) large image datasets; ImageSequence for time sequences of images (including timestamps and cameral locations); and ImageStack for planar slices that form a volume. The next steps in this project should include extending the Takaka plug-ins to include interfaces which deal with these image collection types. This would also require an evaluation of the filter interface to see if it could be extended to handle these image collection types or if a new filter type might have to be designed specifically for these.

6. REFERENCES

[1] R. Gonzalez and R. Woods, Digital Image processing, Second edition. Prentice Hall, 2001.

[2] C. C.-I. Chang, Hyperspectral Imaging: Techniques for Spectral Detection and Classification. Kluwer Academic, 2003.

[3] B. J. Ross, A. G. Gualtieri, F. Fueten, and P. Budkewitsch, “Hyperspectral image analysis using genetic programming,” Applied Soft Computing, no. 5, pp. 147–156, 2005. [Online]. Available:

{http://www.cosc.brocku.ca/%18bross/research/gphyper.pdf} [4] R. Green, M. Eastwood, C. Sarture, T. Chrien, M. Aronsson, B. Chippendale, J. Faust, B. Pavri, C. Chovit, M. Solis, M. Olah, and O. Williams, “Imaging Spectrometry and the Airborne Visible/Infrared Imaging Spectrometer (AVIRIS),” Remote Sensing of Environment, no. 65, pp. 227–248, 1998. [Online]. Available: {http://www.utsa.edu/

LRSG/Teaching/ES6973/AVIRIS.pdf}

[5] S. Chai, A. Gentile, W. Lugo-Beauchamp, J. Cruz-Rivera, and D. Wills, “Hyper-spectral image processing applications on the SIMD Pixel Processor for the digital battlefield,” in Proc. IEEE International Workshop on Computer Vision Beyond the Visible Spectrum: Methods and Applications, (CVBVS ’99), Fort Collins, CO, USA, 1999, pp. 130–138. [Online]. Available: {http://ieeexplore.ieee.org/iel5/6340/ 16950/00781102.pdf?isnumber=\&arn%umber=781102} [6] P. Zarco-Tejada, R. Lpez-Lozano, J. Miller, V. Cachorro, and A. de Frutos, “Assessing vineyard condition with hyperspectral indices: Leaf and canopy reflectance simulation in a row-structured discontinuous canopy,” Remote Sensing of Environment, no. 99, pp. 271 –287,

2005. [Online]. Available:

http://dx.doi.org/10.1016/j.rse.2005.09.002

[7] P. Ardissone, P. Boccardo, and E. B. Mondino, “Digital images processing of hyperspectral airborne data - a cultural heritage example,” in New Perspectives to save Cultural Heritage CIPA 2003 XIXth International Symposium,

Antalya, Turkey, 2003. [Online]. Available:

http://cipa.icomos.org/fileadmin/papers/antalya/59.pdf [8] P. M. Mehl, Y.-R. Chen, M. S. Kim, and D. E. Chan, “Development of hyperspectral imaging technique for the detection of apple surface defects and contaminations,” Journal of Food Engineering, no. 61, pp. 67–81, 2004. [Online]. Available: {http://dx.doi.org/10. 1016/S0260- 8774(03)00188-2}

[9] D. R. Tilley, M. Ahmed, J. H. Son, and H. Badrinarayanan, “Hyperspectral reflectance of emergent macrophytes as an indicator of water column ammonia in an oligohaline, subtropical marsh,” Ecological Engineering, no. 21, pp. 153– 163, 2003. [Online]. Available:

http://dx.doi.org/10.1016/j.ecoleng.2003.10.004

[10] I. S. LLC. ImageMagick. [Online]. Available: {http://www. imagemagick.org/script/index.php}

[11] B. Henderson. Netpbm. [Online]. Available: http://netpbm.sourceforge.net/

[12] FSF. The GIMP (GNU Image Manipulation Program) home page. [Online]. Available: http://www.gimp.org/

[13] Ø. Kol°as. Image processing with gluas. [Online]. Available: http://pippin.gimp.org/image processing

[14] W. C. R. Ierusalimschy, L. H. de Figueiredo, “Lua - an extensible extension language,” Software: Practice & Experience, no. 26, pp.635–652, 1996. [Online]. Available: http://www.lua.org/spe.html

[15] W. Rasband. ImageJ: Image Processing and Analysis in Java. [Online]. Available: http://rsb.info.nih.gov/ij/

[16] NIH. NIH Image. [Online]. Available: http://rsb.info.nih.gov/nih-image/

[17] W. Bailer. (2006, July) Writing ImageJ plug-ins: a Tutorial. Upper Austria University of Applied Sciences, Dept. of Media Technology and Design, Hagenberg, Austria. [Online]. Available: http://mtd.fh-

hagenberg.at/depot/imaging/imagej/tutorial171.pdf

[18] myeclipseide.com. Myeclipse java image editor/preview. [Online]. Available:

{http://www.myeclipseide.com/ContentExpress-display-ceid- 71.html}

[19] J. S. Cinly Ooi and E. Bullmore, “A new pipeline-based gui environment for batch processing of data (poster),” presented at OOPSLA ’04, Vancouver, Canada, 2004.

[20] ——, “Human brain mapping 2004,” presented at the Human Brain Mapping, Budapest, Hungary, 2004.

[21] SMC. (1999, November) Programming in Java Advanced Imaging. Release 1.0.1. [Online]. Available:

{http://java.sun.com/products/ java- media/jai/forDevelopers/jai1 0 1guid%e- unc/JAITOC.fm.html}

[22] Eclipse. Snippet156.java: Convert between swt image and awt bufferedimage. [Online]. Available:

{http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snip pets/src/%org/eclipse/swt/snippets/Snippet156.java?view=co}