sergiotarxz/libvips
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
e0b9b3cd5c
libvips/TODO
John Cupitt e0b9b3cd5c more polishing 
and instrument stuff for vipsthumbnail
2013-11-28 14:56:19 +00:00

449 lines
10 KiB
Plaintext
Raw Blame History

- try disabling turbo-boost?
see http://blog.tube42.se/?p=1225
for i in {0..11}; do sudo cpufreq-set -f 1600000 -c $i; done
-r doesn't seem to work
verify with
cpufreq-info | more
with cpu locked at 1.6 GHz
$ time vips sharpen k2.v x.v --radius 20 --vips-concurrency=1
real 0m2.232s
user 0m2.212s
sys 0m0.036s
$ time vips sharpen k2.v x.v --radius 20 --vips-concurrency=2
real 0m1.295s
user 0m2.448s
sys 0m0.060s
$ time vips sharpen k2.jpg x.jpg --radius 20 --vips-concurrency=1
real 0m2.760s
user 0m2.768s
sys 0m0.024s
$ time vips sharpen k2.jpg x.jpg --radius 20 --vips-concurrency=2
real 0m1.558s
user 0m2.988s
sys 0m0.060s
git master, -o2, --enable-debug=no
$ time vips sharpen k2.jpg x.jpg --radius 20 --vips-concurrency=1
real 0m1.404s
user 0m1.419s
sys 0m0.023s
$ time vips sharpen k2.jpg x.jpg --radius 20 --vips-concurrency=2
real 0m0.870s
user 0m1.659s
sys 0m0.036s
$ time vips sharpen k2.jpg x.jpg --radius 20
real 0m0.760s
user 0m2.726s
sys 0m0.069s
two cores gets a 1.404 / 0.870 = 1.61x speedup
turbo-boost is 20%, so if 1 core were 20% slower, it'd be 1.685
1.685 / 0.870 = 1.94x speedup
(check this, use MHz in tubo and non-turbo)
for four threads, we add 2.726 - 1.659 = 1.067 cpu but only get another 15%
off the wall-clock time
john@bambam ~/pics $ time vips sharpen k2.jpg x.jpg --radius 20 --vips-profile
recording profile in vips-profile.txt
real 0m0.758s
user 0m2.768s
sys 0m0.032s
john@bambam ~/pics $ vipsprofile
reading from vips-profile.txt
loaded 5885 events
last time = 0.710619
name alive wait% work% unk%
worker (0x7f66000008c0) 0 0.0003 67.7 0 32.3
worker (0x7f66100008c0) 1 0.00037 37.2 0 62.8
worker (0x7f66080008c0) 2 0.00032 93.5 0 6.54
worker (0x7f660c0008c0) 3 0.00033 86.8 0 13.2
worker (0x7f66080008c0) 4 0.00023 63.8 0 36.2
worker (0x7f661000a360) 5 0.00024 96.7 0 3.33
worker (0x7f660c0008c0) 6 0.00042 78.1 0 21.9
worker (0x7f66000012d0) 7 0.00025 85 0 15
worker (0x7f660c011450) 8 0.0001 30.7 0 69.3
worker (0x7f661000a360) 9 0.00011 89.7 0 10.3
worker (0x7f6608011850) 10 0.00012 93.2 0 6.78
worker (0x7f66000012d0) 11 0.00023 14.1 8.55 77.4
worker (0x7f661000a360) 12 0.00013 47.2 0 52.8
worker (0x7f6608011850) 13 0.00011 91.2 0 8.77
worker (0x7f660c011430) 14 0.00015 12.9 0 87.1
worker (0x7f6600009fa0) 15 0.00019 45.7 0 54.3
worker (0x7f660c011450) 16 0.00011 90.4 0 9.65
worker (0x7f6600009f80) 17 0.00017 5.81 4.65 89.5
worker (0x7f661000a1f0) 18 0.00013 93.6 0 6.4
worker (0x7f6608011850) 19 0.00011 35.8 0 64.2
worker (0x7f65fc0008c0) 20 0.69 0.453 95.7 3.83
worker (0x7f65f80008c0) 21 0.69 0.333 96.9 2.75
worker (0x7f660c011450) 22 0.69 0.288 97.1 2.57
worker (0x7f661000a1f0) 23 0.69 0.127 97.2 2.63
wbuffer (0x7f66000011c0) 24 0.7 98 0 1.98
wbuffer (0x7f660800fcd0) 25 0.7 97.7 0 2.32
main (0x1e7e200) 26 0.74 93.7 0 6.31
writing to vips-profile.svg
- seen some leaks from
vips dzsave --layout google wtc.jpg x
investigate
- vips_gaussblur() should switch to float prec if given a float image?
same for vips_conv()?
maybe precision is a dumb thing
- do morph quickly as simple wrappers over the vips7 operations
- support --strip for other writers
- vipsthumbnail could shrink-on-load openslide and pyr tiff as well?
- look again at gcc auto-vectorisation, what would we need to do to use this?
- how about
top -d 0.01 | grep vips > log
to watch RES at 0.01s intervals?
note on memuse page
- use the webp advanced encoding api to set a write function for webp save to
file
- use g_log() instead of vips_info()
- object construction is threadsafe, but class construction is not
https://github.com/jcupitt/libvips/issues/64
we worked around this by adding vips_class_ping_all() to dsave build, but
this is not a good fix
find out why vips class construct fails, test on seurat, kirk's 24-core
monster
- quadratic doesn't work for order 3
start to get jaggies on lines --- the 3rd differential isn't being
initialised correctly for the sub-region?
seems fine vertically, only get errors on horizontal tile boundaries
because we step across tiles left to right: y doesn't change, only x does
- the operation cache needs to detect invalidate
tricky!
perhaps have operations always watching all of their inputs and resignalling
"invalidate" themselves
cache then just needs to watch for "invalidate" on operations it tracks
need to add an "invalidate" signal to operation
mosaic
======
- balance should use new meta stuff
- histogram balance option?
resample
========
- check mosaic1, global_balance, similarity etc. use of im__affine
how can we move them to im_affinei ?
- perspective transform with a matrix ... base it on the Lenz transformer, but
partial
foreign
=======
- magick2vips should spot ICC profiles and attach them as meta
- interlaced jpg needs massive memory, we should have two jpg read modes, like
png
- add more sequential mode readers
$ grep -l write_line *.c
csv.c
matlab.c
openexr2vips.c
ppm.c
radiance.c
- foreign docs come up as "VipsForeignSave", annoying, why?
- add nifti support
http://niftilib.sourceforge.net/
- add matlab write
- im_exr2vips can now use c++ api
see TODO notes in openexr read (though they all need more openexr C API)
consider openexr write
- 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
packaging
=========
- test _O_TEMPORARY thing on Windows
- do we bundle "convert" in the OS X / win32 builds? if we don't we
should
convolution
===========
- 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
- 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
- we have aconv and aconvsep
test timing, make sure it;s worth having a separate aconvsep version
if it is, make im_aconvsep an optimisation: call im_aconvsep_raw() from
vips_conv() if mask width or height == 1 and prec == APPROX
now we can get rid of im_aconvsep() since it's just vips_convsep() with prec
set to approx
aconv needs some more work, get it going at least with gaussian
arithmetic
==========
- avg/dev etc. should uncode images? eg. labq2lab etc.
how about ifthenelse?
- HAVE_HYPOT could define a hypot() macro?
- fix a better NaN policy
should we not generate images containing NaN (eg. divide tries to avoid /0),
or should vips_max() etc. try to avoid NaN in images (eg. vips_max() takes a
lot a care to skip NaN, though vips_stats() does not)?
iofuncs
=======
- need vips_image_invalidate_area()
- look at libpeas for plugin support
http://live.gnome.org/Libpeas
- 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
perhaps use curly brackets for code?
vips max add{babe.jpg,babe2.jpg}
no brackets or square brackets for options
- 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
- note member free stuff in vipsobject docs
should boxed get freed in finalise rather than dispose?
vipsobject has few docs atm :(
- vips_object_set_argument_from_string() needs more arg types
must be some way to make this more automatic
- generate the code for vips_add() etc. automatically? it might be
nice to have them all in one place at least
- what does G_UNLIKELY() do? can we use it?
- look into G_GNUC_DEPRECATED for back compat in vips8
- 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
swig
====
- swig is not wrapping im_project() correctly ... returns an extra VImage via
a param
- doc strings would be nice, read the SWIG notes on this
new bindings
============
- new binding is still missing constants
how do boxed types work? confusing
we need to be able to make a VipsArrayDouble
- Vips.Image has members like chain, __subclasshook__ etc etc, are we
really subclassing it correctly?
- add __add__ etc overloads
freq_filt
=========
- fft with odd width or height is broken ... DC ends up in the wrong place
libvipsCC
=========
- need new C++ API
- need an im_init_world() for C++ which does cmd-line args too, so C++ progs
can get --vips-progress and stuff automatically
tools
=====
- 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
- rename header, edvips as vipsheader, vipsedit
maybe have back compat links?
new operations
==============
- 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
- http://en.wikipedia.org/wiki/Otsu%27s_method
- non-linear sharpen: replace each pixel by the lightest or darkest neighbour
depending on which is closer in value
- look at
There is an order 1 algorithm for doing medians over boxes (truly O(1)
per pixel: I checked it carefully; it's like doing means over boxes in
order 1 per pixel) in OpenCV since February 2012 I think, due to
Perreault (and Hebert).
It appears to be well respected, at least for 8-bit medians. Very
memory intensive. Simple and elegant. No clue if it fits VIPS well
(probably not?).
Article: nomis80.org/ctmf.pdf
- check CMC equations against web
http://en.wikipedia.org/wiki/Color_difference#CMC_l:c_.281984.29
- see
http://www.dentistry.bham.ac.uk/landinig/software/cdeconv/cdeconv.html
sounds useful for BM?
Reference in New Issue View Git Blame Copy Permalink