libvips/TODO

- 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

  there must be an autoconf macro that finds the stdc++ library name

  maybe just link with g++ instead of gcc? how can we do this? put a
  dummy.cpp into libsrc?

  or do we only need to link the cimg convenience library with g++? libtool
  should copy the libs up, shouldn't it?

WONTFIX
=======

- unsharp should work on GREY16? shuld be easy to add GREY16->LABS

  no, labs is signed short, ranges are all differrent, and the scaling will be
  wrong anyway

  correct: import with ICC to labs, then process, then export to RGB, take
  green?

  yuk, can we add a 16bit path to vips's lab <--> rgb converter?

- test maxpos_avg, quite a few changes

- write our own python extension to call a vips operation by name

	result = vips_call ("name", args)

  then call that from VImage_method

- do we really need VImage_method? Can't we write

	__getattr__ (self, name) = lambda (obj_to_call, arguments):

  or something like that?

- HAVE_HYPOT could define a hypot() macro?

- im_exr2vips can now use c++ api

- 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?

  check:

  	http://www.swig.org/Doc1.3/SWIGDocumentation.html#Python_nn8
	http://docs.python.org/dist/dist.html

- write our own python extension to call a vips operation by name

	result = vips_call ("name", args)

  then call that from VImage_method

- do we really need VImage_method? Can't we write

	__getattr__ (self, name) = lambda (obj_to_call, arguments):

  or something like that?

- 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