352 lines
9.0 KiB
Plaintext
352 lines
9.0 KiB
Plaintext
- load 500 jpegs, shrink, save
|
|
|
|
VM use is huge, ouch, could we use a bit less?
|
|
|
|
maybe free all windows on evalend? are there regions left about? how come we
|
|
use so many resources?
|
|
|
|
get about 300 images in on the laptop
|
|
|
|
|
|
|
|
- VipsFormat next? where should we document the im_vip2jpeg() options?
|
|
|
|
|
|
- more stuff from util.c? too much to do it all now
|
|
|
|
- im_render()?
|
|
|
|
- memory.c
|
|
|
|
- constant images:
|
|
|
|
we make them with im_black(), then m_lintra(), then im_clip(). How
|
|
about instead making a 1x1 pixel image and expanding it with im_emed()
|
|
would this be quicker?
|
|
|
|
test wth nip2
|
|
|
|
might be rather similar, nip2 will use im_black() + im_maplut() I
|
|
guess
|
|
|
|
maybe optimise the expand-one-pixel mode of im_embed()?
|
|
|
|
- im_flood*() should use inline rather than #define
|
|
|
|
- we have tools/ and contrib/ argh
|
|
|
|
- Joe's new defs
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
- 1-bit PNG read is broken?
|
|
|
|
experimenting with
|
|
|
|
png_set_shift( read->pPng, 2 );
|
|
|
|
in im_png2vips.c
|
|
|
|
test image in gmail
|
|
|
|
- rename vipsCC in SWIG as pyvips?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- try the new liboil thing:
|
|
|
|
http://www.schleef.org/orc/
|
|
|
|
pick something like abs and time it
|
|
|
|
- gbandjoin in Python seems to be broken
|
|
|
|
a = VImage.VImage.gbandjoin ([a, a, a])
|
|
|
|
fails with a typecheck error
|
|
|
|
probably all IMAGEVEC wrappers are duff like this ... the proto should take
|
|
a std::allocator too?
|
|
|
|
- all the messages like:
|
|
|
|
(nip2:31883): GLib-GObject-WARNING **: IA__g_object_set_property:
|
|
object class `VipsInterpolateBilinear' has no property named
|
|
`sharpening'
|
|
|
|
are v. annoying, can we suppress them? don't set unless the property exists
|
|
in the vips generic property setter? or do it in nip2?
|
|
|
|
- vip2dj -rotate STILL does not always work, eg. try
|
|
/data/john/study2/small0.v ... should NOT rotate, but it does
|
|
|
|
- IMAGE->file_length should be gint64 rather than size_t?
|
|
|
|
if we make this change, need to remove extra casts from various uses
|
|
|
|
- rename "header" program? or maybe use "vips header" instead?
|
|
|
|
it's disabled on ubuntu due to a name clash
|
|
|
|
- import ~/summer-demo/summer.tif fails with "unable to read embedded
|
|
profile", is this a bug? better err msg would be good
|
|
|
|
trying to catch errors now, but is it working? not sure
|
|
|
|
- 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
|
|
|
|
WONTFIX for 7.18
|
|
================
|
|
|
|
- can we use conv_sep to speed up the memuse benchmarks?
|
|
|
|
- move im_shrink & friends to resample?
|
|
|
|
match_linear, match_linear_search?
|
|
|
|
what about im_stretch3.c, im_resize_linear
|
|
|
|
- im_render should use a hash for tile lookup ... or+shift x/y together
|
|
|
|
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?
|
|
|
|
- check mosaic1, global_balance, similarity etc. use of im__affine
|
|
|
|
how can we move them to im_affinei ?
|
|
|
|
- make a "deprecated" package too
|
|
|
|
- update the Portfiles on the mac and on the website from the macports ones
|
|
|
|
- radiance read/write needs docs
|
|
|
|
maybe have an im_format(3) page with all the built-in formats?
|
|
|
|
hard until we document vips_object :(
|
|
|
|
- same for matio?
|
|
|
|
- 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
|
|
|
|
also a mail from Martin Breidt has links to several fast free C
|
|
implementations
|
|
|
|
- try making vips_add(), an operator as a class
|
|
|
|
- need to write interpolate docs ... manpages and tutorial
|
|
|
|
difficult without docs for vips_object
|
|
|
|
- need a section for vipsobject in the tutorial
|
|
|
|
also a manpage?
|
|
|
|
not really stable yet :( don't document
|
|
|
|
- how to expose things like yafrsmooth's "sharpening" parameter to
|
|
C++/Python?
|
|
|
|
can we write a find-by-nickname function? eg.
|
|
|
|
GType vips_get_type (const char *base, const char *nickname)
|
|
|
|
then
|
|
|
|
vips_get_type ("VipsInterpolator", "bicubic")
|
|
|
|
would get us the GType for VipsInterpolatorBicubic
|
|
|
|
- we shouldn't need to call im_invalidate() in gtkdisp4 :( how can we fix
|
|
this?
|
|
|
|
will im_invalidate() trash the render cache too?
|
|
|
|
- we should wrap the format API, also im_render*(), see gtkdisp.cc for sample
|
|
code
|
|
|
|
- have a base VObject class and put the ref stuff in there ... share between
|
|
VMask, VDisplay, VImage
|
|
|
|
- need an im_init_world() for C++ which does cmd-line args too, so C++ progs
|
|
can get --vips-progress and stuff automatically
|
|
|
|
- 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
|
|
|
|
- try
|
|
|
|
libsrc/convolution$ grep -l offsets *.c
|
|
|
|
could we do the don't calc offsets thing unless bpl; changes thing in more
|
|
places?
|
|
|
|
- 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
|
|
|
|
- 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?
|
|
|
|
- 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!
|
|
|
|
- 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
|