Items large and small which remain to be done before Magick++ 1.0
--------------------------------------------------------------------

* Support an efficient yet simple way to manipulate image pixels and
  colormap (if pseudocolor) via an array style mechanism. Probably
  support image as a two-dimensional array of a derived class of
  Magick::Color. This is a complex problem which will take time to
  resolve since ImageMagick images are of six distinct varieties not
  including the many colorspaces the pixels can be represented in.

  Who wants this?

  Rehan Ahmad <ahmadr@eee.bham.ac.uk>
  Bill Radcliffe <BillR@corbis.com>
  Daniel M. Duley <mosfet@jorsm.com> <mosfet@kde.org> (KDE2.0 developer)
  Paul S. Mostert <pmostert@gte.net>
  Mario Olimpio de Menezes <mario@curiango.ipen.br>

* Support manipulating IPTC profiles directly. Bill Radcliffe
  <BillR@corbis.com> has agreed to write a container class to support
  this.

* Add thread-safety.  The main impact here is with error reporting
  which is synchronous through a function call (ImageMagick design).
  By ensuring that only one error may be reported at a time, and 
  storing the error report in thread-specific storage, Magick++
  will become thread safe provided that only one thread works on an
  image at one time (one thread per image).

  Another issue with thread-safety is that the image reference
  count must be protected, however, even if the reference count is
  protected, this is insufficient to ensure that the current
  revision of the image is not being processed while its data is
  being cloned to a new image for modification. This is
  particularly tricky since the user is not necessarily aware of
  the various image references.

  Perhaps the correct solution is to simply add a global
  readers/writers lock to the Image class which protects against
  any simultaneous update, and protects against reading the object
  while it is being modified.

* Integrate with GdkMagick.

* Port to Sun Workshop 5.0 under Solaris (no access to compiler yet
  but hope so soon ...)

* Support building working dynamic library under Unix.

* Support building working DLL under Win32.

* Documentation based on Framemaker sources which produce Postscript,
  PDF, and HTML outputs.  Status: documentation for Magick++ is
  included in the ImageMagick documentation which is distributed
  as a PDF file.  HTML generation not yet ready for use.

Items which will require the aid of volunteers.  Volunteers?
--------------------------------------------------------------------

* Port to CodeWarrior Professional 5.0 (released in June) under NT

* Port to Borland C++ Builder 4.0 (http://www.borland.com/)

* Port to EDG C++ (multi-platform) compiler (http://www.edg.com/)

* Port to HP-UX C++ compiler

* Port to AIX C Set++ compiler

* Port to DEC C++ compiler

* Port to Cray C++ compiler

* Port to MacOS (with CodeWarrior)

* Port to VMS

* Provide integration with Blitz++ (http://monet.uwaterloo.ca/blitz/).
  Not sure what it would do other than aid with transformations on pixels.
