Difference between revisions of "Phantom Cine"

From MultimediaWiki
Jump to: navigation, search
m (typo fix)
(Clarify: current description is not based on specification)
Line 4: Line 4:
  
 
The Phantom Cine format
 
The Phantom Cine format
 +
 +
Note: below information is based on looking at a sample file, please verify against the specification linked at the end.
  
 
This is a raw uncompressed format.
 
This is a raw uncompressed format.

Revision as of 04:12, 13 June 2010

Extensions: cine

The Phantom Cine format

Note: below information is based on looking at a sample file, please verify against the specification linked at the end.

This is a raw uncompressed format.

It contains a lot of metadata, and index and raw uncompressed frames, presumably in Bayer format. Know samples store each Bayer sample with 16 bits, where only the lowest 14 bits are relevant (the value 16 can be determined from the BitmapInfoHeader, the 14 bits are somewhere in the file as well, as can be seen from the xml-representation of the metadata (the RealBPP entry) - all data in the xml file exists in the .cine file as well). Making the lowest instead of the highest 14 bits the relevant ones is a rather unfortunate choice since it makes conversion to standard formats more difficult.

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.

External Links