643dc28950
cli operations turn on seq mode automatically when they can vips_operation_get_flags() added: lets you attach a set of flags to an operation flags for now are "nocache" (replacing the old nocache system) and "seqential" if vips_object_set_argument_from_string() from string sees "seq" flag on the object for which it is setting the arg, it enables sequential mode all operations which can run sequentially have been tagged the operation printer knows about flags and can display them
300 lines
6.5 KiB
Plaintext
300 lines
6.5 KiB
Plaintext
- test "rs" mode
|
|
|
|
can't see the code for "rd" mode?
|
|
|
|
or "rw" mode either?
|
|
|
|
|
|
|
|
- need a flag on operations for "is sequential"
|
|
|
|
should be on the object, not the class, since it can change with params
|
|
|
|
use it from command-line interface
|
|
|
|
not really helpful elsewhere, since two operations which are sequential
|
|
alone can be non-sequential in combination -- eg. shrink + conv
|
|
|
|
can you always make sequential-apart, non-seq together pipelines seqential
|
|
by putting a line cache between each pair?
|
|
|
|
- update "how it works" to note we are now fully-functional ... there's
|
|
vips_image_write() now to create a sink
|
|
|
|
- im_jpeg2vips() etc, currently use vips_call() and therefore have an extra
|
|
_write() ... this means that
|
|
|
|
vips im_jpeg2vips huge.jpg x.v
|
|
|
|
decompresses to disc, then vips_copy()s to x.v
|
|
|
|
instead, they could be built on top of VipsFormat and use the compat layer
|
|
there
|
|
|
|
check nip2: is it really only decompressing large images once?
|
|
|
|
blocking bugs
|
|
=============
|
|
|
|
- none!
|
|
|
|
|
|
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/
|
|
|
|
- support planar tiff
|
|
|
|
- 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
|
|
|
|
|
|
colour
|
|
======
|
|
|
|
- lab [100,0,0] -> srgb [255, 255, 254]? how odd
|
|
|
|
- use D65 in cmsCreateLab4Profile() ? not sure
|
|
|
|
|
|
arithmetic
|
|
==========
|
|
|
|
- avg/dev etc. should uncode images? eg. labq2lab etc.
|
|
|
|
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
|
|
|
|
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
|
|
=======
|
|
|
|
- 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
|
|
|
|
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
|
|
=====
|
|
|
|
- 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
|
|
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
|
|
|