libvips/TODO

542 lines
14 KiB
Plaintext
Raw Normal View History

2011-12-11 23:01:39 +01:00
- still some size_t that should be guint64, search for all use of
VIPS_IMAGE_SIZEOF_IMAGE(), vips__parse_size()
2011-12-06 13:34:40 +01:00
- 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
2011-12-05 18:39:11 +01:00
- openslide sets a g_log() handler, argh, must just set temp
- make an argb coding type, add to nip2 and known coding
- "background-rgb" should be a macro
- nip2 should use zooming support, if possible
2011-12-09 15:54:54 +01:00
2011-12-09 19:11:13 +01:00
2011-12-05 18:39:11 +01:00
2011-12-06 13:34:40 +01:00
- what should we do?
vips_image_new_from_file( "x.tif[page=12]" );
or maybe:
vips_image_new_from_file( "x.tif", "page", 12, NULL );
or maybe neither? we'd like this to work though:
header x.tif[page=12]
object_new_from_string()?
2011-12-05 18:39:11 +01:00
- see vips_image_cache(): it currently writes to @out allocated by its caller
should this be called vips_image_write_cache()? or wrapped in the style
of vips_copy()?
2011-12-03 11:59:25 +01:00
- "header fred.png" does not work, since header uses im_open() which uses
2011-12-02 10:10:11 +01:00
VipsForeign
2011-11-29 12:10:56 +01:00
- make the old format/vips.c into a stub as well?
2011-11-28 10:39:20 +01:00
move format/* to deprecated
2011-11-24 22:53:40 +01:00
- 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
- test docs
gtk-doc can't introspect to generate class docs since it has no way to init
the classes ... investigate
- try an area operation, like conv, VipsArea? oops no haha what name should we
use?
- test _O_TEMPORARY thing on Windows
- avg/dev etc. should uncode images? eg. labq2lab etc.
how about ifthenelse?
2011-10-25 16:44:54 +02:00
2011-11-01 13:31:59 +01:00
- bandalike: consider RGB + RGBA ... we should bandup by adding a black band
2011-10-25 16:44:54 +02:00
2011-11-01 13:31:59 +01:00
(or white?? unclear)
2011-10-25 16:44:54 +02:00
2011-11-01 13:31:59 +01:00
not clear if this is a good idea ... eg. when we upband a 1 band to a 2
band, should we duplicate the 1 band or add black?
2011-10-25 16:44:54 +02:00
2011-10-25 16:44:54 +02:00
2011-11-01 13:31:59 +01:00
- note member free stuff in vipsobject docs
2011-10-25 16:44:54 +02:00
2011-11-01 13:31:59 +01:00
should boxed get freed in finalise rather than dispose?
vipsobject has few docs atm :(
2011-10-20 12:22:49 +02:00
- we have this is many places:
if( vips_image_copy_fieldsv( conversion->output,
insert->main, insert->sub, NULL ) )
return( -1 );
vips_demand_hint( conversion->output,
VIPS_DEMAND_STYLE_THINSTRIP, insert->main, insert->sub, NULL );
2011-10-20 15:56:13 +02:00
why not combine these into a single API call?
use array version in several places
2011-10-20 12:22:49 +02:00
things like black and min (sources and sinks) only set the dhint
2011-10-20 12:22:49 +02:00
- vips_object_set_argument_from_string() needs more arg types
2011-09-20 15:52:02 +02:00
must be some way to make this more automatic
2011-09-20 15:52:02 +02:00
2011-10-11 15:30:44 +02:00
- add nifti support
http://niftilib.sourceforge.net/
- add vips_init_argv() which processes argc/argv for you? handy for tiny
progs, perhaps
2011-11-06 12:54:52 +01:00
just saves 5 lines of code, don't bother
2011-08-26 11:15:39 +02:00
- generate the code for vips_add() etc. automatically? it might be
nice to have them all in one place at least
2011-08-26 11:15:39 +02:00
- all the old dispatch wrappers could move to deprecated
- support planar tiff
2011-08-15 19:27:43 +02:00
- vips operation print could show operation flags as well, cf. "vips
im_subtract"
2011-07-26 23:37:03 +02:00
haha, we don't have any flags like that on operation ... NOCACHE looks
useful, should we add that? any others?
maybe wait until we have to
2011-06-04 18:44:54 +02:00
- 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
2011-06-04 18:44:54 +02:00
2011-05-25 09:51:19 +02:00
- make a vips8 binding for Python as well
2011-05-25 09:51:19 +02:00
use ctypes and not swig so we get an easy Win version
2011-05-16 18:34:00 +02:00
wrap new API for C++
2011-05-16 18:34:00 +02:00
2011-05-23 22:27:33 +02:00
2011-05-09 19:28:21 +02:00
- Magick:
- do we bundle "convert" in the OS X / win32 builds? if we don't we
should
- need vips_image_invalidate_area()
- add matlab write
2011-02-03 13:52:14 +01:00
- 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
2011-02-03 13:52:14 +01:00
- use g_mmap() or whatever it's called ... or perhaps they don't have all
these options
2011-02-02 22:19:13 +01:00
2011-01-12 14:40:07 +01:00
- use |_O_TEMPORARY to open()'s mode on Windows for tmpfiles to increase the
chances we actually delete
see http://www.mail-archive.com/bug-gnulib@gnu.org/msg05730.html
2011-01-11 17:58:59 +01:00
- lab [100,0,0] -> srgb [255, 255, 254]? how odd
2010-11-30 12:53:53 +01:00
2010-11-29 15:46:47 +01:00
- im_conv()/im_morph() could have more than 10 programs? try 20 and see if we
still have a speedup
2011-01-11 17:58:59 +01:00
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
2010-11-20 18:55:33 +01:00
- perspective transform with a matrix ... base it on the Lenz transformer, but
partial
2010-11-03 15:45:59 +01:00
2010-11-02 11:59:34 +01:00
2010-11-05 11:52:29 +01:00
2010-11-02 11:59:34 +01:00
2010-09-30 15:36:21 +02:00
- maybe im_draw_smudge() is too slow :-( also, we had a sanity failure with
it, argh
2010-09-29 15:46:45 +02:00
2010-09-30 17:27:54 +02:00
make a region, prepare to that, copy back over the image?
2010-09-28 18:06:58 +02:00
2010-09-24 10:12:30 +02:00
2010-08-13 22:02:23 +02:00
2010-08-02 17:58:30 +02:00
- use D65 in cmsCreateLab4Profile() ? not sure
2010-07-31 12:41:59 +02:00
- im_divide() can /0 for complex
2010-07-28 17:01:48 +02:00
2010-08-01 22:27:47 +02:00
2010-08-01 11:50:40 +02:00
2010-05-12 10:39:26 +02:00
- test
2010-05-05 17:22:04 +02:00
python setup.py build_ext
python setup.py build
python setup.py install
2010-05-06 22:43:44 +02:00
>>> from vipsCC import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.6/dist-packages/vipsCC/VImage.py", line 25, in
<module>
vimagemodule = swig_import_helper()
File "/usr/local/lib/python2.6/dist-packages/vipsCC/VImage.py", line 21, in
swig_import_helper
_mod = imp.load_module('vimagemodule', fp, pathname, description)
ImportError: /usr/local/lib/python2.6/dist-packages/vipsCC/vimagemodule.so:
2011-05-25 09:51:19 +02:00
swig_import_helper
_mod = imp.load_module('vimagemodule', fp, pathname, description)
ImportError: /usr/local/lib/python2.6/dist-packages/vipsCC/vimagemodule.so:
2010-05-06 22:43:44 +02:00
undefined symbol: _ZTIN4vips5VMaskE
ie. vimagemodule.so can't find libvipsCC.so I guess? or perhaps the compiler
is being given a differnt mangling flag
we're building with:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DDEBUG_FATAL=1 -DDEBUG_LEAK=1
-I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/libxml2
-I/usr/include/libpng12 -I/usr/include/libexif -I/usr/include/glib-2.0
-I/usr/include/freetype2 -I/usr/include/OpenEXR -I/usr/include/ImageMagick
-I../../libvips/include -I../../libvipsCC/include -I/usr/include/python2.6 -c
vimagemodule.cpp -o build/temp.linux-x86_64-2.6/vimagemodule.o -pthread
-fopenmp -pthread -Wl,--export-dynamic -pthread -pthread -pthread
g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/vimagemodule.o -Wl,-R/home/john/vips/lib
-lMagickWand -lMagickCore -lpng12 -ltiff -lz -ljpeg -lgthread-2.0 -lrt
-lglib-2.0 -lgmodule-2.0 -lxml2 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0
-lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lrt -lglib-2.0 -lfftw3 -lm -llcms -lIlmImf -lz -lImath -lHalf
-lIex -lIlmThread -lmatio -lz -lexif -lm -lstdc++ -lm -o
build/lib.linux-x86_64-2.6/vipsCC/vimagemodule.so -pthread -fopenmp -pthread
-Wl,--export-dynamic -pthread -pthread -pthread
2010-05-12 10:55:20 +02:00
how does this compare to the working build? swig/vipsCC does
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../libvips/include -I../../libvipsCC/include -DDEBUG_FATAL -DDEBUG_LEAK -pthread -fopenmp -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/libxml2 -I/usr/include/libpng12 -I/usr/include/libexif -I/usr/include/glib-2.0 -I/usr/include/freetype2 -I/usr/include/OpenEXR -I/usr/include/ImageMagick -I/usr/include/python2.6 -g -Wall -MT vimagemodule.lo -MD -MP -MF .deps/vimagemodule.Tpo -c vimagemodule.cxx -o vimagemodule.o >/dev/null 2>&1
g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbeginS.o .libs/vimagemodule.o -Wl,-rpath -Wl,/home/john/SVN/vips/vips7/trunk/libvipsCC/.libs -Wl,-rpath -Wl,/home/john/SVN/vips/vips7/trunk/libvips/.libs -Wl,-rpath -Wl,/home/john/vips/lib ../../libvipsCC/.libs/libvipsCC.so ../../libvips/.libs/libvips.so /usr/lib/libMagickWand.so /usr/lib/libMagickCore.so -lpng12 /usr/lib/libtiff.so /usr/lib/libjpeg.so /usr/lib/libxml2.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lfontconfig /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so /usr/lib/libfftw3.so /usr/lib/liblcms.so /usr/lib/libIlmImf.so -lImath -lHalf -lIex -lIlmThread /usr/lib/libmatio.so -lz /usr/lib/libexif.so -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../.. -L/usr/lib/x86_64-linux-gnu -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crtn.o -pthread -Wl,--export-dynamic -pthread -pthread -pthread -pthread -Wl,-soname -Wl,vimagemodule.so -o .libs/vimagemodule.so
2010-05-06 22:43:44 +02:00
2010-05-05 17:22:04 +02:00
2010-04-25 23:20:00 +02:00
2010-05-12 10:39:26 +02:00
- convert_saveable for other writers: tiff, ppm, csv, rad etc.
2010-04-25 23:20:00 +02:00
2010-04-19 10:04:42 +02:00
2010-03-26 18:32:29 +01:00
- expose more of the tone funcs in nip2
- quite a few hist operations have no GUI ... lhisteq, for example? or
histspec?
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-05 12:14:57 +02:00
- can we use conv_sep to speed up the memuse benchmarks?
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
- 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
2010-09-28 18:20:24 +02:00
http://people.csail.mit.edu/sparis/bf_course/
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
- 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
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
- 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
- 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-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
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!