- look for FCLIP / FABS use ... VIPS_ABS() on float type - write a shrinker that does two 1D shrinks, vertical and horizontal, with bicubic interpolation should be much quicker than affine + bicubic vips_resize() can use this, for the default path at least - get some brightly coloured spots with nohalo / vsqbs on wobble.ws ... very odd, the interpolation shouldn't change between bands - still not happy about float->int mask conversion in im_vips2mask.c - need to follow up on https://github.com/jcupitt/libvips/issues/347 trying new shrinker, also try resize change, should be fixed - colour needs to split _build() into preprocess / process / postprocess phases in icc_import, for example, we want to check that the supplied profile is compatible with the input image as it will be when unpacked and ready for process_line see vips_image_expected_bands() in icc_transform.c for the current hacky solution - does ruby need to unpack RefString as well? what about C++? - are the mosaic functions calling vips_fastcor()? it must be very slow add vips_fastcor_direct() nope .. it's im_chkpair.c:im_correl() im_extract_area(main) im_extract_area(sub) im_extract_band(main) im_extract_band(sub) im_spcor(sub) im_maxpos(sub) then im__chkpair() runs that 20 times, then loops ... oh dear - perhaps im_maxpos_subpel() / im_minpos_subpel() should be undeprecated, useful with vips_fastcor() - support orientation tag in tiff images see http://www.awaresystems.be/imaging/tiff/tifftags/orientation.html seems to be the same values used for exif jpg uses "exif-ifd0-Orientation", see conversion/autorot.c instead, standardize on "orientation" and give it an int value jpg load and save need to use this in preference to the exif value tiff load and save need to set and recover this value tiff load needs an autorot flag don't touch parse_header() on header-only read, just swap width/height and delete the tag on full image read, use read_jpeg_rotate(), broken out into a separate func see https://github.com/jcupitt/libvips/issues/243 - why can't we do im = Vips.Image.new_from_file(sys.argv[1], access = "sequential") ValueError: invalid literal for int() with base 10: 'sequential' no idea ... this works fine: im.embed(10, 10, 100, 100, extend = "copy") what about im = Vips.Image.jpegload(sys.argv[1], access = "sequential") nope, fails too ... mysterious! - test other cpp arg types input int works input double input enum works input image works input doublevec input imagevec input blob output int output double works output enum output image works output doublevec output imagevec output blob - fix up aconv - rewrite im_conv() etc. as vips_conv(), also the mosaicing functions finally finish --disable-deprecated option - can we use postbuild elsewhere? look at use of "preclose" / "written", etc. - test draw_mask on labq images we probably need to unpack the ink back to double before blending - ink to vec etc must have a way to give a complex constant eg. drawink needs a --ink_imag option with the imaginary components of the ink look for uses of vips__vector_to_ink() and add extra params to other places too, eg. vips_embed(), vips_insert() etc. - vips__ink_to_vector() needs an optional imag return - vips_getpoint() needs an optional imag return - add porter-duff compositing, see https://github.com/jcupitt/ruby-vips/issues/28 - now vips_linear() has uchar output, can we do something with orc? - do restrict on some more packages, we've just done arithmetic so far also resample, colour, some of conversion, create, - 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 - 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? we have "shrink" for jpegload, move this into the base loader support it for tiff and openslide as well use it from nip2 for zooming? only if the partial flag is set though, we don't want to use it on jpg files - use the webp advanced encoding api to set a write function for webp save to file - use g_log() instead of vips_info()? - 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 not sure it works for order 2 either, we are seeing interpolation errors on image edges 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 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 ========== - 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?