- maybe IM_INTERPOLATE() isn't a good idea? maybe just IM_GOBJECT? - try making vips_add(), an operator as a class - nickname, description etc need to be properties so nip2 can read them arg, they are class properties, argh, can we support these? - make a new package for "resample"? im_shrink & friends could go in there too - make a "deprecated" package too - im_affinei and im_affinei_all need docs - update format docs - how to expose things like yafrsmooth's "sharpening" 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 - vips_object_print, set_name etc. need writing - check mosaic1, global_balance, similarity etc. use of im__affine how can we move them to im_affinei ? - update the Portfiles on the mac and on the website from the macports ones - im_render should use a hash for tile lookup ... or+shift x/y together - bilinear should be a true subclass of interpolate ... and put the tables into the base class - add 'name' to vipsobbject, and vips_object_print() ... handy for debugging make 'print' into a virtual method so subclasses can add stuff if they want WONTFIX for 7.16 ================ - we shouldn't need to call im_invalidate() in gtkdisp4 :( how can we fix this? will im_invalidate() trash the render cache too? - 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 - examine yafr and add as another interpolation option for im_affine - how much slower wouuld we get if we did a function call + switch for interpolate in im_affine()? it would let us break out the interpolation stuff from the transformer - we need another version of im_affine() with an 'interpolate' option :-( or maybe have im_interpolate_t as another object which we pass to im_affine() - 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 - it'd be nice to handle vips format images in the same im_format system, but it's not clear if this is possible - add new type names, eg. im_region_t, im_image_t etc. and deprecate old names? - 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! - 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