- make a new package for "resample"? im_shrink & friends could go in there too

- try walking the class hierarchy below VipsInterpolate and see if we can see
  all the interpolators

  classes need some extra fields

  	nickname, eg. "bicubic"
	caption, eg. "catmull-rom bicubic interpolation"

- how to expose things like yafrsmooth's "sharpening" parameter to
  nip2/C++/Python?

  look at vips8, can we use the parametter code there?

  would need to be added to VipsObject I guess

- repeat the benchmarks with the final code, how close are we? do we need to
  repeat all of them because of the errors in the code we were testing?

  user time, laptop, 8-bit data

	bilinear					15.1 (was 16)
	bicubic, fixed-point, tables			26.5 (was 29.5)
	bicubic, floating-point, tables			35.8 (no change)
	bicubic, floating-point, no tables		38.3 (was 44.2)
	yafrsmooth, fixed-point, tables			114
	yafrsmooth, from gegl				149

- we need an introspection thing to list interpolation classes

  how do we list the subclasses of VipsInterpolate? it'll need some extra
  stuff to present interpolations to the user (caption?)

  we should add params as gobject properties







- benchmarking notes:

	time vips im_affinei wtc.v wtc2.v 2 0.97 0 0 0.97 0 0 0 0 10000 10000

  user time, opteron, 8-bit data

  	old-vips					3.0
	bilinear					3.0
	bicubic, fixed-point, separate tables		8.3
	bicubic, fixed-point, tables			10.9
	bicubic, floating-point, separate tables	12.8
	bicubic, floating-point, tables			14.2
	bicubic, floating-point, no tables, separate	15.0
	bicubic, floating-point, no tables		17.6
	yafr-smooth					36.3

  user time, opteron, float data (real time is huge, thanks to very large file
  read/write)

	bicubic, fp, tables 				8.2
	bicubic, fp, tables, separate 			9.7
	bicubic, fp, no tables, separate		10.0
	bicubic, fp, no tables				13.2

  user time, opteron, 8 bit -> float, -> 8-bit

	bicubic, fp, no tables				16

  user time, laptop, 8-bit data

  	old-vips					14.7
	bilinear					16.0
	bicubic, fixed-point, tables			29.5
	bicubic, floating-point, tables			35.8
	bicubic, floating-point, no tables		44.2

  user time, laptop, float data

	bicubic, fp, tables 				32.2
	bicubic, fp, no tables 				51.5

  user time, laptop, 8 bit -> float, -> 8-bit

	bicubic, fp, no tables 				69

- still to check:
  
	range clipping

	think again about centred vs non-centred pixels

	coordinate clipping

	image margins

	don't use tables for large expansions? we'll get banding

	put bicubic's improvements into yafrsmooth / yafrnohalo

- think about position of . in int path 

	16 bit needs 16 for mantissa, plus 4 for adding the 16 components
	together, plus a bit of overflow for safety, plus a sign bit 
	... so 8 bits for the fractional part sounds about right

	for 8 bit data, we need 8 + 4 + 1 + 1, say 16 bits for the fractional
	part

	but better to keep it all with the same point position, or we need to
	have two copies of the tables

- vips_object_print, set_name etc. need writing

- im_buf_t -> VipsBuf

  now always included in vips.h

- build nip2

- check mosaic1, global_balance, similarity etc. use of im__affine
  
  how can we move them to im_affinei ?

- rename Transformation -> Transform

- update the Portfiles on the mac and on the website from the macports ones

- im_render should use a hash for tile lookup ... or+shift x/y together

- eval callbacks shouldn't set an errormsg? or maybe it should for debugging
  and stuff

- bilinear should be a true subclass of interpolate ... and put the tables
  into the base class

- add 'name' to vipsobbject, and vips_object_print() ... handy for debugging

  make 'print' into a virtual method so subclasses can add stuff if they want

WONTFIX for 7.16
================

- we shouldn't need to call im_invalidate() in gtkdisp4 :( how can we fix
  this?

  will im_invalidate() trash the render cache too?

- we should wrap the format API, also im_render*(), see gtkdisp.cc for sample
  code

- have a base VObject class and put the ref stuff in there ... share between
  VMask, VDisplay, VImage

- need an im_init_world() for C++ which does cmd-line args too, so C++ progs
  can get --vips-progress and stuff automatically

- examine yafr and add as another interpolation option for im_affine

- how much slower wouuld we get if we did a function call + switch for 
  interpolate in im_affine()? it would let us break out the interpolation 
  stuff from the transformer

- we need another version of im_affine() with an 'interpolate' option :-(

  or maybe have im_interpolate_t as another object which we pass to
  im_affine()

- more cleanups to the handling of vips format images, esp. we have vips write
  spread across many files atm

- could remove a lot of crappy old API

- it'd be nice to handle vips format images in the same im_format system, but
  it's not clear if this is possible

- add new type names, eg. im_region_t, im_image_t etc. and deprecate old
  names?

- try

	libsrc/convolution$ grep -l offsets *.c

  could we do the don't calc offsets thing unless bpl; changes thing in more
  places?

- unsharp should work on GREY16? should 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?

  use TIFF RGB16 as the 16bit RGB target

  im_XYZ2disp() would be easy to 16bit ... just need the 1,500 element table
  table->t_Yr2r[i] expanded
  
  im_disp2XYZ() uses im_col_rgb2XYZ() in a loop ... again, need
  the 1,500 element table table->t_r2Yr[i] expanded

  usually these three tables (t_r2Yr, t_g2Yg, t_b2Yb) will be identical, can
  we common them up? same for t_Yr2r etc.

  how big should the table be for 16 bits? 256 times larger? too big!

  we really just need a LUT for pow() with the right exponent, eg. 2.4 for
  sRGBs, and one for 1/2.4 ... see what calcul_tables does:

  	table->t_r2Yr[i] = yo + a * pow( i * table->ristep / f + c, ga );

  see



  

- test maxpos_avg, quite a few changes

- HAVE_HYPOT could define a hypot() macro?

- im_exr2vips can now use c++ api

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

  consider openexr write

- 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

- also png2vips?

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

- 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