AVINE Video System

File Formats

• IMC2 (aka BKC2) File Format (introduced 2023)
• Dated File Formats (simple, deprecated, still used)
  • IMM file format
  • BKG file format
  • IMC file format
  • BKC file format

IMC2 (BKC2) File Format

Following a request of being able to save individual scaling factors (pixel to millimetre) for horizontal (x) and vertical (y) dimension of an image to file, the file format IMC2 has been created. It can store a single image or an image sequence (meant for multiple images taken very close after one another or directly after each other). Colour (RGB 24 bits per pixel) and grayscale (8 to 16 bit per pixel) images are supported. It stores many header fields of images in human readable format (simple file view as text) as metadata inside the file. In order to distinguish whether a file contains signal or background images, the file extension is used. One shall use '.imc2' for signal images and '.bkc2' for background images. The structure of the file is identical in both cases, just the file extension differs.

Identical to dated file format IMC/BKC, lossless compression (zlib) is applied for each image. If compression is ineffective, uncompressed image data is stored instead.

Video System 3 and IMC2 Header Fields

There are four different type of metadata in IMC2: uint32, int32, float and string. Some metadata is optional, most is mandatory.

Footnotes:

1	valid source image formats (source_format is an informal parameter) are: 'GRAY', 'RGB', 'RGBA', 'RGB15', 'RGB16', 'JPEG', 'TIFF', 'YUV411', 'YUV422', 'YUV444', 'HUFFYUV', 'BMP', 'BAYER'
2	for image_format, valid is 'GRAY' or 'RGB'
3	Image Flags: LITTLE_ENDIAN or BIG_ENDIAN, LOSSLESS or LOSSLESS_BIT_NOT_SET, HORIZONTAL_FLIP_180, VERTICAL_FLIP_180, XYSTART_ONE_BASED, XYSTART_ZERO_BASED, EVENTNUMBER_OUT_OF_SYNC, GLOBAL_TIMESTAMP or LOCAL_TIMESTAMP, TIMESTAMP_EXTRAPOLATED, SCALE_OFFSET, SOFTWARE_ROI

IMC2 File Format Layout

Footnotes:

1	position starting from beginning of file, zero-based index, in bytes
2	data is encoded as little endian format (LSB first, MSB last)
3	initial header values magic1 and magic2 are existing to easily distinguish from imm/bkg/imc/bkc file format (and reject file by already existing code loading in imm/bkg/imc/bkc files)
4	if len_u equals len_c, image data was saved uncompressed (ineffective compression)

METASTRUCT Layout

Remarks:

A metadata set in file consists of 252 bytes.

The key string must not contain equal sign ('='), as it is used to distinguish key part of string from value part. The value part may consist of further equal signs.

It is recommended to use only ASCII inside keyvalue string.

There are four types of metadata: uint32, int32, float and string.

IMM File Format Layout

Footnotes:

1	position starting from beginning of file, zero-based index, in bytes (1 is first byte in file)
2	The data is encoded as little endian format (LSB first, MSB last).
3	Bytes per pixel setting was introducted later on. Before that the field was set to '0'. If field is set to 0 in file, one can assume that 8 bits per pixel setting is used (each pixel is 1 byte).

Either one or multipe images can be stored inside an IMM file. If multiple images are contained within the file, the whole structure (from width to scale) can be repeated multiple times in the IMM file. By this simple technique one is able to store a sequence of images in file. In practice the images that are contained in such files came from the same image source and are guaranteed to be in time-ascending sequence, i.e. later image (higher file index position) in file was acquired later in time than image which was placed earlier in file (lower file index position). Another convention is that the values of width, height, physical and effective bits per pixel and scale factor stay the same for each image inside the file. Only the raw image data should change for each image. If varying values are found within the file, one should present a warning. An algorithm for loading in an IMM file is as follows:

• open the file
• determine file length
• read in first two bytes and store as width
• read in next two bytes and store as physical bits per pixel
• read in next two bytes and store as height
• read in next two bytes and store as effective bits per pixel
• validate values
• calculated number of images inside file: num_images = length_of_file / ((width*height*physical_bits_per_pixel/8)+16)
• validate that num is integer value (if there is a fractional part then file is not wellformed)
• seek to start of file
• repeat for every frame in file (num_images)
  • read in 8 bytes
  • read in frame bits (width*height*physical_bits_per_pixel/8)
  • read in 8 bytes (scale factor)
• close file

Footnotes:

1	position starting from beginning of file, zero-based index, in bytes (1 is first byte in file)
2	The data is encoded as little endian format (LSB first, MSB last).
3	Bytes per pixel setting was introducted later on. Before that the field was set to '0'. If field is set to 0 in file, one can assume that 8 bits per pixel setting is used (each pixel is 1 byte).
4	In the wild, there are some nonstandard bkg files with more than one background image per file. These files are in principle not supported but usually follow the same layout like in IMM file format, except that no scale factor is present. Based on the BKG image file format one can say that the whole structure is repeated for any image in the file (as if a bunch of bkg files have been concatenated).

Only one image can be stored inside an BKG file. An algorithm for loading in is as follows:

• open the file
• read in first two bytes and store as width
• read in next two bytes and store as physical bits per pixel
• read in next two bytes and store as height
• read in next two bytes and store as effective bits per pixel
• validate values
• read in frame bits (width*height*physical_bits_per_pixel/8)
• close file

Footnotes:

1	position starting from beginning of file, zero-based index, in bytes (1 is first byte in file)
2	The data is encoded as little endian format (LSB first, MSB last).

IMC and BKC files contain the same layout inside. Just the file extension is different. When compared to IMM/BKG files, the main difference is that in IMC/BKC files, image data is lossless compressed using zlib library. A compression ratio of about 1:10 is realistic, although it may vary significant on the image content. A BKC file with more than one image is used to store source background images which will be combined to a single background image using certain algorithms (Envelope, Average) in order to produce a single background image out of it, which is used for background subtraction later on. Basically the structure defines that each image in file can have a separate scale factor. But this is not true in practice. Usually all images come from the same image source and are kept in sequence (time ascending order). So they share the same characteristics like width, height, physical and effective bits per pixel as well as the scale factor. If varying scale factors are found inside the file, one should display a warning. An algorithm for loading in an IMC/BKC file is as follows:

• open the file
• read in the file header (first 16 bytes)
• validate values
• repeat for as many images as the file header tells
  • read in single image header (16 bytes)
  • validate values
  • read in compressed frame bits
  • uncompress frame bits
• close file