libvips/TODO

- JPEG write should know about CMYK as well, maybe write all 4 band images as
  CMYK?

- JPEG read could have a "subsample" param and use 

unsigned int scale_num, scale_denom 
	Scale the image by the fraction scale_num/scale_denom.
	Default is 1/1, or no scaling.	Currently, the only supported
	scaling ratios are 1/1, 1/2, 1/4, and 1/8.  (The library design
	allows for arbitrary scaling ratios but this is not likely to
	be implemented any time soon.)	Smaller scaling ratios permit
	significantly faster decoding since fewer pixels need be processed
	and a simpler IDCT method can be used.


- HAVE_HYPOT could define a hypot() macro?

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

- try

	im_max ~/pics/wtc.jpg
	read: done in 8s          
	iterate: done in 11s          
	255

	nip2 --vips-progress -e 'max (Image_file "~/pics/wtc.jpg")'
	/home/john/.nip2-7.13.2/tmp/untitled-nip2-0-XOSIR1T.v: done in 18s
	iterate: done in 20s          

	nip2 --vips-progress ~/pics/wtc.jpg
	/home/john/.nip2-7.13.2/tmp/untitled-nip2-0-X37AX1T.v: done in 23s
	... then "max A1" at the cmd line
	iterate: done in 32s          

  is there a problem

- test ppm writer

- 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

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

  check:

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

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