libvips/TODO

- talk about new progress system in im_add_eval_callback()?

- done jpeg, png ... make others dbl-buf writes too

- missing libstdc++ in link? what if we configure with no openexr?

  added -lstdc++ to VIPS_LIBS, but will this work on solaris etc.? maybe have
  a configure option to turn off CImg

- test maxpos_avg, quite a few changes

- im_exr2vips can now use c++ api

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

- 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