revise TODO

TODO

@@ -1,8 +1,33 @@
+Blocking
+========
+
+- is vips_hist_local() correct? it seems to leave white dots everywhere
+  on the sarto_ng test image
+
+  try a 1x1 window, it be identity operation, I think
+
+- could VipsConversion now have an @in member?
+
+  we've moved all the no-input ones of to create now, I think
+
+  we several many-input ones though, eg. bandary
+
 - why is memuse so high?
 
 	$ vips shrink wtc.png x.v 230 230
 	memory: high-water mark 322.13 MB
 
+  because we have so many threads on the work machine, try:
+
+  	$ vips shrink wtc.png x.v 230 230 --vips-concurrency=1
+	memory: high-water mark 45.46 MB
+
+- check speed and memuse test, are we really 10mb? have a note that memuse can
+  be much higher
+
+Next version
+============
+
 - do conv and morph quickly as simple wrappers over the vips7 operations
 
 - do much fancier profiling with timing on all locks saved in memory and
@@ -11,8 +36,6 @@
 - use the webp advanced encoding api to set a write function for webp save to
   file
 
-- is vips_hist_local() correct? it seems to leave white dots everywhere
-
 - use g_log() instead of vips_info()
 
 - do we always call copy_fields and demand_hint with ALL input images? what
@@ -25,10 +48,6 @@
 
 	https://github.com/jcupitt/ruby-vips/issues/41
 
-- could VipsConversion now have an @in member?
-
-  we've moved all the no-input ones of to create now, I think
-
 - object construction is threadsafe, but class construction is not
 
   https://github.com/jcupitt/libvips/issues/64
@@ -43,19 +62,6 @@
 
 
 
-- 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
-
 - quadratic doesn't work for order 3
 
   start to get jaggies on lines --- the 3rd differential isn't being 
@@ -65,9 +71,6 @@
 
   because we step across tiles left to right: y doesn't change, only x does
 
-- test with interpolators, do we add margins correctly?
-
-
 
 
 - the operation cache needs to detect invalidate
@@ -81,24 +84,6 @@
 
   need to add an "invalidate" signal to operation
 
-- 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?
-
-
-
-blocking bugs
-=============
-
-- none!
-
-
 mosaic
 ======
 
@@ -141,8 +126,6 @@ foreign
 
 	http://niftilib.sourceforge.net/
 
-- support planar tiff
-
 - add matlab write
 
 - im_exr2vips can now use c++ api
@@ -190,7 +173,6 @@ convolution
   wait for vipsobject for this
 
 
-
 arithmetic
 ==========
 
@@ -198,13 +180,6 @@ arithmetic
 
   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
@@ -217,10 +192,6 @@ arithmetic
 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
@@ -314,10 +285,6 @@ libvipsCC
 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
@@ -350,3 +317,26 @@ new operations
 - 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?
+