MPSUnaryImageKernel(3)

NAME
MPSUnaryImageKernel -

SYNOPSIS

#import <MPSImageKernel.h>

Inherits MPSKernel.

Inherited by MPSImageAreaMax, MPSImageBox, MPSImageConversion, MPSImageConvolution, MPSImageDilate, MPSImageGaussianBlur, MPSImageHistogramEqualization, MPSImageHistogramSpecification, MPSImageIntegral, MPSImageIntegralOfSquares, MPSImageLanczosScale, MPSImageLaplacian, MPSImageMedian, MPSImagePyramid, MPSImageSobel, MPSImageThresholdBinary, MPSImageThresholdBinaryInverse, MPSImageThresholdToZero, MPSImageThresholdToZeroInverse, MPSImageThresholdTruncate, and MPSImageTranspose.

  Instance Methods
(BOOL) - encodeToCommandBuffer:inPlaceTexture:fallbackCopyAllocator:
(void) - encodeToCommandBuffer:sourceTexture:destinationTexture:
(MPSRegion) - sourceRegionForDestinationSize:

  Properties
MPSOffset offset
MTLRegion clipRect
MPSImageEdgeMode edgeMode

  Additional Inherited Members

Detailed Description

MPSImageKernel.h MetalPerformanceShaders.framework

Copyright:
    Copyright (c) 2015 Apple Inc. All rights reserved. MetalPerformanceShaders filter base classes

This depends on Metal.framework A MPSUnaryImageKernel consumes one MTLTexture and produces one MTLTexture.

Method Documentation

  - (BOOL) encodeToCommandBuffer: (nonnull id< MTLCommandBuffer >) commandBuffer(__nonnull id< MTLTexture > __strong *__nonnull) texture(encode(commandBuffer:inPlaceTexture:fallbackCopyAllocator:)) MPS_SWIFT_NAME
This method attempts to apply the MPSKernel in place on a texture.

    In-place operation means that the same texture is used both to hold the input
    image and the results. Operating in-place can be an excellent way to reduce
    resource utilization, and save time and energy. While simple Metal kernels can
    not operate in place because textures can not be readable and writable at the
    same time, some MPSKernels can operate in place because they use
    multi-pass algorithms. Whether a MPSKernel can operate in-place can
    depend on current hardware, operating system revision and the parameters
    and properties passed to it. You should never assume that a MPSKernel will
    continue to work in place, even if you have observed it doing so before.

If the operation succeeds in-place, YES is returned. If the in-place operation fails and no copyAllocator is provided, then NO is returned. Without a fallback MPSCopyAllocator, in neither case is the pointer held at *texture modified.

Failure during in-place operation is very common and will occur inconsistently across different hardware platforms and OS releases. Without a fallback MPSCopyAllocator, operating in place may require significant error handling code to accompany each call to -encodeToCommandBuffer:..., complicating your code.

You may find it simplifies your code to provide a fallback MPSCopyAllocator so that the operation can proceed reliably even when it can not proceed in-place. When an in-place filter fails, the MPSCopyAllocator (if any) will be invoked to create a new texture in which to write the results, allowing the filter to proceed reliably out-of-place. The original texture will be released, replaced with a pointer to the new texture and YES will be returned. If the allocator returns an invalid texture, it is released, *texture remains unmodified and NO is returned. Please see the MPSCopyAllocator definition for a sample allocator implementation.

Sample usage with a copy allocator:

id <MTLTexture> inPlaceTex = ...;
MPSImageSobel *sobelFiler = [[MPSImageSobel alloc] initWithDevice: my_device];
// With a fallback MPSCopyAllocator, failure should only occur in exceptional
// conditions such as MTLTexture allocation failure or programmer error.
// That is, the operation is roughly as robust as the MPSCopyAllocator.
// Depending on the quality of that, we might decide we are justified here
// in not checking the return value.
[sobelFilter encodeToCommandBuffer: my_command_buffer
                    inPlaceTexture: &inPlaceTex  // may be replaced!
             fallbackCopyAllocator: myAllocator];
// If myAllocator was not called:
//
//      inPlaceTex holds the original texture with the result pixels in it
//
// else,
//
//      1) myAllocator creates a new texture.
//      2) The new texture pixel data is overwritten by MPSUnaryImageKernel.
//      3) The old texture passed in *inPlaceTex is released once.
//      4) *inPlaceTex = the new texture
//
// In either case, the caller should now hold one reference to the texture now held in
// inPlaceTex, whether it was replaced or not. Most of the time that means that nothing
// further needs to be done here, and you can proceed to the next image encoding operation.
// However, if other agents held references to the original texture, they still hold them
// and may need to be alerted that the texture has been replaced so that they can retain
// the new texture and release the old one.
[sobelFilter release];  // if not ARC, clean up the MPSImageSobel object

