Python binding
==============

- python startup fails with plugins in vipslib:

	Fatal Python error: can't initialise module vips
	plugin: unable to open plugin "/home/john/vips/lib/resample.plg"
	plugin: /home/john/vips/lib/resample.plg: undefined symbol: im_start_one

  do we need to build plugins with -rpath etc. and more libs?

  or do we need to make sure our python modules export all their im_ symbols?

WONTFIX
=======

- can we use GraphicsMagick instead of ImageMagick?

  no: current stable GraphicsMagick is missing (at least) QuantumRange and
  GetNextImageAttribute() ... perhaps this will be fixed in 1.2

- TIFF load/save should use meta system for unknown tags

- balance should use new meta stuff

- magick2vips should spot ICC profiles and attach them as meta

- magick should set some header field for n_frames and frame_height? see also
  analyze

- see TODO notes in openexr read (though they all need more openexr C API)

  consider openexr write

- add GREYCstoration filter

    http://www.haypocalc.com/wiki/Gimp_Plugin_GREYCstoration

  actually, it has to be a plugin, since their code is GPL

  and very memory-hungry for large images :-( needs 20x size of image to be
  processed

  could we rewrite with VIPS? how much more stuff would we need to add?

  try again using the current version of the filter from the suthors rather
  than the gimp plugin

- im_csv2vips() could use "-" for filename to mean stdin

  but then we'd have to read to a malloced buffer of some sort rather than an
  image, since we might need to grow it during the read, since we couldn't
  then seek

- add erode/dilate 3x3 special case using a 512-bit LUT

  ... nope, actually slower :-( we end up doing an inner loop like

  	for( i = 0; i < 9; i++ )
		bits |= (p[o[i]] != 0) << i;

  which is horrible. Maybe if we had a one band true 1 bit image it'd be
  quicker since we could get bits out in parallel and wouldn't have to worry
  about converting non-zero to 1

  could have a Coding type for bitpack? eg. relational produces a bitpack
  image by default, boolean & morph can work on bitpack etc

  maybe something for vips8 ... we could have a flag on operations for the
  coding types they can accept, and if they are passed other type, they are
  automatically converted

- non-linear sharpen: replace each pixel by the lightest or darkest neighbour
  depending on which is closer in value

- can wrap other inplace funcs which use ink now we have vector_to_ink() in
  inplace_dispatch.c

  see also comments in nip2 TODO ... we could auto-wrap in vips_call.c

  cleaner!

- on win32, should not write matrix files in binary mode, we want CR/LF chars
  so we can load into excel etc easily

  how odd, we're doing

	if( !(fp = fopen( name, "w" )) ) {

  shouldn't be binary ... hmm

Build
=====

- xmlFree() is still broken :-(

  maybe we are not importing it correctly? im_readhist.c references

	_imp__xmlFree

  how is this made? look at gcc -E output ... maybe there's an extra define we
  need to make it generate the right link code?

  see what libxml2.dll.a is exporting that looks anything like xmlFree
 
- can we make a fftw3.dll? also, magick.dll?

  maybe just build with no-undefined? can we then link the DLL against the
  static lib?

- update gtk/glib/etc. on the PC to the latest versions, apparently much
  quicker (esp. pango)




This TODO list is now held on the VIPS Wiki

   http://wiki.vips.ecs.soton.ac.uk/bin/view/Vips/TodoVips7