libvips/TODO

- nip2-7.22.3 on Windows is not adding the path you load from to the set opf
  paths to search, breaking demo2 for Hamish

- custom morph, erode, apply 3 times, lock up!

  4way3.mor

	7 7 1 0
	128 128 128 255 128 128 128 
	128 128 255 255 255 128 128 
	128 255 255 255 255 255 128 
	255 255 255 255 255 255 255 
	128 255 255 255 255 255 128 
	128 128 255 255 255 128 128 
	128 128 128 255 128 128 128 

  	$ vips im_erode wtc1bit.v t2.v 4way3.mor

  lock up

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

- could do small masks in a single pass

- try using a smaller norm factor in nip2 for sep conv gen there?

- Lan's c4_stats.ws is broken, I guess due to vector stuff

- how much time are we spending setting sources by name, profile!

- maybe im_draw_smudge() is too slow :-( also, we had a sanity failure with
  it, argh

  make a region, prepare to that, copy back over the image?




- how do we wrap inplace ops in C++ now? will checking the RW bit help at all?

- consider:

	if( im_check_vector( "im__vector_to_ink", n, im ) )
		return( -1 );

  n must be 1 or im->Bands ... but what about n > 1 and im->Bands == 1?

  look at im_lintra_vec(), what happens here?




- use D65 in cmsCreateLab4Profile() ? not sure

- VImage("poop.v") should use "rd" as well? Python too?

- im_divide() can /0 for complex 

- unlink temps earlier on *nix systems

  the file is created by setupout, which is called just before generate or
  writeline, so perhaps unlink on evalstart?

  no, on a rewind we need to be able to close and reopen, argh

- why is im_setupout() necessary for WIO output? couldn't writeline call it if
  it's not been called?

  equally, could pincheck/poutcheck/outcheck be made optional?
  im_region_create() could call pincheck for you, for example

  open_lazy does a pincheck to rewind the disc conversion, but that could be
  removed

  incheck is necessary to make ->data valid I suppose




- tools subdirs are now pretty stupid :-( just have a single dir

- test

		python setup.py build_ext
		python setup.py build
		python setup.py install


>>> from vipsCC import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/dist-packages/vipsCC/VImage.py", line 25, in
<module>
    vimagemodule = swig_import_helper()
  File "/usr/local/lib/python2.6/dist-packages/vipsCC/VImage.py", line 21, in
swig_import_helper
    _mod = imp.load_module('vimagemodule', fp, pathname, description)
ImportError: /usr/local/lib/python2.6/dist-packages/vipsCC/vimagemodule.so:
undefined symbol: _ZTIN4vips5VMaskE

ie. vimagemodule.so can't find libvipsCC.so I guess? or perhaps the compiler
is being given a differnt mangling flag

we're building with:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DDEBUG_FATAL=1 -DDEBUG_LEAK=1
-I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/libxml2
-I/usr/include/libpng12 -I/usr/include/libexif -I/usr/include/glib-2.0
-I/usr/include/freetype2 -I/usr/include/OpenEXR -I/usr/include/ImageMagick
-I../../libvips/include -I../../libvipsCC/include -I/usr/include/python2.6 -c
vimagemodule.cpp -o build/temp.linux-x86_64-2.6/vimagemodule.o -pthread
-fopenmp -pthread -Wl,--export-dynamic -pthread -pthread -pthread

g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/vimagemodule.o -Wl,-R/home/john/vips/lib
-lMagickWand -lMagickCore -lpng12 -ltiff -lz -ljpeg -lgthread-2.0 -lrt
-lglib-2.0 -lgmodule-2.0 -lxml2 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0
-lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lrt -lglib-2.0 -lfftw3 -lm -llcms -lIlmImf -lz -lImath -lHalf
-lIex -lIlmThread -lmatio -lz -lexif -lm -lstdc++ -lm -o
build/lib.linux-x86_64-2.6/vipsCC/vimagemodule.so -pthread -fopenmp -pthread
-Wl,--export-dynamic -pthread -pthread -pthread

how does this compare to the working build? swig/vipsCC does

g++ -DHAVE_CONFIG_H -I. -I../.. -I../../libvips/include -I../../libvipsCC/include -DDEBUG_FATAL -DDEBUG_LEAK -pthread -fopenmp -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/libxml2 -I/usr/include/libpng12 -I/usr/include/libexif -I/usr/include/glib-2.0 -I/usr/include/freetype2 -I/usr/include/OpenEXR -I/usr/include/ImageMagick -I/usr/include/python2.6 -g -Wall -MT vimagemodule.lo -MD -MP -MF .deps/vimagemodule.Tpo -c vimagemodule.cxx -o vimagemodule.o >/dev/null 2>&1

g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbeginS.o  .libs/vimagemodule.o   -Wl,-rpath -Wl,/home/john/SVN/vips/vips7/trunk/libvipsCC/.libs -Wl,-rpath -Wl,/home/john/SVN/vips/vips7/trunk/libvips/.libs -Wl,-rpath -Wl,/home/john/vips/lib ../../libvipsCC/.libs/libvipsCC.so ../../libvips/.libs/libvips.so /usr/lib/libMagickWand.so /usr/lib/libMagickCore.so -lpng12 /usr/lib/libtiff.so /usr/lib/libjpeg.so /usr/lib/libxml2.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lfontconfig /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so /usr/lib/libfftw3.so /usr/lib/liblcms.so /usr/lib/libIlmImf.so -lImath -lHalf -lIex -lIlmThread /usr/lib/libmatio.so -lz /usr/lib/libexif.so -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../.. -L/usr/lib/x86_64-linux-gnu -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crtn.o  -pthread -Wl,--export-dynamic -pthread -pthread -pthread   -pthread -Wl,-soname -Wl,vimagemodule.so -o .libs/vimagemodule.so





- convert_saveable for other writers: tiff, ppm, csv, rad etc.

- the tiff writer could use more im_check_ things


- expose more of the tone funcs in nip2

- quite a few hist operations have no GUI ... lhisteq, for example? or
  histspec?

- added im_local_imask(), im_local_dmask(), needs docs?

  I guess when mask/* gets docs

- im_rotate_imask90 only works for square, odd-sized masks, argh

  just use im_rot90? have a small wrapper to let you use image functions on 
  masks

- lots of stupid little files in hist, eg. im_hsp.c ... paste them into larger 
  modules




- try writing docs for vipsthumbnail with gtkdoc? then try header etc.

  we need to have a separate docs package for the tools/ dir

- rename header, edvips as vipsheader, vipsedit

  maybe have back compat links?

- 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

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

- rename vipsCC in SWIG as pyvips?

- look into G_GNUC_DEPRECATED for back compat in vips8

- use

	http://library.gnome.org/devel/glib/stable/glib-Byte-Order-Macros.html

  for swapping ... they are asm macros so we should see a speedup

- can we use conv_sep to speed up the memuse benchmarks?

- move im_shrink & friends to resample?

  match_linear, match_linear_search?

  what about im_stretch3.c, im_resize_linear

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

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

- 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

- try making vips_add(), an operator as a class

- need a section for vipsobject in the tutorial

  also a manpage?

  not really stable yet :( don't document

- how to expose things like snohalo1's "blur" parameter to
  C++/Python?

  can we write a find-by-nickname function? eg.

  	GType vips_get_type (const char *base, const char *nickname)

  then 

  	vips_get_type ("VipsInterpolator", "bicubic")

  would get us the GType for VipsInterpolatorBicubic

- we shouldn't need to call im_invalidate() in gtkdisp4 :( how can we fix
  this?

- we should wrap the format API, also im_render*(), see gtkdisp.cc for sample
  code

- have a base VObject class and put the ref stuff in there ... share between
  VMask, VDisplay, VImage

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

- more cleanups to the handling of vips format images, esp. we have vips write
  spread across many files atm

- could remove a lot of crappy old API

- try

	libsrc/convolution$ grep -l offsets *.c

  could we do the don't calc offsets thing unless bpl; changes thing in more
  places?

- unsharp should work on GREY16? should be easy to add GREY16->LABS

  no, labs is signed short, ranges are all differrent, and the scaling will be
  wrong anyway

  correct: import with ICC to labs, then process, then export to RGB, take
  green?

  yuk, can we add a 16bit path to vips's lab <--> rgb converter?

  use TIFF RGB16 as the 16bit RGB target

  im_XYZ2disp() would be easy to 16bit ... just need the 1,500 element table
  table->t_Yr2r[i] expanded
  
  im_disp2XYZ() uses im_col_rgb2XYZ() in a loop ... again, need
  the 1,500 element table table->t_r2Yr[i] expanded

  usually these three tables (t_r2Yr, t_g2Yg, t_b2Yb) will be identical, can
  we common them up? same for t_Yr2r etc.

  how big should the table be for 16 bits? 256 times larger? too big!

  we really just need a LUT for pow() with the right exponent, eg. 2.4 for
  sRGBs, and one for 1/2.4 ... see what calcul_tables does:

  	table->t_r2Yr[i] = yo + a * pow( i * table->ristep / f + c, ga );

  see



  

- test maxpos_avg, quite a few changes

- HAVE_HYPOT could define a hypot() macro?

- im_exr2vips can now use c++ api

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

  consider openexr write

- python startup fails with plugins in vipslib:

	Fatal Python error: can't initialise module vips
	plugin: unable to open plugin "/home/john/vips/lib/resample.plg"
	plugin: /home/john/vips/lib/resample.plg: undefined symbol: im_start_one

  do we need to build plugins with -rpath etc. and more libs?

  or do we need to make sure our python modules export all their im_ symbols?

  check:

  	http://www.swig.org/Doc1.3/SWIGDocumentation.html#Python_nn8
	http://docs.python.org/dist/dist.html

- write our own python extension to call a vips operation by name

	result = vips_call ("name", args)

  then call that from VImage_method

- do we really need VImage_method? Can't we write

	__getattr__ (self, name) = lambda (obj_to_call, arguments):

  or something like that?

- TIFF load/save should use meta system for unknown tags

- balance should use new meta stuff

- magick2vips should spot ICC profiles and attach them as meta

- also png2vips?

- 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

- add erode/dilate 3x3 special case using a 512-bit LUT

  ... nope, actually slower :-( we end up doing an inner loop like

  	for( i = 0; i < 9; i++ )
		bits |= (p[o[i]] != 0) << i;

  which is horrible. Maybe if we had a one band true 1 bit image it'd be
  quicker since we could get bits out in parallel and wouldn't have to worry
  about converting non-zero to 1

  could have a Coding type for bitpack? eg. relational produces a bitpack
  image by default, boolean & morph can work on bitpack etc

  maybe something for vips8 ... we could have a flag on operations for the
  coding types they can accept, and if they are passed other type, they are
  automatically converted

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

- can wrap other inplace funcs which use ink now we have vector_to_ink() in
  inplace_dispatch.c

  see also comments in nip2 TODO ... we could auto-wrap in vips_call.c

  cleaner!