revise TODO
This commit is contained in:
John Cupitt
parent
57b6622690
commit
aaa418ee22
106
TODO
106
TODO
@ -1,8 +1,33 @@
|
||||
Blocking
|
||||
========
|
||||
|
||||
- is vips_hist_local() correct? it seems to leave white dots everywhere
|
||||
on the sarto_ng test image
|
||||
|
||||
try a 1x1 window, it be identity operation, I think
|
||||
|
||||
- could VipsConversion now have an @in member?
|
||||
|
||||
we've moved all the no-input ones of to create now, I think
|
||||
|
||||
we several many-input ones though, eg. bandary
|
||||
|
||||
- why is memuse so high?
|
||||
|
||||
$ vips shrink wtc.png x.v 230 230
|
||||
memory: high-water mark 322.13 MB
|
||||
|
||||
because we have so many threads on the work machine, try:
|
||||
|
||||
$ vips shrink wtc.png x.v 230 230 --vips-concurrency=1
|
||||
memory: high-water mark 45.46 MB
|
||||
|
||||
- check speed and memuse test, are we really 10mb? have a note that memuse can
|
||||
be much higher
|
||||
|
||||
Next version
|
||||
============
|
||||
|
||||
- do conv and morph quickly as simple wrappers over the vips7 operations
|
||||
|
||||
- do much fancier profiling with timing on all locks saved in memory and
|
||||
@ -11,8 +36,6 @@
|
||||
- use the webp advanced encoding api to set a write function for webp save to
|
||||
file
|
||||
|
||||
- is vips_hist_local() correct? it seems to leave white dots everywhere
|
||||
|
||||
- use g_log() instead of vips_info()
|
||||
|
||||
- do we always call copy_fields and demand_hint with ALL input images? what
|
||||
@ -25,10 +48,6 @@
|
||||
|
||||
https://github.com/jcupitt/ruby-vips/issues/41
|
||||
|
||||
- could VipsConversion now have an @in member?
|
||||
|
||||
we've moved all the no-input ones of to create now, I think
|
||||
|
||||
- object construction is threadsafe, but class construction is not
|
||||
|
||||
https://github.com/jcupitt/libvips/issues/64
|
||||
@ -43,19 +62,6 @@
|
||||
|
||||
|
||||
|
||||
- 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
|
||||
|
||||
- quadratic doesn't work for order 3
|
||||
|
||||
start to get jaggies on lines --- the 3rd differential isn't being
|
||||
@ -65,9 +71,6 @@
|
||||
|
||||
because we step across tiles left to right: y doesn't change, only x does
|
||||
|
||||
- test with interpolators, do we add margins correctly?
|
||||
|
||||
|
||||
|
||||
|
||||
- the operation cache needs to detect invalidate
|
||||
@ -81,24 +84,6 @@
|
||||
|
||||
need to add an "invalidate" signal to operation
|
||||
|
||||
- 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?
|
||||
|
||||
|
||||
|
||||
blocking bugs
|
||||
=============
|
||||
|
||||
- none!
|
||||
|
||||
|
||||
mosaic
|
||||
======
|
||||
|
||||
@ -141,8 +126,6 @@ foreign
|
||||
|
||||
http://niftilib.sourceforge.net/
|
||||
|
||||
- support planar tiff
|
||||
|
||||
- add matlab write
|
||||
|
||||
- im_exr2vips can now use c++ api
|
||||
@ -190,7 +173,6 @@ convolution
|
||||
wait for vipsobject for this
|
||||
|
||||
|
||||
|
||||
arithmetic
|
||||
==========
|
||||
|
||||
@ -198,13 +180,6 @@ arithmetic
|
||||
|
||||
how about ifthenelse?
|
||||
|
||||
- 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?
|
||||
|
||||
- HAVE_HYPOT could define a hypot() macro?
|
||||
|
||||
- fix a better NaN policy
|
||||
@ -217,10 +192,6 @@ arithmetic
|
||||
iofuncs
|
||||
=======
|
||||
|
||||
- we have VipsArrayObject and also vips_object_local_array()
|
||||
|
||||
can we make one use the other?
|
||||
|
||||
- need vips_image_invalidate_area()
|
||||
|
||||
- look at libpeas for plugin support
|
||||
@ -314,10 +285,6 @@ libvipsCC
|
||||
tools
|
||||
=====
|
||||
|
||||
- could spot "copy" and turn on seq mode automatically?
|
||||
|
||||
perhaps there should be something on operations to indicate seq-ability
|
||||
|
||||
- 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
|
||||
@ -350,3 +317,26 @@ new operations
|
||||
- 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?
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user