Two images can be stitched horizontally to create a bigger image.

The image processing is done at byte level, and utilizes Thomas Jung’s ZCL_ABAP_BITMAP class.

Below image summarizes what is being done.


Thomas Jung’s ABAP Bitmap Image Processing Class (ZCL_ABAP_BITMAP) , available as SAPLink nugget.

Any Hex Editor to view image files, because the processing is done on hex string at byte level.

Code snippet can be written in Thomas Jung’s test program ZABAP_BITMAP_TEST, or a new method can be created in ZCL_ABAP_BITMAP


Class ZCL_ABAP_BITMAP already has several single image processing options such as rotation, flipping, inversion etc.

For 2 input images, 2 instances are creating using method CREATE_FROM_EXT_FORMAT.

The bitmap headers are retrieved using method GET_HEADER_INFORMATION.

Individual image pixels are read using method GET_PIXEL_VALUE.

After creating hex stream that contains stitched image, method CREATE_FROM_BYTESTREAM is used to create image object.

Method DISPLAY_IN_SAPGUI is used to display final image.

Understanding of bitmap structure using small images

Although everything is well explained in ABAP Bitmap Image Processing Class and BMP file format – Wikipedia , it took some effort to understand how bitmap image is structured.

So I created a very small image of resolution 3×4 using Microsoft Paint. (24-bit uncompressed bitmap format).

This is how the 3×4 image looks at 32x zoom.

After debugging the constructor and rotate methods on this image, I came to know that:

  • Bitmap stream can be divided on 2 parts, header and pixel array.
  • Bitmap header contains size, height, width, pixel array bytes information. Wikipedia article shows exact offset at which this information is stored.
  • Bitmap pixel array start at an offset maintained in header, and for 24-bit bitmap, 3 bytes per pixel is used.
  • A 3×4 image has 4 rows, each row having 3 pixels (total 12 pixels).
  • For a row (3pixels), 9 bytes are required, but bitmap uses 12 bytes for each row. This is because row size in bytes is rounded to next multiple of 4.
  • 1 row = 12 bytes = 3pixels * 3bytesperpixel + 3 (padding with dummy data)
  • Since padding determines exact bytes occupied, rotating an image can result in change of pixel array size.
  • For example 3×4 image pixel array size is 48 {4 * (3 * 3 + 3padding) }, whereas 4×3 image pixel array size is 36 { 3 * ( 4 * 3 + 0padding ) }.

Hex mode comparison of input and output image bitmap header

I created two 3×4 input images, and stitched them manually to create 6×4 output image.

All 3 images were seen in hex mode to figure out the logic.

Below are the images at 32x zoom, and their hex mode view.

This is the pseudo code for stitching images horizontally, deduced by comparing hex modes.

  • Ensure height of input images is same.
  • Copy header of first image.
  • Since images are joined horizontally edge to edge, height does not need to be changed.
  • New width would be sum of widths of input images.
  • Pixel array Offset remains unchanged for 24bit uncompressed bitmap.
  • Size of pixel array needs to be calculated for (width1+width2)x(commonheight) image, taken padding bytes into consideration.
  • The pixel array needs to be constructed putting together pixels of image1, image2 and padding bytes.
  • Hex stream of output image can be created by concatenating new header and new pixel array.
  • A new instance of ZCL_ABAP_BITMAP can be created using this hex content, so that output can be shown in SAP GUI.

Stitching images vertically

For stitching images vertically, similar logic is required.

It should be relatively simpler because in this case the width (padding too by extension) does not change.

So we can directly concatenate pixel arrays in input images to get output pixel array.

Size can be direct sum of header, pixelarray1 and pixelarray2.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

Leave a Reply