libvips/TODO

- new_heart.ws fails with libvips master

	has the sharing fix resolved this?

- nip2 hist match is failing with 7.36, was working in 7.34





- do restrict on some more packages, we've just done arithmetic so far

	also resample, colour, some of conversion, create, 

- orc is poor for float stuff ... if vips_linear() had a "preserve type"
  option we could do something

  maybe a "uchar ouput" option? this seems to be a very common case

- maybe avg?

  but avg doesn't subclass arithmetic, so we can't

- for interpolate, we'd need to be able to unroll the vector, so the
  interpolator would need to be built for the bands / stride / type of the
  image

  need new API For this, since interpolators currently work for any image

  




- do morph quickly as simple wrappers over the vips7 operations

- do restrict on some more packages, we've just done arithmetic so far

  how about avg? do we need -ffast-math to vec that?
  	
	yes we do, though it doesn't seem any faster

  how about avg? do we need -ffast-math to vec that?
  	
	yes we do, though it doesn't seem any faster

	perhaps because it only vecs the innermost loop across bands and it's
	too short to trigger the vec code

	try swapping the loops over ... inner loop across width, outer across 
	bands

	but then we'd have an unknown stride

	need to special-case 1 band and 3 band images

	or use orc to gen code at operator build 

	does this mean we should revert the removal of orc from arithmetic?

  not seen more than x2 from auto-vec of abs(), perhaps the bool ops?





- seen some leaks from 

	vips dzsave --layout google wtc.jpg x

  investigate

- vips_gaussblur() should switch to float prec if given a float image?

  same for vips_conv()?

  maybe precision is a dumb thing

- support --strip for other writers

- vipsthumbnail could shrink-on-load openslide and pyr tiff as well?

- how about

	top -d 0.01 | grep vips > log

  to watch RES at 0.01s intervals?

  note on memuse page

- use the webp advanced encoding api to set a write function for webp save to
  file

- use g_log() instead of vips_info()

- object construction is threadsafe, but class construction is not

  https://github.com/jcupitt/libvips/issues/64

  we worked around this by adding vips_class_ping_all() to dsave build, but
  this is not a good fix

  find out why vips class construct fails, test on seurat, kirk's 24-core
  monster





- quadratic doesn't work for order 3

  start to get jaggies on lines --- the 3rd differential isn't being 
  initialised correctly for the sub-region?

  seems fine vertically, only get errors on horizontal tile boundaries

  because we step across tiles left to right: y doesn't change, only x does



- the operation cache needs to detect invalidate

  tricky!

  perhaps have operations always watching all of their inputs and resignalling
  "invalidate" themselves

  cache then just needs to watch for "invalidate" on operations it tracks

  need to add an "invalidate" signal to operation

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/

- 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

- we have aconv and aconvsep

  test timing, make sure it;s worth having a separate aconvsep version

  if it is, make im_aconvsep an optimisation: call im_aconvsep_raw() from
  vips_conv() if mask width or height == 1 and prec == APPROX

  now we can get rid of im_aconvsep() since it's just vips_convsep() with prec
  set to approx

  aconv needs some more work, get it going at least with gaussian


arithmetic
==========

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

  how about ifthenelse? 

- 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
=======

- 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
=====

- 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

- look at
	
	There is an order 1 algorithm for doing medians over boxes (truly O(1)
	per pixel: I checked it carefully; it's like doing means over boxes in
	order 1 per pixel) in OpenCV since February 2012 I think, due to
	Perreault (and Hebert).

	It appears to be well respected, at least for 8-bit medians. Very
	memory intensive. Simple and elegant. No clue if it fits VIPS well
	(probably not?).

	Article: nomis80.org/ctmf.pdf

- check CMC equations against web

	http://en.wikipedia.org/wiki/Color_difference#CMC_l:c_.281984.29

- see

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

  sounds useful for BM?