libvips/TODO

- how curious

	$ vips jpegload wtc.jpg x.v --vips-progress
	** DEBUG_FATAL
	vips x.v: 2 threads, 128 x 128 tiles, groups of 256 scanlines
	vips /tmp/vips-1-2UERGW.v: 2 threads, 128 x 128 tiles, groups of 256 scanlines
	vips /tmp/vips-1-2UERGW.v: done in 2s          
	vips x.v: done in 3s          
	memory: high-water mark 77.46 MB


- test "rs" mode

  can't see the code for "rd" mode?

  or "rw" mode either?


- update "how it works" to note we are now fully-functional ... there's
  vips_image_write() now to create a sink

- im_jpeg2vips() etc, currently use vips_call() and therefore have an extra
  _write() ... this means that

  	vips im_jpeg2vips huge.jpg x.v

  decompresses to disc, then vips_copy()s to x.v

  instead, they could be built on top of VipsFormat and use the compat layer
  there

  check nip2: is it really only decompressing large images once?

blocking bugs
=============

- none!


mosaic
======

- balance should use new meta stuff

- histogram balance option?


resample
========

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

- perspective transform with a matrix ... base it on the Lenz transformer, but
  partial


foreign
=======

- magick2vips should spot ICC profiles and attach them as meta

- interlaced jpg needs massive memory, we should have two jpg read modes, like
  png

- add more sequential mode readers

	$ grep -l write_line *.c
	csv.c
	matlab.c
	openexr2vips.c
	ppm.c
	radiance.c

- foreign docs come up as "VipsForeignSave", annoying, why?

- add nifti support

	http://niftilib.sourceforge.net/

- support planar tiff

- add matlab write

- im_exr2vips can now use c++ api

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

  consider openexr write

- 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


packaging
=========

- test _O_TEMPORARY thing on Windows

- do we bundle "convert" in the OS X / win32 builds? if we don't we
  should


convolution
===========

- revisit orc conv

  use an 8.8 accumulator ... build the scale into the 8.8 coeffs ... no div at
  the end, just a shift

  need 8 x 8.8 -> 8.8 for each coeff though

- im_conv()/im_morph() could have more than 10 programs? try 20 and see if we
  still have a speedup

  make a base class for vector area operations with a matrix with three vfuncs
  for init / generate code for one element / end and a gslist of programs, use
  that as the base for morph and conv

  wait for vipsobject for this


colour
======

- lab [100,0,0] -> srgb [255, 255, 254]? how odd

- use D65 in cmsCreateLab4Profile() ? not sure


arithmetic
==========

- avg/dev etc. should uncode images? eg. labq2lab etc.

  how about ifthenelse? 

- bandalike: consider RGB + RGBA ... we should bandup by adding a black band

  (or white?? unclear)

  not clear if this is a good idea ... eg. when we upband a 1 band to a 2
  band, should we duplicate the 1 band or add black?

- HAVE_HYPOT could define a hypot() macro?

- fix a better NaN policy

  should we not generate images containing NaN (eg. divide tries to avoid /0),
  or should vips_max() etc. try to avoid NaN in images (eg. vips_max() takes a
  lot a care to skip NaN, though vips_stats() does not)?


iofuncs
=======

- we have VipsArrayObject and also vips_object_local_array()

  can we make one use the other?

- need vips_image_invalidate_area()

- look at libpeas for plugin support

	http://live.gnome.org/Libpeas

- how about

	vips max add[babe.jpg,babe2.jpg]

  does that make any sense?

	vips copy add[babe.jpg,add[babe2.jpg,babe3.jpg]] sum.v

  perhaps use curly brackets for code?

	vips max add{babe.jpg,babe2.jpg}

  no brackets or square brackets for options

- transform_g_string_array_image() can't handle quoted strings, so filenames
  with spaces will break

  is there an easy fix? can we reuse code from the csv parser?

  the csv parser just parses FILE* streams, we'd need to break it out

- note member free stuff in vipsobject docs

  should boxed get freed in finalise rather than dispose?

  vipsobject has few docs atm :(

- vips_object_set_argument_from_string() needs more arg types

  must be some way to make this more automatic

- generate the code for vips_add() etc. automatically? it might be 
  nice to have them all in one place at least

- what does G_UNLIKELY() do? can we use it?

- look into G_GNUC_DEPRECATED for back compat in vips8

- should im_rwcheck() copy to disc?

  maybe im_rwcheck_disc() copies to im->filename and maps that

  rather awkward to do atm with the way check.c is structured


swig
====

- swig is not wrapping im_project() correctly ... returns an extra VImage via
  a param

- doc strings would be nice, read the SWIG notes on this


new bindings
============

- new binding is still missing constants 

  how do boxed types work? confusing

  we need to be able to make a VipsArrayDouble

- Vips.Image has members like chain, __subclasshook__ etc etc, are we
  really subclassing it correctly?

- add __add__ etc overloads


freq_filt
=========

- fft with odd width or height is broken ... DC ends up in the wrong place


libvipsCC
=========

- need new C++ API

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


tools
=====

- could spot "copy" and turn on seq mode automatically?

  perhaps there should be something on operations to indicate seq-ability

- need a way to make the vips.1 etc. man pages

  gtk has things like docs/reference/gtk/gtk-update-icon-cache.xml and man
  pages are made from that with xslt

- get rid of a lot of the command-line programs, who wants to write a man page
  for batch_image_convert etc yuk

- can we make man pages for the API as well? probably not from googling a bit

- rename header, edvips as vipsheader, vipsedit

  maybe have back compat links?


new operations
==============

- bilateral filtering, see:

	http://en.wikipedia.org/wiki/Bilateral_filter
	http://www.shellandslate.com/fastmedian.html
	http://people.csail.mit.edu/sparis/bf_course/

  also a mail from Martin Breidt has links to several fast free C
  implementations

- http://en.wikipedia.org/wiki/Otsu%27s_method

- non-linear sharpen: replace each pixel by the lightest or darkest neighbour
  depending on which is closer in value