@@ -29,7 +29,7 @@ Reading this example line by line, we have::
29
29
30
30
image = pyvips.Image.new_from_file('some-image.jpg', access='sequential')
31
31
32
- :meth: `.new_from_file ` can load any image file supported by libvips. In
32
+ :meth: `.Image. new_from_file ` can load any image file supported by libvips. In
33
33
this example, we will be accessing pixels top-to-bottom as we sweep through
34
34
the image reading and writing, so `sequential ` access mode is best for us.
35
35
120
120
NumPy and PIL
121
121
-------------
122
122
123
- You can use :meth: `.write_to_memory ` and :meth: `.new_from_memory ` to pass
123
+ You can use :meth: `.write_to_memory ` and :meth: `.Image. new_from_memory ` to pass
124
124
buffers of pixels between PIL, NumPy and pyvips. For example::
125
125
126
126
import pyvips
@@ -276,18 +276,6 @@ Add these lines somewhere near the start of your program::
276
276
logging.basicConfig(level=logging.WARNING)
277
277
278
278
279
- Automatic documentation
280
- -----------------------
281
-
282
- The bulk of these API docs are generated automatically by
283
- :meth: `.Operation.generate_sphinx_all `. It examines libvips and writes a
284
- summary of each operation and the arguments and options that that operation
285
- expects.
286
-
287
- Use the C API docs for more detail:
288
-
289
- https://libvips.github.io/libvips/API/current
290
-
291
279
Exceptions
292
280
----------
293
281
@@ -301,23 +289,6 @@ The libvips enums, such as ``VipsBandFormat``, appear in pyvips as strings
301
289
like ``'uchar' ``. They are documented as a set of classes for convenience, see
302
290
:class: `.Access `, for example.
303
291
304
- Draw operations
305
- ---------------
306
-
307
- Paint operations like :meth: `.Image.draw_circle ` and
308
- :meth: `.Image.draw_line ` modify their input image. This makes them
309
- hard to use with the rest of libvips: you need to be very careful about
310
- the order in which operations execute or you can get nasty crashes.
311
-
312
- The wrapper spots operations of this type and makes a private copy of the
313
- image in memory before calling the operation. This stops crashes, but it does
314
- make it inefficient. If you draw 100 lines on an image, for example, you'll
315
- copy the image 100 times. The wrapper does make sure that memory is recycled
316
- where possible, so you won't have 100 copies in memory.
317
-
318
- If you want to avoid the copies, you'll need to call drawing operations
319
- yourself.
320
-
321
292
Overloads
322
293
---------
323
294
@@ -348,3 +319,105 @@ The wrapper defines a few extra useful utility functions:
348
319
:meth: `.bandsplit `, :meth: `.maxpos `, :meth: `.minpos `,
349
320
:meth: `.median `.
350
321
322
+ Tracking and interrupting computation
323
+ -------------------------------------
324
+
325
+ You can attach progress handlers to images to watch the progress of
326
+ computation.
327
+
328
+ For example::
329
+
330
+ image = pyvips.Image.black(1, 500)
331
+ image.set_progress(True)
332
+ image.signal_connect('preeval', preeval_handler)
333
+ image.signal_connect('eval', eval_handler)
334
+ image.signal_connect('posteval', posteval_handler)
335
+ image.avg()
336
+
337
+ Handlers are given a `progress ` object containing a number of useful fields.
338
+ For example::
339
+
340
+ def eval_handler(image, progress):
341
+ print('run time so far (secs) = {}'.format(progress.run))
342
+ print('estimated time of arrival (secs) = {}'.format(progress.eta))
343
+ print('total number of pels to process = {}'.format(progress.tpels))
344
+ print('number of pels processed so far = {}'.format(progress.npels))
345
+ print('percent complete = {}'.format(progress.percent))
346
+
347
+ Use :meth: `.Image.set_kill ` on the image to stop computation early.
348
+
349
+ For example::
350
+
351
+ def eval_handler(image, progress):
352
+ if progress.percent > 50:
353
+ image.set_kill(True)
354
+
355
+ Custom sources and targets
356
+ --------------------------
357
+
358
+ You can load and save images to and from :class: `.Source ` and
359
+ :class: `.Target `.
360
+
361
+ For example::
362
+
363
+ source = pyvips.Source.new_from_file("some/file/name")
364
+ image = pyvips.Image.new_from_source(source, "", access="sequential")
365
+ target = pyvips.Target.new_to_file("some/file/name")
366
+ image.write_to_target(target, ".png")
367
+
368
+ Sources and targets can be files, descriptors (eg. pipes) and areas of memory.
369
+
370
+ You can define :class: `.SourceCustom ` and :class: `.TargetCustom ` too.
371
+
372
+ For example::
373
+
374
+ input_file = open(sys.argv[1], "rb")
375
+
376
+ def read_handler(size):
377
+ return input_file.read(size)
378
+
379
+ source = pyvips.SourceCustom()
380
+ source.on_read(read_handler)
381
+
382
+ output_file = open(sys.argv[2], "wb")
383
+
384
+ def write_handler(chunk):
385
+ return output_file.write(chunk)
386
+
387
+ target = pyvips.TargetCustom()
388
+ target.on_write(write_handler)
389
+
390
+ image = pyvips.Image.new_from_source(source, '', access='sequential')
391
+ image.write_to_target(target, '.png')
392
+
393
+ You can also define seek and finish handlers, see the docs.
394
+
395
+ Automatic documentation
396
+ -----------------------
397
+
398
+ The bulk of these API docs are generated automatically by
399
+ :meth: `.Operation.generate_sphinx_all `. It examines libvips and writes a
400
+ summary of each operation and the arguments and options that that operation
401
+ expects.
402
+
403
+ Use the C API docs for more detail:
404
+
405
+ https://libvips.github.io/libvips/API/current
406
+
407
+ Draw operations
408
+ ---------------
409
+
410
+ Paint operations like :meth: `.Image.draw_circle ` and
411
+ :meth: `.Image.draw_line ` modify their input image. This makes them
412
+ hard to use with the rest of libvips: you need to be very careful about
413
+ the order in which operations execute or you can get nasty crashes.
414
+
415
+ The wrapper spots operations of this type and makes a private copy of the
416
+ image in memory before calling the operation. This stops crashes, but it does
417
+ make it inefficient. If you draw 100 lines on an image, for example, you'll
418
+ copy the image 100 times. The wrapper does make sure that memory is recycled
419
+ where possible, so you won't have 100 copies in memory.
420
+
421
+ If you want to avoid the copies, you'll need to call drawing operations
422
+ yourself.
423
+
0 commit comments