RCD Files

RCD is a file format created by FLI in order to save the raw and uncompressed data array that is produced by
our cameras.  The following is a breakdown of the data structure of the RCD files

Metadata
Image Data

The Metadata is broken down into the following
Bytes 0-3: The Magic #.  This is the sequence that all of our image files start with. (0x4D657461)
Bytes 4-5: Tell how large the metadata file size is. 
Bytes 6-n: The metadata of the image, defined by Bytes 4-5.  Our current metadata 0-n is currently 246
bytes long.  Older image files may have 156 bytes of information. 
Bytes n(245)-m: Include the Image Data

The image data is dependent on the sensor and mode the camera is operating in.  For a complete
understanding of how the sensor outputs data for the image, please see the sensors manufacturer.  Our
cameras output the pixel data in a 12bits.  Therefore every 2 bytes of data yield 3 pixels worth of data. 
Below is a brief synopsis of some of the sensors/modes.

// In HDR mode, the capture contains both images interlaced so the pixels are:
// (LDR, row0, pixel0), (LDR, row0, pixel1) ... (LDR, row0, pixelN),
// (HDR, row0, pixel0), (HDR, row0, pixel1) ... (HDR, row0, pixelN),
// (LDR, row1, pixel0), (LDR, row1, pixel1) ... (LDR, row1, pixelN),
// (HDR, row1, pixel0), (HDR, row1, pixel1) ... (HDR, row1, pixelN),
// (LDR, rowN, pixel0), (LDR, rowN, pixel1) ... (LDR, rowN, pixelN),
// (HDR, rowN, pixel0), (HDR, rowN, pixel1) ... (HDR, rowN, pixelN),
//
// If there is dummy data at the end of the rows on the KL400 the pixels are:
// (LDR, row0, pixel0), (LDR, row0, pixel1) ... (LDR, row0, pixelN),
// (HDR, row0, pixel0), (HDR, row0, pixel1) ... (HDR, row0, pixelN), (HDR, row0, pixelD0), (HDR, row0, pixelD1), ... (HDR, row0,
pixelDN),
// (LDR, row1, pixel0), (LDR, row1, pixel1) ... (LDR, row1, pixelN),
// (HDR, row1, pixel0), (HDR, row1, pixel1) ... (HDR, row1, pixelN), (HDR, row1, pixelD0), (HDR, row1, pixelD1), ... (HDR, row1,
pixelDN),
// (HDR, rowN, pixel0), (HDR, rowN, pixel1) ... (HDR, rowN, pixelN), (HDR, rowN, pixelD0), (HDR, rowN, pixelD1), ... (HDR, rowN,
pixelDN),
//
// If there is dummy data at the end of the rows on all other cameras the pixels are:
// (LDR, row0, pixel0), (LDR, row0, pixel1) ... (LDR, row0, pixelN), (LDR, row0, pixelD0), (LDR, row0, pixelD1), ... (LDR, row0,
pixelDN),
// (HDR, row0, pixel0), (HDR, row0, pixel1) ... (HDR, row0, pixelN), (HDR, row0, pixelD0), (HDR, row0, pixelD1), ... (HDR, row0,
pixelDN),
// (LDR, row1, pixel0), (LDR, row1, pixel1) ... (LDR, row1, pixelN), (LDR, row1, pixelD0), (LDR, row1, pixelD1), ... (LDR, row1,
pixelDN),
// (HDR, row1, pixel0), (HDR, row1, pixel1) ... (HDR, row1, pixelN), (HDR, row1, pixelD0), (HDR, row1, pixelD1), ... (HDR, row1,
pixelDN),
// (LDR, rowN, pixel0), (LDR, rowN, pixel1) ... (LDR, rowN, pixelN), (LDR, rowN, pixelD0), (LDR, rowN, pixelD1), ... (LDR, rowN,
pixelDN),
// (HDR, rowN, pixel0), (HDR, rowN, pixel1) ... (HDR, rowN, pixelN), (HDR, rowN, pixelD0), (HDR, rowN, pixelD1), ... (HDR, rowN,
pixelDN),


// In LDR mode, the capture contains straight pixel data so the pixels are:
// (LDR, row0, pixel0), (LDR, row0, pixel1) ... (LDR, row0, pixelN),
// (LDR, row1, pixel0), (LDR, row1, pixel1) ... (LDR, row1, pixelN),
// (LDR, rowN, pixel0), (LDR, rowN, pixel1) ... (LDR, rowN, pixelN),
//
// If there is dummy data at the end of the rows the pixels are:
// (LDR, row0, pixel0), (LDR, row0, pixel1) ... (LDR, row0, pixelN),
// (LDR, row1, pixel0), (LDR, row1, pixel1) ... (LDR, row1, pixelN), (LDR, row1, pixelD0), (LDR, row1, pixelD1), ... (LDR, row1,
pixelDN),
// (LDR, row2, pixel0), (LDR, row2, pixel1) ... (LDR, row2, pixelN),
// (LDR, row3, pixel0), (LDR, row3, pixel1) ... (LDR, row3, pixelN), (LDR, row3, pixelD0), (LDR, row3, pixelD1), ... (LDR, row3,
pixelDN),
// (LDR, rowN, pixel0), (LDR, rowN, pixel1) ... (LDR, rowN, pixelN), (LDR, rowN, pixelD0), (LDR, rowN, pixelD1), ... (LDR, rowN,
pixelDN)


For Cobalt Cameras, the data is slightly different.
// Process the image data. We are processing 2 rows per loop
// The capture contains images with the following pixel configuration:
// (row0, pixel0), (row0, pixel1) ... (row0, pixelN/2), (row0, pixelN), (row0, pixelN-1), ... (row0, pixelN/2+2), (row0, pixelN/2+1)
// (rowN, pixel0), (rowN, pixel1) ... (rowN, pixelN/2), (rowN, pixelN), (rowN, pixelN-1), ... (rowN, pixelN/2+2), (rowN, pixelN/2+1)
// (row1, pixel0), (row1, pixel1) ... (row1, pixelN/2), (row1, pixelN), (row1, pixelN-1), ... (row1, pixelN/2+2), (row1, pixelN/2+1)
// (rowN-1, pixel0), (rowN-1, pixel1) ... (rowN-1, pixelN/2), (rowN-1, pixelN), (rowN-1, pixelN-1), ... (rowN-1, pixelN/2+2), (rowN-1,
pixelN/2+1)
// ...,
// (rowN/2, pixel0), (rowN/2, pixel1) ... (rowN/2, pixelN/2), (rowN/2, pixelN), (rowN/2, pixelN-1), ... (rowN/2, pixelN/2+2), (rowN/2,
pixelN/2+1)
// (rowN/2+1, pixel0), (rowN/2+1, pixel1) ... (rowN/2+1, pixelN/2), (rowN/2+1, pixelN), (rowN/2+1, pixelN-1), ... (rowN/2+1, pixelN/2+
2), (rowN/2+1, pixelN/2+1)
Raw Camera Data (RCD) File Format
Finger Lakes Instrumentation, a division of IDEX Health & Science
1250 Rochester St.
Lima, New York 14485
Phone: 585-624-3760
Email: IHSKeplerSupport@IdexCorp.com
Web: www.flicamera.com
©2023 IDEX Health & Science