- HAVE_HYPOT could define a hypot() macro? - 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? - try im_max ~/pics/wtc.jpg read: done in 8s iterate: done in 11s 255 nip2 --vips-progress -e 'max (Image_file "~/pics/wtc.jpg")' /home/john/.nip2-7.13.2/tmp/untitled-nip2-0-XOSIR1T.v: done in 18s iterate: done in 20s nip2 --vips-progress ~/pics/wtc.jpg /home/john/.nip2-7.13.2/tmp/untitled-nip2-0-X37AX1T.v: done in 23s ... then "max A1" at the cmd line iterate: done in 32s is there a problem - test ppm writer - missing libstdc++ in link? what if we configure with no openexr? added -lstdc++ to VIPS_LIBS, but will this work on solaris etc.? maybe have a configure option to turn off CImg there must be an autoconf macro that finds the stdc++ library name - test maxpos_avg, quite a few changes - im_exr2vips can now use c++ api Python binding ============== - 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 WONTFIX ======= - can we use GraphicsMagick instead of ImageMagick? no: current stable GraphicsMagick is missing (at least) QuantumRange and GetNextImageAttribute() ... perhaps this will be fixed in 1.2 - 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 - magick should set some header field for n_frames and frame_height? see also analyze - see TODO notes in openexr read (though they all need more openexr C API) consider openexr write - 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! - on win32, should not write matrix files in binary mode, we want CR/LF chars so we can load into excel etc easily how odd, we're doing if( !(fp = fopen( name, "w" )) ) { shouldn't be binary ... hmm Build ===== - xmlFree() is still broken :-( maybe we are not importing it correctly? im_readhist.c references _imp__xmlFree how is this made? look at gcc -E output ... maybe there's an extra define we need to make it generate the right link code? see what libxml2.dll.a is exporting that looks anything like xmlFree - can we make a fftw3.dll? also, magick.dll? maybe just build with no-undefined? can we then link the DLL against the static lib? - update gtk/glib/etc. on the PC to the latest versions, apparently much quicker (esp. pango) This TODO list is now held on the VIPS Wiki http://wiki.vips.ecs.soton.ac.uk/bin/view/Vips/TodoVips7