libvips/TODO

119 lines
3.4 KiB
Plaintext
Raw Normal View History

2007-11-02 23:35:51 +01:00
- talk about new progress system in im_add_eval_callback()?
- done jpeg, png ... make others dbl-buf writes too
2007-11-02 17:37:32 +01:00
2007-10-31 18:13:22 +01:00
- missing libstdc++ in link? what if we configure with no openexr?
2007-10-31 23:57:18 +01:00
added -lstdc++ to VIPS_LIBS, but will this work on solaris etc.? maybe have
a configure option to turn off CImg
2007-10-19 19:14:25 +02:00
- test maxpos_avg, quite a few changes
2007-10-31 18:13:22 +01:00
- im_exr2vips can now use c++ api
2007-08-29 18:23:50 +02:00
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?
WONTFIX
=======
2007-08-31 15:01:42 +02:00
- 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
2007-08-29 18:23:50 +02:00
- 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