Grayscale Dilation

Morphological dilation of grayscale pixel data

• 

Libraries:
Vision HDL Toolbox / Morphological Operations

Description

The Grayscale Dilation block performs morphological dilation on a stream of pixel intensity values. You can specify a neighborhood or structuring element of up to 32-by-32 pixels. For line, square, or rectangle structuring elements more than 8 pixels wide, the block uses the Van Herk algorithm to find the maximum pixel value. This algorithm uses only three comparators to find the maximums of all the rows, and then uses a comparison tree to find the maximum pixel value of the row results.

For structuring elements less than 8 pixels wide, or that contain zero elements, the block implements a pipelined comparison tree for each row of the neighborhood. An additional comparison tree finds the maximum pixel value of the row results. If the structuring element contains zeros that exclude pixels, the algorithm saves hardware resources by not implementing comparators for those pixel locations.

Ports

This block uses a streaming pixel interface with a bus for frame control signals. This interface enables the block to operate independently of image size and format. The pixel ports on this block support single pixel streaming or multipixel streaming. Single pixel streaming accepts and returns a single pixel value each clock cycle. Multipixel streaming accepts and returns a vector of M pixels per clock cycle to support high-frame-rate or high-resolution formats. The M value corresponds to the Number of pixels parameter of the Frame To Pixels block. Along with the pixel, the block accepts and returns a pixelcontrol bus that contains five control signals. The control signals indicate the validity of each pixel and their location in the frame. For multipixel streaming, one set of control signals applies to all pixels in the vector. To convert a frame (pixel matrix) into a serial pixel stream and control signals, use the Frame To Pixels block. For a full description of the interface, see Streaming Pixel Interface.

Input

pixel — Input pixel stream

scalar | vector

For single pixel streaming, specify pixel as an unsigned scalar value that represents grayscale intensity. For multipixel streaming, specify pixel as a column vector of Number of pixels pixel intensity values. Number of pixels can be two, four, or eight.

The software supports double and single data types for simulation, but not for HDL code generation.

Data Types: uint8 | uint16 | uint32 | uint64 | double | single | fi(0,N,0)

ctrl — Control signals associated with pixel stream

pixelcontrol bus

The pixelcontrol bus contains five signals. The signals describe the validity of the pixel and its location in the frame. For more information, see Pixel Control Bus.

For multipixel streaming, each vector of pixel values has one set of control signals. Because the vector has only one valid signal, the pixels in the vector must be either all valid or all invalid. The hStart and vStart signals apply to the pixel with the lowest index in the vector. The hEnd and vEnd signals apply to the pixel with the highest index in the vector.

Data Types: bus

Output

pixel — Output pixel stream

scalar | vector

The dimensions of the output pixel match the dimensions of the input pixel. The block returns the output pixel as a scalar or a column vector of Number of pixels values.

The data type of this output pixel is the same as the data type of the input pixel.

ctrl — Control signals associated with pixel stream

pixelcontrol bus

The pixelcontrol bus contains five signals. The signals describe the validity of the pixel and its location in the frame. For more information, see Pixel Control Bus.

For multipixel streaming, each vector of pixel values has one set of control signals. Because the vector has only one valid signal, the pixels in the vector must be either all valid or all invalid. The hStart and vStart signals apply to the pixel with the lowest index in the vector. The hEnd and vEnd signals apply to the pixel with the highest index in the vector.

Data Types: bus

Parameters

Neighborhood — Pixel neighborhood

ones(3,3) (default) | vector or matrix of 1s and 0s

Pixel neighborhood, specified as a vector or matrix of binary values.

The block supports flat neighborhoods of up to 32-by-32 pixels. To use a structuring element, set the Neighborhood parameter to getnhood (Image Processing Toolbox)(strel (Image Processing Toolbox)(shape)), where shape is specified by the input arguments to the strel (Image Processing Toolbox) function. The minimum neighborhood size is a 2-by-2 matrix, or a 2-by-1 column vector. If the neighborhood is a row vector, it must be at least 8 columns wide and contain no zeros.

Line buffer size — Size of line memory buffer

2048 (default) | positive integer

Size of the line memory buffer, specified as a positive integer. Choose a power of two that accommodates the number of active pixels in a horizontal line. If you specify a value that is not a power of two, the buffer uses the next largest power of two.

When you use multipixel input, this value must accommodate (Active pixels per line)/(Number of pixels) + 2.

The block allocates (n – 1)-by-Line buffer size memory locations to store the pixels, where n is the number of lines in the Neighborhood parameter value.

Tips

• When you use a block with an internal line buffer inside an Enabled Subsystem (Simulink), the enable signal pattern must maintain the timing of the pixel stream, including the minimum blanking intervals. If the enable pattern corrupts the timing of the pixel stream, you might see partial output frames, corrupted pixel stream control signals, or mismatches between Simulink^® and HDL simulation results. You may need to extend the blanking intervals to accommodate for cycles when the enable is low. For more information, see Configure Blanking Intervals.

Algorithms

The block pads the image with zeros for the dilation operation. For more information, see Edge Padding.

Van Herk Implementation

