- add params

  use property system

  use construtors, see docs for g_object_new(), rather than vips8 build funcs

  nickname, description etc need to be properties so nip2 can read them

  add a g_get_children( "classname" ) -> ["child1-name", ..] to nip2, see old 
  vips8.c cooe?



- started adding 

#define IM_TYPE_GOBJECT "gobject"       /* A GObject of a specified class */

- make a "deprecated" package too

- im_affinei and im_affinei_all need docs

- all the interpolators

  want bicubic args to be

  	IM_GOBJECT( "VipsInterpolate", "interpolate" );

  ie. pass a gobject which is a sub-type of VipsInterpolate in an arg called
  "interpolate"

  then we need to create an object of that class, get the param list, set from
  any args, call object_init, and pass

  on return, unref the object

  so 
  
  	im_affinei_all in.v out.v "yafrsmooth(2.4)" 0.9 0 0 0.9 0 0

  creates a yafrsmooth, sets the param,


  in nip2, 

  	inter = g_object_new "VipsInterpolateBicubic" [$sharpness => 2.4];

  also need something to return a list of GTypes below a name etc., find class
  description:w


  need k



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

- how to expose things like yafrsmooth's "sharpening" parameter to
  nip2/C++/Python?
  can we write a find-by-nickname function? eg.

  	GType vips_get_type (const char *base, const char *nickname)

  then 

  	vips_get_type ("VipsInterpolator", "bicubic")

  would get us the GType for VipsInterpolatorBicubic

- redo the format system in this way too?

  need a way to init a package: the init would register all the types that
  package uses to they appear to introspection

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

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

  would need to be added to VipsObject I guess

- 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

- 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