DB2 UDB static image extender (1)

Introduction

Many applications need to store and manage digital images in databases. DB2 UDB provides the DB2 UDB Audio, Image, and Video Extenders packages. DB2 Image Extender is part of this package [2]. Although this extender provides a certain number of image processing functions, more functions are often needed, or the existing functions need to be more common, such as supporting rotation at any angle. The existing extensifier was initially based on DB2 UDB Version 5, after which many new features have been added to the database engine. However, the extended package has not fully utilized these new features.

This article demonstrates how to combine the latest image processing program ImageMagick with DB2 UDB to provide a new extender to manage static images in a new way. This article shows how to implement the necessary User-Defined Function udfs), register them to the database, and combine these functions through the ImageMagick library, finally, you get your own image Extender for DB2 UDB [5, 6.

The extended extender) described in this article provides basic functions for manipulating images stored in the database in the form of Binary Large Object BLOB. These images can be rotated at any angle, scaled, resized, reversed, and trimmed, and the shape, color, or content can be manipulated in multiple ways. This extender also provides a set of functions for obtaining image-specific attributes, such as the height or width in pixels) or resolutions on X or Y dimensions. In addition to the BLOB-based interface, this article also describes how to implement a specific data type according to SQL/MM Part 5: Still Image [3.

The next section will give a brief overview of ImageMagick, and then attach some sample code about image-related udfs. You will see how to compile the code and link it to ImageMagick into a shared library that can be processed by DB2. The SQL interface is described in this article. It can be seen that simple interfaces that only process BLOB and interfaces that use object-relational of DB2, especially those that encapsulate image functions using structure types) what is the difference between the two.

ImageMagick Overview

ImageMagick [1] is a collection of libraries and tools that allow you to read, write, and process static images in different formats. Currently, more than 89 supported image formats are supported, such as TIFF, JPEG, PNG, PDF, and GIF. It allows you to resize, rotate, or sharpen an image, reduce the number of colors, or add special effects. ImageMagick provides a variety of interfaces, including for C/C ++, Perl, Java™Various command line tools that interact with programming languages such as PHP. The DB2 extension provided in this article uses the ImageMagick library and its C/C ++ interface to connect to DB2. The sample code provided in the download section is based on ImageMagick 6.1.9. If you want to use different versions, you need to modify the code because the interface may change.

Sample Code for some udfs

First, let's give a brief overview of some udf c/C ++ code. You will implement these udfs [6]. Note that the implementations of all other functions are very similar. The main difference is that the ImageMagick function is called.

Before describing the actual UDF details, let's take a look at the supported functions used in most udfs. Some of these functions are used for error processing, and some use the BLOB locator to obtain image data from db2, some others write the result to another BLOB locator.

Supported Functions

All udfs need some infrastructure to manage errors. The error processing implemented for the static image extender will process all ImageMagick errors. Error handling is encapsulated in the IexError class. In this way, you can easily add error message locating. This class also provides single point of control over all errors and provides the necessary basis for tracking error information, which helps to discover unexpected errors in the production environment. In addition to the IexError class, we also define a group of macros named IEX_SET_ERROR *, which are used to set new error messages.

The second supported functions are in the IexUdfUtils. cpp file. These functions manage scratchpad and process the transmission of image data between different BLOB locators in DB2. The IexReadImageToScratchPad function obtains image data from the input BLOB locator, constructs a specific ImageMagick object in the memory, and stores the pointer to that object in the data structure mapped to scratchpad. Similarly, the IexWriteImageToLocator function uses an ImageMagick object as the input parameter, converts the object into a binary stream, and writes the stream to the output BLOB locator. We will not discuss the code that supports functions in a row, but just focus on those functions specific to images.

Function SI_rotate

Each UDF is implemented as an independent C ++ function. It uses function-specific parameters as the target format for input, for example, format conversion operations). One is the BLOB Locator of the image, which is used for operations, and the other is the BLOB locator, used for the final image. In addition, common null indicators and other mandatory parameters used for udfs must appear in function labels. Please note that we use the locator to provide runtime performance. For example, when detecting the performance specific to an image, you usually only need to process the image's header, instead of passing the entire image data from DB2 to the UDF.

