libvips/TODO

247 lines
6.7 KiB
Plaintext
Raw Normal View History

2010-01-22 17:17:23 +01:00
- how about im_invalidate_area()? we currently repaint the whole window on
every paint action in nip2 :-(
2010-01-21 18:04:00 +01:00
2010-01-22 17:56:57 +01:00
we'd need to have coordinate transforms broken out for this :-(
2010-01-25 15:23:30 +01:00
- try writing docs for vipsthumbnail with gtkdoc? then try header etc.
2010-01-25 17:28:34 +01:00
we need to have a separate docs package for the tools/ dir
2010-01-25 15:23:30 +01:00
- rename header, edvips as vipsheader, vipsedit
maybe have back compat links?
2010-01-22 17:56:57 +01:00
- should im_rwcheck() copy to disc?
maybe im_rwcheck_disc() copies to im->filename and maps that
2010-01-22 18:08:39 +01:00
rather awkward to do atm with the way check.c is structured
2010-01-14 23:07:07 +01:00
2010-01-08 15:28:40 +01:00
- what does G_UNLIKELY() do? can we use it?
2009-11-06 15:35:43 +01:00
2009-08-18 17:32:28 +02:00
- rename vipsCC in SWIG as pyvips?
2009-08-16 17:00:08 +02:00
2009-04-16 22:13:28 +02:00
- look into G_GNUC_DEPRECATED for back compat in vips8
2009-04-16 16:42:16 +02:00
- 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
2009-04-05 12:14:57 +02:00
- can we use conv_sep to speed up the memuse benchmarks?
2009-02-24 17:40:10 +01:00
- move im_shrink & friends to resample?
match_linear, match_linear_search?
what about im_stretch3.c, im_resize_linear
2009-02-24 18:00:40 +01:00
- im_render should use a hash for tile lookup ... or+shift x/y together
2009-03-05 14:20:43 +01:00
load wtc.jpg, rotate 42 degrees, zoom in and out quickly for a while, quit
tiles are leaked :(
does not leak if you wait for repaint to finish before zooming/unzooming
problem with waiting for paint to finish in render_kill?
2009-02-24 18:00:40 +01:00
2009-02-23 23:23:11 +01:00
- check mosaic1, global_balance, similarity etc. use of im__affine
how can we move them to im_affinei ?
2008-12-19 13:32:46 +01:00
2009-03-25 15:38:02 +01:00
- radiance read/write needs docs
2008-10-20 19:10:40 +02:00
2009-03-25 15:38:02 +01:00
maybe have an im_format(3) page with all the built-in formats?
2009-01-05 17:45:39 +01:00
2009-03-25 15:38:02 +01:00
hard until we document vips_object :(
2009-01-05 17:45:39 +01:00
2009-03-25 15:38:02 +01:00
- same for matio?
2009-01-05 17:45:39 +01:00
2009-03-25 15:38:02 +01:00
- doc strings would be nice, read the SWIG notes on this
2009-01-05 17:45:39 +01:00
- bilateral filtering, see:
http://en.wikipedia.org/wiki/Bilateral_filter
http://www.shellandslate.com/fastmedian.html
2009-03-20 00:43:52 +01:00
also a mail from Martin Breidt has links to several fast free C
implementations
2009-02-23 23:23:11 +01:00
- try making vips_add(), an operator as a class
2009-01-05 17:45:39 +01:00
2009-02-23 23:23:11 +01:00
- need to write interpolate docs ... manpages and tutorial
2009-01-05 17:45:39 +01:00
2009-02-23 23:23:11 +01:00
difficult without docs for vips_object
2009-01-05 17:45:39 +01:00
2009-02-23 23:23:11 +01:00
- need a section for vipsobject in the tutorial
2009-01-05 17:45:39 +01:00
2009-02-23 23:23:11 +01:00
also a manpage?
2009-01-05 17:45:39 +01:00
2009-02-23 23:23:11 +01:00
not really stable yet :( don't document
2008-10-20 19:10:40 +02:00
2009-02-23 23:23:11 +01:00
- how to expose things like yafrsmooth's "sharpening" parameter to
C++/Python?
2008-08-21 10:32:24 +02:00
2009-02-23 23:23:11 +01:00
can we write a find-by-nickname function? eg.
2008-10-19 22:25:48 +02:00
2009-02-23 23:23:11 +01:00
GType vips_get_type (const char *base, const char *nickname)
2008-10-19 22:25:48 +02:00
2009-02-23 23:23:11 +01:00
then
2008-10-19 22:25:48 +02:00
2009-02-23 23:23:11 +01:00
vips_get_type ("VipsInterpolator", "bicubic")
2008-10-19 22:25:48 +02:00
2009-02-23 23:23:11 +01:00
would get us the GType for VipsInterpolatorBicubic
2008-08-21 10:32:24 +02:00
2008-10-11 23:29:16 +02:00
- we shouldn't need to call im_invalidate() in gtkdisp4 :( how can we fix
this?
2008-08-21 10:32:24 +02:00
2008-10-11 23:29:16 +02:00
will im_invalidate() trash the render cache too?
2008-08-21 10:32:24 +02:00
2008-10-11 23:29:16 +02:00
- we should wrap the format API, also im_render*(), see gtkdisp.cc for sample
code
2008-08-21 10:32:24 +02:00
2008-10-11 23:29:16 +02:00
- have a base VObject class and put the ref stuff in there ... share between
VMask, VDisplay, VImage
2008-08-19 10:01:23 +02:00
2008-10-11 23:29:16 +02:00
- need an im_init_world() for C++ which does cmd-line args too, so C++ progs
can get --vips-progress and stuff automatically
2008-08-19 10:01:23 +02:00
2008-08-15 10:40:05 +02:00
- 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
2008-05-12 20:16:38 +02:00
- try
libsrc/convolution$ grep -l offsets *.c
could we do the don't calc offsets thing unless bpl; changes thing in more
places?
2008-06-24 12:37:54 +02:00
- unsharp should work on GREY16? should be easy to add GREY16->LABS
2008-02-29 19:37:05 +01:00
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?
2008-04-02 20:19:35 +02:00
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!
2008-04-23 14:17:26 +02:00
we really just need a LUT for pow() with the right exponent, eg. 2.4 for
2008-04-02 20:19:35 +02:00
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
2008-02-17 08:53:02 +01:00
- HAVE_HYPOT could define a hypot() macro?
2007-10-31 18:13:22 +01:00
2008-02-17 08:53:02 +01:00
- im_exr2vips can now use c++ api
2007-08-29 18:23:50 +02:00
2008-10-11 23:29:16 +02:00
see TODO notes in openexr read (though they all need more openexr C API)
consider openexr write
2007-08-29 18:23:50 +02:00
- 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?
2008-01-16 16:18:21 +01:00
check:
http://www.swig.org/Doc1.3/SWIGDocumentation.html#Python_nn8
http://docs.python.org/dist/dist.html
2008-02-17 08:53:02 +01:00
- 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?
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
2008-03-31 19:51:24 +02:00
- also png2vips?
2007-08-29 18:23:50 +02:00
- 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