
- 0,0,0 RGB -> [0.950406, 0.9999086, 1.089062] in XYZ

  !?!?!?! how odd

- add horizontal and vertical projections

- look into "check":

	http://check.sourceforge.net/doc/x68.html

- load babe.jpg, resize to quicklook, black border along top and down left!

- load k2.jpg, resize to, im_affine size misses by one pixel

- rump.jpg, size to, nearest neighbour, rightmost column of pixels is black

- what about all the other _vec() funcs? eg. powtra_vec()? will they do
  (op 1-band-image 3-band-vector)

- break global balance into two stages

  add offset as well as scale

  guess gamma?

  add median

  remosaic with size change ... eg mosaic low res, then join hi-res

- remosaic fails for JPEGs, since it sees the temp file name, not the real
  file name

  also mosaic balance, I guess?

  can we zap image->filename with the true filename? does im_open() already do
  this for RAM files?

- im_insert should follow xoffset /yoffset, since it's used as a fallback by
  merge and they look at the offset

  hhm, nope, they don't something else is going on

  look up Joe's example ... ~/frame/*

- could render have a timeout? eg. ask for a tile, wait 10ms, if there's no
  data yet, return the checkerboard

  might make thumbnails less flickery?

- check Joe's balancing problems?

WONTFIX
=======

- try the swap trick:

	swap_max ( a, b ) if( (z = b - a) < 0 ) { a += z; b -= z }

  swaps a and b if necessary to make a > b

  in rank? elsewhere?

  faster without optimiser, slower by 2% with -O2 turned on, gah!!

- could we replace the tile cache in im_tiff2vips() with an im_render()? I
  think im_render() becomes a tilecache if there's no callback, non?

  ... not worth it

- patch in win32 video grab

  ... gah, it's 2000 lines of C++!

- should not expose glib2 dependency in vips includes

  currently threadgroup.h etc. require you to have included glib2 stuff, so
  vips-config --cflags has glib2 stuff in

  this breaks ip-7.8 and nip-7.8, since they depend on gtk+-1.2

  so threadgroup and vsem need public and private interfaces :-( public
  interface should be opaque

  too painful to hide, and will be exposed anyway soon when we move to gobject

  give up and accept that nip1 will not build with 7.10

- change Rect to VRect ... too much breakage?

  ... save this for vips8

- im_prepare() should clip r argument against image size

  see vips2jpeg etc., also im_prepare_thread()

  or maybe not: we often do stuff like

  	im_prepare( input_region, &output_region->valid )

  changing valid would be baaad

  need safer idiom for im_prepare_thread() style looping?

  ... save this for vips8

- need to change im_prepare() meaning

	im_prepare( region, area )

  after calling, can read pixels inside area from region (area will not be
  touched ... not even clipped against image size)

  no guarantees about valid, except ir will be >= area

  generate function passed an output region plus a rect (*not* valid):
  generate function is asked to supply im_prepare()'s guarantee ... that
  someone will be able to read area pixels from oregion (area <= valid)

  same for iterate scan functions ... passed a region to read from, and an
  area to read separately

  change im_prepare() so that if the requested region is inside valid, it does
  nothing ... regions can start to act like little caches

  valid always means "this many pixels are fine and up to date"

  for region_other_region etc. need an extra layer with refcounting? something
  to make sure we don't get dangling pointers when we move regions

- VMask( x, y, s, o, ...) constructor must go

  add a separate varargs convenience function

TODO vips
=========

- lr/tb merge should test for all bands == 0 for transparency? when we build
  firstlast as well as blend?

- im_magick2vips seems to memleak according to memprof ... bug in libMagick, 
  or are we just not calling it right? can't tell

- can we make a cie2000 colourspace? not sure we can

  try to find a pair of hue angles which break joe's code?

- make a mosaic, use im_remosaic to rebuild, global_balance no longer works
  (more than 1 root msg)

- add func descriptors for im_isjpeg etc.?

iofuncs
-------

- vips.m4 could test for --prefix arg does not match location of vips-config
  executable

- could add a flag for "works on LABPACK" ... if we try to call a function
  with a LABPACK when it doesn't handle them, silently unpack to float

- replace callbacks with signals

- add a [image] type ... cf. realvec ... useful for gbandjoin and im_compass()
  built out of lots of im_conv()

- function dispatch should trace VIPS calls (with im_diagnostics())
  need some mechanism so diagnostics can write to a buffer which apps can
  display ... or at least set a handler for

- im_add_diagnostic_callback()?

- fix function dispatch stuff to include <-> char functions for each type ...
  see notes in nip/TODO

- new C API based on ip's vips.c interface? add optional args, OO stuff

- break vips into separate libs ... iofuncs becomes libvips, arithmetic becomes
  vips/arithmetic.plg, etc. 

- use g_object OO mechanism ...
  operations become classes, inheritance for more code sharing

- new C API based on ip's vips.c interface? add optional args, OO stuff,
  overloading

  eg
	
	if( im_add( a, b, result ) )
	  ...

  becomes

	result = vips( &err, "add", "in1", a, "in2", b, NULL );
	if( err ..

  rename all im_ to vips_

- maybe add arg flags for required/optional ... so in1/in2/result for vips_add
  are required and would not need flaging with names

	result = vips( &err, "add", a, b, "option1", option, NULL );
	if( err ..

operations
----------

- move more video stuff into vips from ip1, follow im_video_linux() template

- lhisteq menu item could loop over bands, rather than just working on the
  1st band

- im_invertlut() could be improved quite a bit

- put the acohir calibrator into VIPS

- colour stuff needs reworking to do differing colour temperatures cleanly, 
  some docs would be nice

- write im_resize() ... arbitrary scale/shrink, bi-cubic

- add im_connect()? writes a 1 band image with 255 pixels connected to the
  start point ... can then do im_flood() by plotmask, or im_ifthenelse()

  would avoid big undo thing in paintbox

  could have partial output, with some sort of sparse image thing for the
  mask?

  im_connect_equal(), im_connect_notequal()

- for a segmenter, would probably want a RW_ image, with pixels being set to a
  specified value, and only zero pixels being overwritten?

C++ API
-------

- C++ API is missing vector types ... doublevec and imagevec

- could add LUT stuff from nip 

configure
---------

- add BUILDING_DLL stuff to vips.h

  update main VIPS README for new configure options

- should rebuild C++ API using vips.exe in libsrcCC/Makefile.am ... somehow

- should define -DNDEBUG for production build