Call type & scratchpad Parameters

All udfs are declared using the final call and SCRATCHPAD options. Therefore, a memory block is used to pass information or pointers to other memory blocks from callback function calls to callback function calls. This is often the case when a function needs to process multiple images, for example, SQL statements. Because SQL is a collection-oriented query language, the above practices provide necessary support for improving performance.

In listing 1, you can see the code about UDF SI_rotate. It can be represented by all other udfs that manipulate image content. These udfs are very similar. At the beginning of a function, next to the function tag is the initialization of the internal variables of the function, such as ImageMagick variables, pointing to scratchpad to impose a structure on it) and the null Indicator Used for the result image locator. The angle parameter affects image operations. For example, it defines how the image is rotated. If necessary, the Code also standardizes this parameter, the angle is expressed in the form of a degree between [0,360.

Next is the actual processing. First, call the support function IexReadImageToScratchPad inItalicsDisplay) obtain the image from the BLOB locator, construct the data structure required by ImageMagick, and place the pointer to the data structure on scratchpad. If this function is not the first time, you can reuse the last allocated data structure. The rotation operation itself uses the ImageMagick function RotateImage in the following listBoldDisplay ). The processing result is placed in the Data Structure specific to ImageMagick again. This structure needs to be converted into a BLOB and passed to DB2 through a locator. This is done by using the supported function IexWriteImageToLocatorItalicsDisplay.

Listing 1. Sample Code for image rotation UDF

/** Rotate the image. * * The given image is rotated using the ImageMagick function RotateImage(). * The angle needs to be specified in degrees. The angle is taken modulo 360 * degrees; in other words, angles larger than +360 degrees and smaller than * -360 degrees are accepted. * * Positive angles cause the image to be rotated counter-clockwise, and * negative angles rotate the image clockwise. * * NULL is returned if the given image is NULL. If the specified angle is * NULL, then the image is returned unchanged. */ IEX_EXTERNC void SQL_API_FN IexRotateImage( // input: locator to source image SQLUDF_LOCATOR *sourceLocator, // input: angle of the rotation SQLUDF_DOUBLE *angle, // output: locator to target image SQLUDF_LOCATOR *targetLocator, // null indicators SQLUDF_NULLIND *sourceLocator_ind, SQLUDF_NULLIND *angle_ind, SQLUDF_NULLIND *targetLocator_ind, SQLUDF_TRAIL_ARGS_ALL) { int rc = IEX_SUCCESS; IexError error; Image *result = NULL; ExceptionInfo exception; GetExceptionInfo(&exception); // we assume NULL result *targetLocator_ind = -1; // map the scratchpad struct scratchMap *scratch = (struct scratchMap *)SQLUDF_SCRAT->data; // clean up when the SQL statement is finished if (SQLUDF_CALLT == SQLUDF_FINAL_CALL) { goto cleanup; } // normalize the angle and test if we actually have something to do if (SQLUDF_NULL(angle_ind)) { *angle = 0.0; } *angle = fmod(*angle, 360); if (*angle == 0.0) { *targetLocator = *sourceLocator; *targetLocator_ind = 0; goto cleanup; } // read the image data rc = IexReadImageToScratchPad(sourceLocator, *sourceLocator_ind, scratch, SQLUDF_CALLT, error); if (rc || !scratch->image) { goto cleanup; } // rotate the image result =RotateImage(scratch->image, *angle, &exception); if (!result || IEX_HAVE_MAGICK_EXCEPTION(exception)) { IEX_SET_MAGICK_ERROR(exception); goto cleanup; } if (IEX_HAVE_MAGICK_EXCEPTION(result->exception)) { IEX_SET_MAGICK_ERROR(result->exception); goto cleanup; } // write the result to the target locator rc = IexWriteImageToLocator(result, targetLocator, error); if (rc) { goto cleanup; } *targetLocator_ind = 0; cleanup: DestroyExceptionInfo(&exception); if (result) { DestroyImage(result); } IEX_COMMON_CLEANUP; }