File: TODO

package info (click to toggle)
vips 8.7.4-1%2Bdeb10u1
  • links: PTS
  • area: main
  • in suites: buster
  • size: 32,536 kB
  • sloc: ansic: 110,472; cpp: 57,147; python: 6,038; sh: 5,000; xml: 4,047; makefile: 1,130; perl: 40
file content (439 lines) | stat: -rw-r--r-- 10,571 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
- try

	$ vips gaussmat x.mat 0.1 0.1
	(vips:28376): GLib-GObject-WARNING **: value "-1" of type 'gint' is invalid or out of range for property 'width' of type 'gint'
	(vips:28376): GLib-GObject-WARNING **: value "-1" of type 'gint' is invalid or out of range for property 'height' of type 'gint'
	$ more x.mat 
	1 1 0 0 
	5.55604e+180 

  check numeric range of SIGMA args, we should standardize

- rewind should break more things ... does it remove upsteam/downstream? does it
  just need to remove reorder links?

  perhaps reorder should use upstream/downstream, then it will be broken anyway

- not sure about utf8 error messages on win

- strange: 

	$ vips similarity --scale 0.33 k2.jpg x.v
	$ vipsheader k2.jpg 
	k2.jpg: 1450x2048 uchar, 3 bands, srgb, jpegload
	$ vipsheader x.v
	x.v: 478x676 uchar, 3 bands, srgb, jpegload

	1450 * 0.33 = 478.5 ... this was rounded down
	2048 * 0.33 = 675.84 ... this was rounded up

- add APPROX convsep test? 

- add more webp tests to py suite

- try moving some more of the CLI tests to py

- colour needs to split _build() into preprocess / process / postprocess
  phases

  in icc_import, for example, we want to check that the supplied profile is
  compatible with the input image as it will be when unpacked and ready for
  process_line 

  see vips_image_expected_bands() in icc_transform.c for the current hacky
  solution



- use the incremental webp decoding api to support seq for webp images

	https://developers.google.com/speed/webp/docs/api#decodingadvancedapi

  doesn't seem to be possible

- does ruby need to unpack RefString as well? what about C++?

- are the mosaic functions calling vips_fastcor()? it must be very slow

  add vips_fastcor_direct()

  nope .. it's im_chkpair.c:im_correl()
  	
	im_extract_area(main)
	im_extract_area(sub)
	im_extract_band(main)
	im_extract_band(sub)
	im_spcor(sub)
	im_maxpos(sub)

  then im__chkpair() runs that 20 times, then loops ... oh dear

- perhaps im_maxpos_subpel() / im_minpos_subpel() should be undeprecated,
  useful with vips_fastcor()



- why can't we do

	im = Vips.Image.new_from_file("/data/john/pics/k2.jpg", access = "sequential")

  no idea ... this works fine:

  	im.embed(10, 10, 100, 100, extend = "copy")

  test:

	op = Vips.Operation.new("embed")
	op.props.__setattr__("extend", "copy")
	op = Vips.Operation.new("jpegload")
	op.props.__setattr__("access", "sequential")

  first setattr works fine, second fails with invalid literal




- test other cpp arg types

	input int		works
	input double
	input enum		works
	input image		works
	input doublevec
	input imagevec
	input blob

	output int		
	output double		works
	output enum		
	output image		works
	output doublevec
	output imagevec
	output blob

  we probably need to unpack the ink back to double before blending



- ink to vec etc must have a way to give a complex constant

  eg. drawink needs a --ink_imag option with the imaginary components of the 
  ink

  look for uses of vips__vector_to_ink() and add extra params to other places
  too, eg. vips_embed(), vips_insert() etc. 

- vips__ink_to_vector() needs an optional imag return

- vips_getpoint() needs an optional imag return

- add porter-duff compositing, see

	https://github.com/jcupitt/ruby-vips/issues/28

- now vips_linear() has uchar output, can we do something with orc?

- do restrict on some more packages, we've just done arithmetic so far

	also resample, colour, some of conversion, create, 

- maybe avg?

  but avg doesn't subclass arithmetic, so we can't

- for interpolate, we'd need to be able to unroll the vector, so the
  interpolator would need to be built for the bands / stride / type of the
  image

  need new API For this since interpolators currently work for any image

- vips_gaussblur() should switch to float prec if given a float image?

  same for vips_conv()?

  maybe precision is a dumb thing

- support --strip for other writers

- vipsthumbnail could shrink-on-load openslide and pyr tiff as well?

  we have "shrink" for jpegload, move this into the base loader

  support it for tiff and openslide as well

  use it from nip2 for zooming? only if the partial flag is set though, we
  don't want to use it on jpg files



- 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

  not sure it works for order 2 either, we are seeing interpolation errors 
  on image edges


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


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
==========

- 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

- see

        http://www.dentistry.bham.ac.uk/landinig/software/cdeconv/cdeconv.html

	http://www.nature.com/srep/2015/150730/srep12096/full/srep12096.html

  sounds useful for BM?