libvips/TODO

642 lines
17 KiB
Plaintext
Raw Normal View History

2011-10-27 16:27:03 +02:00
- lintra_vec next
2011-10-28 18:36:20 +02:00
- try:
2011-10-27 16:27:03 +02:00
2011-10-28 18:36:20 +02:00
$ vips insert Gugg_coloured.jpg x.jpg x.v 100 100 --expand --background "1 2 3"
2011-10-27 16:27:03 +02:00
2011-10-28 18:36:20 +02:00
often gets the BG colour wrong, eg. notworking:
2011-10-28 18:36:20 +02:00
$ vips insert Gugg_coloured.jpg x.jpg x.v 100 100 --expand --background "1 2 3"
vips__vector_to_ink: starting
vips_cast_build: 0xbff920
vips_cast_build: 0xbff920 done
vips_cast_gen: 0xbff920
vips__vector_to_ink: ink = 0xc1c660 (1 2 3)
2011-10-28 18:36:20 +02:00
vs. working:
2011-10-28 18:36:20 +02:00
$ vips insert Gugg_coloured.jpg x.jpg x.v 100 100 --expand --background "1 2 3"
vips__vector_to_ink: starting
vips_cast_build: 0x1760920
vips_cast_build: 0x1760920 done
vips__vector_to_ink: ink = 0x177d660 (0 0 0)
vips_cast_gen() is never called???
vips__vector_to_ink() breakage something to do with the new bandjoin thing?
2011-10-29 21:59:32 +02:00
strange, seems to work on laptop, try again on desktop
2011-10-27 16:27:03 +02:00
2011-10-26 17:53:39 +02:00
2011-10-26 17:51:27 +02:00
- do clip etc. in new style, good to get everything that VipsAdd uses in
the new stack
insert* needs clip, lintra_vec
2011-10-26 16:09:01 +02:00
- bandalike: consider RGB + RGBA ... we should bandup by adding a black band
2011-10-25 16:44:54 +02:00
2011-10-26 16:09:01 +02:00
(or white?? unclear)
2011-10-26 10:39:14 +02:00
2011-10-26 17:53:39 +02:00
2011-10-26 14:26:20 +02:00
- note member free stuff in vipsobject docs
2011-10-26 10:39:14 +02:00
2011-10-26 14:26:20 +02:00
should boxed get freed in finalise rather than dispose?
2011-10-25 16:44:54 +02:00
2011-10-26 14:26:20 +02:00
- vipsimage should be cached too, eg.
2011-10-25 17:22:03 +02:00
2011-10-26 14:26:20 +02:00
VipsImage *a = vips_image_new_from_file( "poop.jpg" );
2011-10-25 17:22:03 +02:00
2011-10-26 14:26:20 +02:00
can be reused
2011-10-25 17:22:03 +02:00
2011-10-26 14:26:20 +02:00
- we should cache on "written" ... we should emit written for all objects, and
there should be a a vipsarg flag to block updates after written
2011-10-25 17:22:03 +02:00
- the lifetime of an object is
2011-10-25 16:44:54 +02:00
new
set base params
build
set more params
write
... and now it's frozen and read-only, except for things like "kill"
unref
we have
gboolean constructed; /* Construct done and checked */
I suppose we need to add
gboolean written; /* Object done and frozen */
and a "written" virtual method I guess
this seems like a big change :-( can we avoid it?
bodge it for now, fix properly after we merge
- don't do vips_image_write() at the end of a pipeline, instead try:
g_object_set( object, "output", t );
ie. replace the output object
fails due to "assign once only" rule ... we need "don't assign after
written" instead
2011-10-25 16:44:54 +02:00
2011-10-26 14:26:20 +02:00
- lintra_vec next ... how should we do vips_lin() vs. vips_lin_vec()? do we
need two separate things?
2011-10-26 14:26:20 +02:00
perhaps just have vips_lin() as a convenience function
2011-10-26 14:26:20 +02:00
how about a "squash" param to VipsLin which clips the output type back to
the input type? maybe not a great idea
2011-10-25 16:44:54 +02:00
2011-10-26 14:26:20 +02:00
- all things that use sizealike could take a --background param? or an
--extend param? maybe not a great idea (maybe handy for convolve affine etc.
though)
2011-10-25 16:44:54 +02:00
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
2011-10-19 13:06:02 +02:00
- change the way we wrap vips7 operations
make im_max() appear in vips8 as "im_max" (we wrap as "max" right now), this
will help compatibility when we redo as a class and create "max"
make vips.c try the vip8 APIs for an operation before falling back to vips7
... actually, leave it alone, it can never work well, no point encouraging
its use
2011-10-18 15:50:47 +02:00
- we have some serious exif problems
we attach exif as both the original exif data and as a set of broken-out
tags, such as 'exif-Orientation' ... the tags are attached as strings
when we write a jpg file, we parse the original exif block, update the
resolution and Orientation tags from metadata, and add to the output file
we need a way to update the exif block with all 'exif-' tags, but this is
hard because a tag is
tag
format (eg. short, rational, string)
components (for short, for example, you can have an array of 12)
data (byte buffer)
size (sizeof byte buffer)
many tags have extra meanings, for example Orientation means that the format
must be short and the data must be 1, 2, 3, 4, 5, 6, 7 or 8 for the 8
possible rotates and flips ... libexif does not expose any way to convert
strings to enum values safely, what do we do with "Bottom-right"
how do we expose this to bindings in a sane way, how do we accurately
convert the updated tag values back into correct exif when we reattach
additionally, exif tags can be in one of several ifd blocks, do we need to
add the tag to the correct block? how do we save that information?
oo! we have the original, of course
to reattach, get the entry from the original exif block, get the updated
tag, coerce the updated value back to the orginal format
save exif entries to tags as something like:
2011-10-18 15:50:47 +02:00
exif-Orientation: 1 (Top-left, Short, 1 component, 2 bytes)
2011-10-18 15:50:47 +02:00
so we can restore the value from the "1" without needding to look up i18n
strings
2011-10-18 15:50:47 +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-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
- also VipsFormat ... could this replace vips_image_new_from_string()? or
could we call this from vips_image_new_from_string()?
2011-05-25 15:06:23 +02:00
at the moment, VipsFormat subclasses never get made, we just use the classes
... we'd need to start making real vipsformat objects for this to work
2011-05-25 09:51:19 +02:00
how would this work?
at the moment we have
image = vips_image_new_from_file( filename );
build a VipsImage with filename "r"
we also have the new CLI thing
obj = vips_object_new_from_string( class, str );
calls class->new_from_string( first-component(str) ), then sets
optional args from rest-of-str(str), then does _build()
image-class->new_from_string() just make a vipsimage "r" str
the _build() uses VipsFormat() to load via im_tiff2vips() or whatever
so ... we could change vips_image_new_from_file() to be
VIPS_IMAGE( vips_object_new_from_string( VipsImageClass, str ) )
we could also make VipsImage::new_from_string() make a real VipsFormat
object, then load options could be set from the str
how does save work? we call image-class->output_to_arg(obj, str), which in
turn calls vips_image_write(), which in turn uses VipsFormat
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 11:50:40 +02:00
- unlink temps earlier on *nix systems
2010-08-01 22:27:47 +02:00
the file is created by setupout, which is called just before generate or
writeline, so perhaps unlink on evalstart?
no, on a rewind we need to be able to close and reopen, argh
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-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-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!