Grayscale Closing

Morphological closing of grayscale pixel data

• 

Libraries:
Vision HDL Toolbox / Morphological Operations

Description

The Grayscale Closing block performs morphological dilation followed by morphological erosion by using the same neighborhood for both calculations. The block operates 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 and minimum pixel values. For structuring elements less than 8 pixels wide, or that contain zero elements, the block implements a pipelined comparison tree to find the maximum and minimum pixel values.

Ports

This block uses a streaming pixel interface with a pixelcontrol bus for frame control signals. This interface enables the block to operate independently of image size and format. All Vision HDL Toolbox™ blocks use the same streaming interface. The block accepts and returns a scalar pixel value and a bus that contains five control signals. The control signals indicate the validity of each pixel and its location in the frame. 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

Single image pixel in a pixel stream, specified as an unsigned integer scalar that represents grayscale intensity.

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.

Data Types: bus

Output

pixel — Output pixel stream

scalar

Single output pixel transformed by a morphological operation, returned as a scalar value.

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.

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.

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 closing algorithm is morphological dilation followed by morphological erosion. For the respective kernel architectures, see the Grayscale Dilation and Grayscale Erosion reference pages.

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

Latency

The total latency of the block is the line buffer latency plus the latency of the kernel calculation. The line buffer latency includes edge padding. Morphological closing is a compound operation, so this block contains a second line buffer between the dilation kernel and the erosion kernel. To determine the exact latency for any configuration of the block, monitor the number of time steps between the input control signals and the output control signals.

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).

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 291 MHz.

Resource	Usage
Slice LUTs	864
Slice Registers	1484
DSP48	0
Block RAM	2

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.