libvips/TODO
2008-05-27 17:15:04 +00:00

136 lines
3.8 KiB
Plaintext

- try
libsrc/convolution$ grep -l offsets *.c
could we do the don't calc offsets thing unless bpl; changes thing in more
places?
- docs include figures twice! yuk
fixed? not sure, check again
- unsharp should work on GREY16? shuld 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
- 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
- see TODO notes in openexr read (though they all need more openexr C API)
consider openexr write
- 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