648 lines
17 KiB
Plaintext
648 lines
17 KiB
Plaintext
|
|
- lintra_vec next
|
|
|
|
so we need a unary.c .. easy copy frombinary.c now that most of binary has
|
|
moved into arithmetic
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- try:
|
|
|
|
$ vips insert Gugg_coloured.jpg x.jpg x.v 100 100 --expand --background "1 2 3"
|
|
|
|
often gets the BG colour wrong, eg. notworking:
|
|
|
|
$ 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)
|
|
|
|
vs. working:
|
|
|
|
$ 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?
|
|
|
|
strange, seems to work on laptop, try again on desktop
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- do clip etc. in new style, good to get everything that VipsAdd uses in
|
|
the new stack
|
|
|
|
insert* needs clip, lintra_vec
|
|
|
|
|
|
|
|
|
|
- bandalike: consider RGB + RGBA ... we should bandup by adding a black band
|
|
|
|
(or white?? unclear)
|
|
|
|
|
|
|
|
|
|
|
|
- note member free stuff in vipsobject docs
|
|
|
|
should boxed get freed in finalise rather than dispose?
|
|
|
|
- vipsimage should be cached too, eg.
|
|
|
|
VipsImage *a = vips_image_new_from_file( "poop.jpg" );
|
|
|
|
can be reused
|
|
|
|
- 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
|
|
|
|
- the lifetime of an object is
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- lintra_vec next ... how should we do vips_lin() vs. vips_lin_vec()? do we
|
|
need two separate things?
|
|
|
|
perhaps just have vips_lin() as a convenience function
|
|
|
|
how about a "squash" param to VipsLin which clips the output type back to
|
|
the input type? maybe not a great idea
|
|
|
|
- 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)
|
|
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
- 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:
|
|
|
|
exif-Orientation: 1 (Top-left, Short, 1 component, 2 bytes)
|
|
|
|
so we can restore the value from the "1" without needding to look up i18n
|
|
strings
|
|
|
|
|
|
|
|
|
|
- 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!
|