libvips/TODO

256 lines
7.0 KiB
Plaintext
Raw Normal View History

2009-11-06 15:35:43 +01:00
- some of deprecated.h repeats stuff we do better in image.h, eg. addr()
should just call IM_REGION_ADDR()
2009-08-18 17:32:28 +02:00
- rename vipsCC in SWIG as pyvips?
2009-08-16 17:00:08 +02:00
2009-11-05 22:48:31 +01:00
- im_flood*() should use inline rather than #define
2009-06-17 18:00:16 +02:00
2009-07-06 10:12:37 +02:00
- try the new liboil thing:
2009-12-10 11:58:10 +01:00
http://code.entropywave.com/projects/orc/
2009-07-06 10:12:37 +02:00
pick something like abs and time it
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-11-05 22:48:31 +01:00
Something like:
const char *im_system_image( IMAGE *in, const char *command, char **log );
Actions:
- create two empty temporary files
- write the image to the first
- call system() on the expanded command
- capture stdout/stderr into log
- delete the temp input file
- return the output filename, or NULL if the command failed (log is still
returned in this case)
The caller would open the output file, either with im_open(), or with it's
own system (nip2 has it's own open file thing to give progress feedback and
use disc for format conversion), and be responsible for deleting the temp
output file at some point.
2009-01-23 13:03:11 +01:00
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