libvips/TODO

- add something to dzsave to control pyramid depth ... can then use it for
  straight tiling

- add mono as a colourspace? also rad?

  move colour_convert into a separate file

- im_icc_ac2rc needs doing once we have a general 'convert' operator

- test new icc stuff with lcms1 and lcms2

- should we have a better thing to stop convert_saveable running for vips
  images?

- why do we need the extra vips_image_write() at the end of
  vips_colour_convert_build()? why can't we just g_object_set() x?



- boolean.c has

	vips_check_noncomplex( "VipsBoolean", binary->left ) )

  why not

	vips_check_noncomplex( VIPS_OBJECT_GET_CLASS( object )->nickname,
		binary->left )

  many other places too

- can we make DOUBLE ARRAY args easier from C?

  at the moment they are horrible or ad-hoc, see vips_linear() etc. and
  the im_Lab2XYZ_temp() wrapper

  can the thing that collects args from the stack spot array objects? eg. 

	double fred[3];

	vips_Lab2XYZ( in, out, "temp", fred, 3, NULL );


colour

colour operations:

	process just first three bands
	one in, one out
	float only
	uncoded only

		LabS2Lab, LCh2UCS etc. etc.

	uncoded
	one in, one out

		icc ops
		disp2XYZ
		XYZ2disp

	uncoded
	two in, one out
	float output
	possibly auto-convert inputs to LAB

		dE, dE00, dECMC

	one in, one out

		rad2float, LabQ2Lab, LabQ2disp






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

- use D65 in cmsCreateLab4Profile() ? not sure

how about a base colour class with 1 in, 1 out, 

    PCS operations all operate on three float bands

    first three bands passed through the operation, other bands bypass


    import ops go from device space to PCS


    export ops go from PCS to n-band device space

    how do we handle alpha in import/export ops? op must declare the number of 
    bands required (eg. 4 for cmyk import, or 1 for greyscale), other bands
    appended

- can we do CMC(2:1) by warping UCS space?

  remove dECMC_fromLab etc. just have a pythag operation in arith? needs to
  pass extra bands through though


- CMC(l:c) needs optional args for l and c





- add a simple wrapping of im_affinei_all() to the po db, perhaps the name of
  the interpolator as a string?

- dzsave should maybe write some xml as well, see the Python dz writer?

- the operation cache needs to detect invalidate

- see

        http://www.dentistry.bham.ac.uk/landinig/software/cdeconv/cdeconv.html

  sounds useful for BM?



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



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