5f0db6a093
on save, rebuild the whole of the exif block from vips metadata ... users can now alter tags by updating attached strings
510 lines
14 KiB
Plaintext
510 lines
14 KiB
Plaintext
|
|
- don't do vips_image_write() at the end of a pipeline, instead try:
|
|
|
|
g_object_set( object, "out", t, NULL );
|
|
|
|
ie. replace the output object
|
|
|
|
this doesn't work, I wonder why ... do we need to add an extra ref to t?
|
|
|
|
yes, the old obj holds a ref to the operation, not the other way around
|
|
|
|
|
|
|
|
|
|
|
|
- vipsimage should be cached too, eg.
|
|
|
|
VipsImage *a = vips_image_new_from_file( "poop.jpg" );
|
|
|
|
can be reused
|
|
|
|
ah ha! will im_jpeg2vips() or whatever get cached? that would do the reuse
|
|
for us
|
|
|
|
move format to new-style and try it
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- bandalike: consider RGB + RGBA ... we should bandup by adding a black band
|
|
|
|
(or white?? unclear)
|
|
|
|
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?
|
|
|
|
|
|
|
|
|
|
- note member free stuff in vipsobject docs
|
|
|
|
should boxed get freed in finalise rather than dispose?
|
|
|
|
vipsobject has few docs atm :(
|
|
|
|
|
|
|
|
|
|
- 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 );
|
|
|
|
why not combine these into a single API call?
|
|
|
|
use array version in several places
|
|
|
|
things like black and min (sources and sinks) only set the dhint
|
|
|
|
|
|
|
|
|
|
- vips_object_set_argument_from_string() needs more arg types
|
|
|
|
must be some way to make this more automatic
|
|
|
|
|
|
|
|
|
|
- add nifti support
|
|
|
|
http://niftilib.sourceforge.net/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- add vips_init_argv() which processes argc/argv for you? handy for tiny
|
|
progs, perhaps
|
|
|
|
|
|
|
|
|
|
- generate the code for vips_add() etc. automatically? it might be
|
|
nice to have them all in one place at least
|
|
|
|
|
|
|
|
|
|
- all the old dispatch wrappers could move to deprecated
|
|
|
|
|
|
|
|
|
|
- support planar tiff
|
|
|
|
|
|
|
|
|
|
- vips operation print could show operation flags as well, cf. "vips
|
|
im_subtract"
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- also VipsFormat ... could this replace vips_image_new_from_string()? or
|
|
could we call this from vips_image_new_from_string()?
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- make a vips8 binding for Python as well
|
|
|
|
use ctypes and not swig so we get an easy Win version
|
|
|
|
wrap new API for C++
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
- 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
|
|
|
|
|
|
|
|
- use g_mmap() or whatever it's called ... or perhaps they don't have all
|
|
these options
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
|
|
- lab [100,0,0] -> srgb [255, 255, 254]? how odd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- im_conv()/im_morph() could have more than 10 programs? try 20 and see if we
|
|
still have a speedup
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
- perspective transform with a matrix ... base it on the Lenz transformer, but
|
|
partial
|
|
|
|
|
|
|
|
|
|
|
|
- maybe im_draw_smudge() is too slow :-( also, we had a sanity failure with
|
|
it, argh
|
|
|
|
make a region, prepare to that, copy back over the image?
|
|
|
|
|
|
|
|
|
|
- use D65 in cmsCreateLab4Profile() ? not sure
|
|
|
|
- im_divide() can /0 for complex
|
|
|
|
- unlink temps earlier on *nix systems
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
- test
|
|
|
|
python setup.py build_ext
|
|
python setup.py build
|
|
python setup.py install
|
|
|
|
|
|
>>> 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:
|
|
swig_import_helper
|
|
_mod = imp.load_module('vimagemodule', fp, pathname, description)
|
|
ImportError: /usr/local/lib/python2.6/dist-packages/vipsCC/vimagemodule.so:
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
- convert_saveable for other writers: tiff, ppm, csv, rad etc.
|
|
|
|
|
|
|
|
- expose more of the tone funcs in nip2
|
|
|
|
- quite a few hist operations have no GUI ... lhisteq, for example? or
|
|
histspec?
|
|
|
|
|
|
|
|
|
|
- rename header, edvips as vipsheader, vipsedit
|
|
|
|
maybe have back compat links?
|
|
|
|
- should im_rwcheck() copy to disc?
|
|
|
|
maybe im_rwcheck_disc() copies to im->filename and maps that
|
|
|
|
rather awkward to do atm with the way check.c is structured
|
|
|
|
- what does G_UNLIKELY() do? can we use it?
|
|
|
|
- rename vipsCC in SWIG as pyvips?
|
|
|
|
- look into G_GNUC_DEPRECATED for back compat in vips8
|
|
|
|
- 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
|
|
|
|
- can we use conv_sep to speed up the memuse benchmarks?
|
|
|
|
- check mosaic1, global_balance, similarity etc. use of im__affine
|
|
|
|
how can we move them to im_affinei ?
|
|
|
|
- doc strings would be nice, read the SWIG notes on this
|
|
|
|
- bilateral filtering, see:
|
|
|
|
http://en.wikipedia.org/wiki/Bilateral_filter
|
|
http://www.shellandslate.com/fastmedian.html
|
|
http://people.csail.mit.edu/sparis/bf_course/
|
|
|
|
also a mail from Martin Breidt has links to several fast free C
|
|
implementations
|
|
|
|
- need a section for vipsobject in the tutorial
|
|
|
|
also a manpage?
|
|
|
|
not really stable yet :( don't document
|
|
|
|
- we shouldn't need to call im_invalidate() in gtkdisp4 :( how can we fix
|
|
this?
|
|
|
|
- we should wrap the format API, also im_render*(), see gtkdisp.cc for sample
|
|
code
|
|
|
|
- need an im_init_world() for C++ which does cmd-line args too, so C++ progs
|
|
can get --vips-progress and stuff automatically
|
|
|
|
- unsharp should work on GREY16? should be easy to add GREY16->LABS
|
|
|
|
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?
|
|
|
|
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!
|
|
|
|
we really just need a LUT for pow() with the right exponent, eg. 2.4 for
|
|
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
|
|
|
|
- HAVE_HYPOT could define a hypot() macro?
|
|
|
|
- im_exr2vips can now use c++ api
|
|
|
|
see TODO notes in openexr read (though they all need more openexr C API)
|
|
|
|
consider openexr write
|
|
|
|
- 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?
|
|
|
|
check:
|
|
|
|
http://www.swig.org/Doc1.3/SWIGDocumentation.html#Python_nn8
|
|
http://docs.python.org/dist/dist.html
|
|
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?
|
|
|
|
- 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
|
|
|
|
- also png2vips?
|
|
|
|
- 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!
|