Introduction
This page describes the various frame buffers available in the cameras.
Raw
Description
The raw buffer contains the raw image data from the sensor for still photos. It only contains valid raw data during the shooting process. The same address space may be used for other things at other times.
Some cameras have a single raw buffer, while others alternate between two (or more ?).
Formats
All raw buffers contain bayer data. Two different bayer patterns are used on CHDK cameras.
The first, more common variant is
Red Green Green Blue
The second is
Green Blue Red Green
The total size can usually be found with the string "CRAW BUF SIZE"
The dimensions may be found with the string "CrwAddress %lx, CrwSize H %ld V %ld" (TODO other cameras)
The raw buffer may be either 10 bit or 12 bit, packed little endian, as detailed below.
The ASCII diagrams below show how the bits in memory make up pixels.
- Bytes are numbered from right to left
- Pixels are numbered from top to bottom
- Bits of a given pixel are numbered in the table itself. For the 12 BPP format, the letters A and B stand for 10 and 11
So the first pixel in the ten bit format has it's least significant two bits in the least significant two bits of the first byte, and the most significant 8 bits in the second byte.
See the code of tools/rawconvert.c or core/raw.c for examples of how to read each possible position.
10-bit
Most pre Digic IV cameras use this format
0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
0 10 98765432
1 987654 3210
2 543210 9876
3 98 76543210
4 98765432 10
5 3210 987654
6 9876 543210
7 76543210 98
12-bit
Most Digic IV cameras use this format
0 |1 |2 |3 |4 |5 |
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
0 3210 BA987654
1 BA98 76543210
2 BA987654 3210
3 76543210 BA98
Location
One address can generally be found using the string "CRAW BUF".
TODO: describe how to find the other where needed.
In CHDK
TODO: add function etc.
Used for:
- Raw/DNG images
- bad pixel removal
- shot_histogram
- curves
- raw develop
Bitmap (or Overlay)
Description
An overlay which is used to display the camera UI.
The overlay is double-buffered. The second buffer directly follows the first. TODO: describe usage
Format
The bitmap buffer is 8-bit, indexed. The palette varies between models, and in between playback and record modes on some models.
The most common size is 360x240, but 720x240 and other sizes occur. The buffer may not be the same size as the actual display area or the viewport buffer.
Bitmap pixels are not square on some cameras, for example on those with a 720x240 buffer.
The buffer can be bigger than the actual image. If the buffer width is bigger than the image width, each row of pixels is padded to the buffer width. Similarly, if the buffer height is bigger than the image height, the last row is followed by padding to get to the buffer height. The latter is important when you want to get the location of the second bitmap buffer.
Palette (TODO)
Location (TODO)
In CHDK
Functions:
- include/platform.h
- void *vid_get_bitmap_fb(): get base address of the bitmap buffers
- long vid_get_bitmap_screen_width(): get width of actual image
- long vid_get_bitmap_screen_height(): get height of actual image
- long vid_get_bitmap_buffer_width(): get width of buffer
- long vid_get_bitmap_buffer_height(): get height of buffer
- void vid_bitmap_refresh(): force redrawing of the overlay(?)
- void vid_turn_off_updates(): block drawing of the overlay by the firmware
- void vid_turn_on_updates(): allow the firmware to be draw the overlay again
- long vid_is_bitmap_shown(): unused and only trivially implemented for A610 1.00f; should probably not be used and removed from CHDK
Defines:
- CAM_BITMAP_PALETTE: defines which palette the camera uses (defined in include/camera.h, platform/<platform>/platform_camera.h, used in core/gui_draw.h)
- COLOR_*: palette colours (defined in core/gui_draw.h)
Used for:
- UI
Viewport
Description
The viewport buffer is used for the live view from the camera, or images in playback.
There are three different viewport buffers. One for playback mode, two for record mode. One of the buffers for record mode is triple-buffered (the other "single-buffered). Unlike the bitmap buffers, the triple-buffered buffers need not follow each other in memory.
TODO: Fast MD relies on known the current buffer, describe...
Format
In the viewport buffer pixels are grouped in 4. Each group is represented in six bytes. Each pixel is represented by a YUV triplet where the U and V components are shared amongst the group. The order of the bytes is as follows, with Yi the Y component of the ith pixel in the group:
U Y1 V Y2 Y3 Y4
Note that U and V are signed bytes, while the Y components are a unsigned bytes.
To convert a YUV triplet to an RGB triplet, one can use the following code:
function clip(val):
if val < 0:
return 0
else if val > 255:
return 255
else:
return val
R = clip( ((Y << 12) + 5742 * V + 2048) >> 12 )
G = clip( ((Y << 12) - 1411 * U - 2925 * V + 2048) >> 12 )
B = clip( ((Y << 12) + 7258 * U + 2048) >> 12 )
N.B.: The constants in the code above differ from the ones in one of the threads below. The code does (seem to) work.
As with the bitmap buffers, viewport buffers might be wider (and higher) than the actual image. Padding is done similarly. The height of a viewport buffer, however, is not really relevant as one doesn't need to look beyond the last row of the actual image.
With newer cameras the actual image might be offset at a different location than (0,0). This means that there can be some padding rows at the start of the buffer as well as some padding bytes at the start of each row.
See also http://chdk.setepontos.com/index.php?topic=5415.0 and http://chdk.setepontos.com/index.php?topic=6072.0 .
Location (TODO)
In CHDK
Functions:
- include/platform.h
- void *vid_get_viewport_fb_d();: get "single-buffered" buffer for playback mode
- void *vid_get_viewport_fb();: get "single-buffered" buffer for record mode
- void *vid_get_viewport_live_fb();: get triple-buffered buffer for record mode
- int vid_get_viewport_width();: get the width of the actual image
- long vid_get_viewport_height();: get the height of the actual image
- int vid_get_viewport_buffer_width();: get the width of the buffer
- int vid_get_viewport_xoffset();: get the x offset of the image in the buffer
- int vid_get_viewport_yoffset();: get the y offset of the image in the buffer
- int vid_get_viewport_image_offset();: get the offset of the first actual pixel (group) in the buffer (auxiliary function?)
- int vid_get_viewport_row_offset();: get the number of bytes between rows (auxiliary function?)
Used for:
- Motion detection
- Live histogram
- Zebra
- Edge overlay
JPEG (TODO)
Jpeg buffer is mentioned in the firmware, might be interesting