Note: Image filters that look at neighboring pixel values may actually consume more memory when operating in place than out of place. Many such operations are tiled internally to save intermediate texture storage, but can not tile when operating in place. The memory savings for tiling is however very short term, typically the lifetime of the MTLCommandBuffer.

Attempt to apply a MPSKernel to a texture in place.

Parameters:
    commandBuffer A valid MTLCommandBuffer to receive the encoded filter
    texture A pointer to a valid MTLTexture containing source image. On success, the image contents and possibly texture itself will be replaced with the result image.
    copyAllocator An optional block to allocate a new texture to hold the results, in case in-place operation is not possible. The allocator may use a different MTLPixelFormat or size than the original texture. You may enqueue operations on the provided MTLCommandBuffer using the provided MTLComputeCommandEncoder to initialize the texture contents.

Returns:
    On success, YES is returned. The texture may have been replaced with a new texture if a copyAllocator was provided. On failure, NO is returned. The texture is unmodified.

  - (void) encodeToCommandBuffer: (nonnull id< MTLCommandBuffer >) commandBuffer(nonnull id< MTLTexture >) sourceTexture(encode(commandBuffer:sourceTexture:destinationTexture:)) MPS_SWIFT_NAME
Encode a MPSKernel into a command Buffer. The operation shall proceed out-of-place.

Parameters:
    commandBuffer A valid MTLCommandBuffer to receive the encoded filter
    sourceTexture A valid MTLTexture containing the source image.
    destinationTexture A valid MTLTexture to be overwritten by result image. DestinationTexture may not alias sourceTexture.

  - (MPSRegion) sourceRegionForDestinationSize: (sourceRegion(destinationSize:)) MPS_SWIFT_NAME
sourceRegionForDestinationSize: is used to determine which region of the sourceTexture will be read by encodeToCommandBuffer:sourceTexture:destinationTexture (and similar) when the filter runs. This information may be needed if the source image is broken into multiple textures. The size of the full (untiled) destination image is provided. The region of the full (untiled) source image that will be read is returned. You can then piece together an appropriate texture containing that information for use in your tiled context.

The function will consult the MPSUnaryImageKernel offset and clipRect parameters, to determine the full region read by the function. Other parameters such as sourceClipRect, kernelHeight and kernelWidth will be consulted as necessary. All properties should be set to intended values prior to calling sourceRegionForDestinationSize:.

Caution: This function operates using global image coordinates, but
-encodeToCommandBuffer:... uses coordinates local to the source and
destination image textures. Consequently, the offset and clipRect
attached to this object will need to be updated using a global to
local coordinate transform before -encodeToCommandBuffer:... is
called.

Determine the region of the source texture that will be read for a encode operation

Parameters:
    destinationSize The size of the full virtual destination image.

Returns:
    The area in the virtual source image that will be read.

Property Documentation

  - clipRect [read], [write], [nonatomic], [assign]
An optional clip rectangle to use when writing data. Only the pixels in the rectangle will be overwritten. A MTLRegion that indicates which part of the destination to overwrite. If the clipRect does not lie completely within the destination image, the intersection between clip rectangle and destination bounds is used. Default: MPSRectNoClip (MPSKernel::MPSRectNoClip) indicating the entire image.

See Also: MPSKernel clipRect

  - edgeMode [read], [write], [nonatomic], [assign]
The MPSImageEdgeMode to use when texture reads stray off the edge of an image Most MPSKernel objects can read off the edge of the source image. This can happen because of a negative offset property, because the offset + clipRect.size is larger than the source image or because the filter looks at neighboring pixels, such as a Convolution or morphology filter. Default: usually MPSImageEdgeModeZero. (Some MPSKernel types default to MPSImageEdgeModeClamp, because MPSImageEdgeModeZero is either not supported or would produce unexpected results.)

See Also: MPSKernelEdgeMode

  - offset [read], [write], [nonatomic], [assign]
The position of the destination clip rectangle origin relative to the source buffer. The offset is defined to be the position of clipRect.origin in source coordinates. Default: {0,0,0}, indicating that the top left corners of the clipRect and source image align.

See Also: subsubsection_mpsoffset

Author

Generated automatically by Doxygen for MetalPerformanceShaders.framework from the source code.