Progress on decoding SiPix JPEG format.


A Raw Image from the camera.


Converted Image from Gphoto2 v2.1.4


Fixed Image by separating Y component into two 320x240 parts and diagonally interlacing into a 640x480 image. Imagine a checkerboard with the red squares being the original pixels and each black square is a pixel made by averaging 4 surrounding red squares.


Fixed Image, custom color map. Somehow the YCbCr -> RGB mapping is exceeding the 0-255 8-bit limit. The data for this picture has been gain-reduced so that clipping does not occur.

Actually, that was what I first thought and the problem is worse. The picture is still blurry and out of focus. The standard JPEG viewer program decodes the raw file by uncompressing the Huffman code. What results is the Discrete Cosine Transform of the image data. There are two steps that follow this before you have a picture, however at this point there is already a serious difference between the proprietary Windows program decoded file and the raw file we are trying to decode.

On comparison of the uncompressed data from the raw file and the Windows program decoded file, it is seen that much of the frequency information in the raw file is zeroed out, or has somewhat different values than the correctly decoded file. That is why the image is lacking sharpness. There is no way to put back in frequency information to restore the data. "Smoothing" does not add information. Therefore, two possiblilities exist, 1) There is a "correct" Huffman code table that will decode the raw data correctly and produce the original DCT frequency data intact, or 2) information is hidden in the data, such as attaching bits onto data values. These bits could be difference values that may be used to construct nearby pixels (I've checked but not found this). One thing is certain: all the pixel data between the proprietary Windows program decoded file and the standard JPEG decoded are different.


Fixed image, missing pixels left blank (0x00). Original pixels wanted.

Garrick Sitongia