For line, square, or rectangle structuring elements more than 8 pixels wide, the block implements a Van Herk algorithm. All pixels in the structuring element must be set to one. The block decomposes the structuring element into rows and serially finds the maximum pixel value in each row by using the Van Herk algorithm. If the size of the input frame is not a multiple of m pixels, the line memory also adds horizontal padding to a multiple of m. This implementation uses only three comparators total for all rows. Then, if there is more than one row, it calculates the maximum pixel value of the row results by using a comparison tree. The diagram indicates the latency of each computation block.

The Van Herk kernel computes a running forward maximum and a running backward maximum of the pixel values in each row of the neighborhood. For this computation, the pixels in the row must be buffered and the order reversed. The buffer adds latency relative to the comparison tree implementation. The Mirror Buffer is a ping-pong RAM of m pixels, where one memory reads values in reverse order while the other memory is writing. The kernel uses 3+n-1 comparators.

Comparison Tree Implementation

For structuring elements smaller than 8 pixels wide or with one or more pixels set to zero, the block implements a comparison tree.

The diagram shows the architecture of the dilation operation. The algorithm finds the maximum pixel value of each row of the neighborhood in parallel. Then it calculates the maximum pixel value of the rows using another comparison tree. The diagram indicates the latency of each computation block.

For a rectangular neighborhood that is m pixels wide, the first-stage comparison trees contain m – 1 comparators over log₂(m) clock cycles. For instance, for a rectangular neighborhood that is 7 pixels wide, the comparison tree has six comparators over 3 clock cycles.

If the neighborhood that you specify contains zeroes, the generated HDL excludes the comparator for the zero locations. The pipeline delay through the comparison tree does not change. For instance, for a nonrectangular neighborhood with a row of [0 0 1 1 0 0 1], the comparison tree for that row contains two comparators and still uses 3 clock cycles.

Latency

The latency of the operation is the line buffer latency plus the latency of the kernel calculation. The line buffer latency includes edge padding.

The latency of a Van Herk kernel for a neighborhood of m-by-n pixels is 2m + log₂(n). The block implements this kernel for line, square, or rectangle structuring elements more than 8 pixels wide, with no pixels set to zero.

The latency of a comparison tree kernel for a neighborhood of m-by-n pixels is log₂(m)+log₂(n). The block implements this kernel for structuring elements smaller than 8 pixels wide or with one or more pixels set to zero.

Note

When you use edge padding, use a horizontal blanking interval of at least twice the kernel width. This interval lets the block finish processing one line before it starts processing the next one, including adding padding pixels before and after the active pixels in the line.

The horizontal blanking interval is equal to TotalPixelsPerLine – ActivePixelsPerLine or, equivalently, FrontPorch + BackPorch. Standard streaming video formats use a horizontal blanking interval of about 25% of the frame width. This interval is much larger than the filters applied to each frame.

The horizontal blanking interval must also meet these minimums:

• If the kernel size is less than 4, and you use edge padding, the total porch must be at least 8 pixels.

• When you disable edge padding, the horizontal blanking interval must be at least 12 cycles and is independent of the kernel size.

• The BackPorch must be at least 6 pixels. This parameter is the number of inactive pixels before the first valid pixel in a frame.

For more information, see Configure Blanking Intervals.

Performance

This table shows the resource use after synthesis of the block for the Xilinx^® Zynq^®-7000 SoC ZC706 Evaluation Kit with single-pixel uint8 input and the default parameter settings. The design achieves a clock frequency of 309 MHz.

Resource	Usage
Slice LUTs	436
Slice Registers	771
DSP48	0
Block RAM	1

Extended Capabilities

C/C++ Code Generation

Generate C and C++ code using Simulink® Coder™.

This block supports C/C++ code generation for Simulink accelerator and rapid accelerator modes and for DPI component generation.

HDL Code Generation

Generate VHDL, Verilog and SystemVerilog code for FPGA and ASIC designs using HDL Coder™.

HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.

HDL Architecture

This block has one default HDL architecture.

HDL Block Properties

ConstrainedOutputPipeline	Number of registers to place at the outputs by moving existing delays within your design. Distributed pipelining does not redistribute these registers. The default is 0. For more details, see ConstrainedOutputPipeline (HDL Coder).
InputPipeline	Number of input pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is 0. For more details, see InputPipeline (HDL Coder).
OutputPipeline	Number of output pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is 0. For more details, see OutputPipeline (HDL Coder).

Restrictions

You cannot generate HDL code for this block if it is inside a Resettable Synchronous Subsystem (HDL Coder).

Version History

Introduced in R2016a

R2018b: Improved line buffer

The internal line buffer in this block now handles bursty data, that is, noncontiguous valid signals within a pixel line. This implementation uses fewer hardware resources due to improved padding logic and native support for kernel sizes with an even number of lines. This change affects the Line Buffer block and blocks that use an internal line buffer.

The latency of the line buffer is now reduced by a few cycles for some configurations. You might need to rebalance parallel path delays in your models. A best practice is to synchronize parallel paths in your models by using the pixel stream control signals rather than by inserting a specific number of delays.