Phantom Cine: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 7: Line 7:
Note: some of the fixed offsets below might not always be at that offset, though they are for the known samples and there are no length fields that would allow calculating them in a sensible way.
Note: some of the fixed offsets below might not always be at that offset, though they are for the known samples and there are no length fields that would allow calculating them in a sensible way.


Variable length part seems to start at offset 0x16c0.
All values are stored in little-endian format.
 
The files start with the bytes "CI", followed by two bytes possibly giving a size or index (all files so far have the value 2c 00).
 
This "main header" contains this data:
  2 bytes "CI"
  2 bytes length
  2 bytes "compression type" (always 2) ??
  2 bytes version (always 1)
  4 bytes number of first frame (usually negative)
  4 bytes number of frames in files
  4 bytes number of first frame (repeated?)
  4 bytes number of frames in files (repeated?)
  4 bytes offset of BitampInfoHeader
  4 bytes offset of ???
  4 bytes offset of file index
  8 bytes recording time stamp (?)
 
At offset 0x2c there is a BitmapInfoHeader structure. The first 4 bytes give its length (0x28).
 
The next sections starts with "ST" at offset 0xe0, again followed by two bytes giving a size or index (so far always 6c 16).
 
Variable length part seems to start at offset 0x16c0. Note that this is the sum of the possible length files from CI, ST and BitmapInfoHeader (i.e. 0x2c + 0x28 + 0x166c = 0x16c0).


It consists of 3 parts:
It consists of 3 parts:

Revision as of 05:02, 28 March 2010

The Phantom Cine format

This is a raw uncompressed format.

It contains a lot of metadata, and index and raw uncompressed frames, presumably in Bayer format.

Note: some of the fixed offsets below might not always be at that offset, though they are for the known samples and there are no length fields that would allow calculating them in a sensible way.

All values are stored in little-endian format.

The files start with the bytes "CI", followed by two bytes possibly giving a size or index (all files so far have the value 2c 00).

This "main header" contains this data:

 2 bytes "CI"
 2 bytes length
 2 bytes "compression type" (always 2) ??
 2 bytes version (always 1)
 4 bytes number of first frame (usually negative)
 4 bytes number of frames in files
 4 bytes number of first frame (repeated?)
 4 bytes number of frames in files (repeated?)
 4 bytes offset of BitampInfoHeader
 4 bytes offset of ???
 4 bytes offset of file index
 8 bytes recording time stamp (?)

At offset 0x2c there is a BitmapInfoHeader structure. The first 4 bytes give its length (0x28).

The next sections starts with "ST" at offset 0xe0, again followed by two bytes giving a size or index (so far always 6c 16).

Variable length part seems to start at offset 0x16c0. Note that this is the sum of the possible length files from CI, ST and BitmapInfoHeader (i.e. 0x2c + 0x28 + 0x166c = 0x16c0).

It consists of 3 parts:

1) timestamps

2) exposure values

3) index

The timestamp and exposure values parts start with a 4-byte length field allowing to skip them.

The index contains a 8-byte offset value for each frame. It does not have a length field, the number of entries is determined from the number of frames in the main header.

At each offset indicated by the index, there is first a header. The first 4 bytes of the header give the length of the header. Only the value 8 has a known meaning, in which case the next 4 bytes give the length of the frame data.