Next: 4. Function dispatch and Up: 3.8 Joining operations together Previous: 3.8.5 Blocking computation Contents

##
3.8.6 Limitations

Not all VIPS operations are partial-aware. These non-partial operations use a pre-VIPS7.0 I/O scheme in which the whole of the input image has to be present at the same time. In some cases, this is because partial I/O simply makes no sense -- for example, a Fourier Transform can produce no output until it has seen all of the input. `im_fwfft()` is therefore not a partial operation. In other cases, we have simply not got around to rewriting the old non-partial operation in the newer partial style.

You can mix partial and non-partial VIPS operations freely, without worrying about which type they are. The only effect will be on the time your pipeline takes to execute, and the memory requirements of the intermediate images. VIPS uses the following rules when you mix the two styles of operation:

1. When a non-partial operation is asked to output to a partial image descriptor, the `"p"` descriptor is magically transformed into a `"t"` descriptor.

2. When a non-partial operation is asked to read from a `"p"` descriptor, the `"p"` descriptor is turned into a `"t"` type, and any earlier stages in the pipeline forced to evaluate into that memory buffer.

   The non-partial operation then processes from the memory buffer.

These rules have the consequence that you may only process very large images if you only use partial operations. If you use any non-partial operations, then parts of your pipelines will fall back to old whole-image I/O and you will need to think carefully about where your intermediates should be stored.

Next: 4. Function dispatch and Up: 3.8 Joining operations together Previous: 3.8.5 Blocking computation Contents