VisibleGif

Image As Data Packed

Within the XML file, within the <image> tag block, image data can be displayed within the <data-packed> tag block. Valid tags within this block are <blocksize> and <bytes>. This page describes the characteristics and use of this data.

Generating similar images

• Warning on manually editing the "packed" data
• Why work with the <data-packed> tag block?
• Tags which can be amended
• Precedence in generation before <data-codes> and <data-rows>

Technical details

• Bytes and blocks
• Bytes and bits
• Inefficient block sizes
• Warning when handling interlaced images

Generating similar images

 ^  Warning on manually editing the "packed" data

The data in the <data-packed> tag block should only be manually amended by an expert who understands the GIF variant with variable bit size of the LZW compression algorithm. It can, with care, be used without amendment ("as is") to generate other similar images.

 ^  Why work with the <data-packed> tag block?

If the <lzw-minimum-code-size> and the <data-packed> tag block are left exactly as they were generated, colours and other characteristics can be changed and new GIF images generated. These new images will be exactly the same as the original except in respect of those tags which have been changed.

It is faster to generate large numbers of similar images if the <data-packed> tag block does not have to be regenerated each time. This is a development issue not an operational one.

 ^  Tags which can be amended

The following are tags that can be changed without needing to regenerate the <lzw-minimum-code-size> and the <data-packed> tag block.

 ^  Precedence in generation before <data-codes> and <data-rows>

If an XML file contains the three versions of the image data, the precedence when generating the GIF image file is as follows.

1. <data-packed>
2. <data-codes>
3. <data-rows>

So if <data-packed> and <data-rows> are present in an XML file the image will be generated from the <data-packed> tag block.

Technical details

 ^  Bytes and blocks

Each byte comprises two hex characters. Contigous groups of bytes comprise a block. A block can be up to 255 bytes in length. Groups of blocks are terminated by a block of zero length. This termination block must always be present

  <lzw-minimum-code-size>2</lzw-minimum-code-size>
  <data-packed>

   <blocksize>29</blocksize>
   <bytes>848FA9CBED0FA39CB4DA4B83DE5CB70E065FC88DA4C79C9B79B224E614</bytes>

   <blocksize>0</blocksize>
   <bytes></bytes>

  </data-packed>

It is usual and most efficient to hold an image as a number of maximum sized blocks each of 255 bytes, a last block containing the remainder and a final zero sized termination block.

 ^  Bytes and bits

A byte comprises eight bits. A variable group of bits represent a "compression table" code. The minimum number of bits which can store a code is three and the maximum number of bits is twelve. The <lzw-minimum-code-size> plus one represents the initial number of bits used to store the first "compression table" code.

 ^  Inefficient block sizes

Some image editor software generates variable sized blocks. This is inefficient. The "reblock" sub-parameter will reblock the data to the optimal efficiency.

If the "reblock" sub-parameter is used with the "packed" sub-parameter both the original <data-packed> tag block and a new <data-repacked> tag block are generated. If a new image is generated using this XML file the original <data-packed> tag block will be used even if the new <data-repacked> tag block is present. The XML file should be manually edited to use either the original or the new optimal blocking.

The presumption must be that the original blocking was created for a reason. The reasons lie outside the scope of performance considerations. For example the variable sizes of blocks might indicate additional meaning for the data such as might be used in a security application. Alternatively it might imply a poor implementation of the image editor software.

If the "reblock" sub-parameter is used with the "-packed" sub-parameter only an optimally blocked <data-packed> tag block will be generated. The original blocking will not be generated.

It is usually worth generating first without the "-packed" sub-parameter to try and assess the quality of the original image editor software blocking.

 ^  Warning when handling interlaced images

The <interlaced> tag should not be amended. The process to interlace an image works prior to creating the "compression table" codes and prior to packing these codes into bytes. If the <interlaced> tag is amended the image is scrambled.

This may be a quick and easy low grade encryption technique.

• The sender would take a GIF image and generate the XML.
• The sender would change the <interlaced> tag and regenerate the scrambled GIF image.
• The scrambled GIF image would be sent to the receipient.
• The recipient would generate the XML, change the tag and recreate the original GIF image.