What is the file format of the 16bit bitmap hex file?

Question

I am new to this area; so excuse me if I did not describe the issue well.

I have a hex file which should contain three images (width: 640, height: 333). The hex file is 1.2 MB. So if we do a little calculation, we obtain that each pixel should have 16-bit of data.

Some of hex code of the file is as below:

90 eb 6f 14 02 02 fd fd 4e 01 80 02 00 00 00 00
90 eb 6f 14 82 82 7d 7d 4e 01 80 02 03 00 00 00
90 eb 6f 14 c2 c2 3d 3d 4e 01 80 02 00 00 8e 08
a7 33 0f d4 00 01 00 01 00 01 43 01 f8 03 0e 17
00 01 00 00 00 00 02 00 00 00 00 00 00 00 01 00
00 04 00 00 01 01 00 00 00 00 00 00 00 00 00 00
00 00 01 01 00 00 00 00 00 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 01 01
00 00 00 00 01 00 00 00 00 00 00 00 00 00 01 01
00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00
00 01 00 00 08 01 00 00 00 00 00 00 00 00 00 00
00 01 00 00 00 00 00 01 00 00 00 00 00 0a 01 00
00 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00
02 00 00 01 00 00 00 01 00 00 00 00 00 00 00 01

As you can see there is a header with 4 row content which 3 of them is similar. the bitmap data begins. The repeating row is repeated another two times in the file. So I assume that the repeating structure is at the beginning of each of 3 images. But the data between these headers are 210 KB, which means 8-bit per pixel. So I read every 8-bit as an tiny integer and set it to rgb of corresponding pixels of images. So I obtained 3 gray images. Also 630 KB of data remains unread in the file.

Here is magnified version of the original image as gray (original version of the picture is colored) and obtained image. As you see, there are some pixels (every other pixel) which are totally different in compare to original pixels, but whole image is almost correct.

So, my questions are as below: What is the true structure of the hex file? How should I read the hex file? How can I achieve original colored file? What is the extra 630 KB of data!? And what is the wrong pixels?!

also here is original image(i.stack.imgur.com/NdBOa.png), original image as gray(i.stack.imgur.com/wDUPB.png) and obtained image (i.stack.imgur.com/lY3ib.png).

Your original file is 636x330 not 640x333 as you say - why? What happened to the image to make it like it is - what program/tool did this? Doesn't the author of the tool say how the file works? Where is the whole file? — Mark Setchell, Nov 11 '15 at 09:49
the original file is came from a software which the source code is not available. Also I think it is cropped to 636x330; but in the binary file it has 640x333 bytes of data. No documentation is available for the software and I need to do the same In the c++ Code. I can attach whole file if you need it. — l3enQ, Nov 11 '15 at 10:12
If you attach the whole file I'll have a *play* with it - err, I mean "do some very professional forensic analysis". — Mark Setchell, Nov 11 '15 at 10:25
I have uploaded it at filebin.ca/2MAr1UtKowIR. thank you for your effort. this thread's answer is like what I did http://stackoverflow.com/questions/11239203/with-c-and-qt-how-do-i-display-a-16-bit-raw-file-as-an-image — l3enQ, Nov 11 '15 at 10:31

Mark Setchell · Accepted Answer · 2015-11-11T13:00:39.193

Nothing conclusive, but here is what I have found...

If you hex dump the file and look at the start, you find 90eb and if you look for that throughout the file, you get this:

xxd a.raw | egrep "90eb"

0000000: 90eb 6f14 0202 fdfd 4e01 8002 0000 0000  ..o.....N.......
0000010: 90eb 6f14 8282 7d7d 4e01 8002 0300 0000  ..o...}}N.......
0000020: 90eb 6f14 c2c2 3d3d 4e01 8002 0000 8e08  ..o...==N.......
0034340: e773 2bf4 90eb 6f14 c2c2 3d3d 4e01 8002  .s+...o...==N...
0068660: 0301 0100 ca03 0104 90eb 6f14 c2c2 3d3d  ..........o...==

The data looks to begin 32 bytes after every 90eb. If the image is 640x333, there will be 213,120 bytes per image. So we can extract the basic planes/channels of the image like this with ImageMagick:

dd if=a.raw bs=1 skip=64 count=213120 | convert -depth 8 -size 640x333 gray:- a.png

dd if=a.raw bs=1 skip=213860 count=213120 | convert -depth 8 -size 640x333 gray:- b.png

dd if=a.raw bs=1 skip=427656 count=213120 | convert -depth 8 -size 640x333 gray:- c.png

Now we have a problem - the individual images are not positioned the same in all three images - you can see that if I animate the 3 frames together like this:

convert -delay 80 a.png b.png c.png -normalize  anim.gif

So now I am a bit lost - are there multiple cameras since the viewpoint seems to move?

I don't know - maybe my findings will inspire someone else! Let's see.

Another approach may be to compare the statistics - if you look at the "original" image's statistics, you get this:

identify -verbose original.png | egrep "Red:|Green:|Blue:|mean:|deviation"
    Red:
      mean: 5.77718 (0.0226556)
      standard deviation: 17.0501 (0.066863)
    Green:
      mean: 13.7015 (0.0537312)
      standard deviation: 38.4053 (0.150609)
    Blue:
      mean: 10.2863 (0.0403386)
      standard deviation: 30.1792 (0.11835)

If you now look at the statistics for the a.png, b.png and c.png as extracted above, you get this:

identify -verbose a.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
    Gray:
      mean: 2.48532 (0.00974635)
      standard deviation: 9.00678 (0.0353207)

identify -verbose b.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
    Gray:
      mean: 10.1611 (0.0398473)
      standard deviation: 30.2288 (0.118544)


identify -verbose c.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
    Gray:
      mean: 2.26135 (0.00886804)
      standard deviation: 7.43093 (0.0291409)

And there doesn't seem to be any correlation between the statistics of the "original" image and the putative "channels" of the extracted images... I think there is more going on here than I can guess.

Thank you For your effort, I did the same as you by C++ code. there are 3 image which have been shot by one camera in 3 moments. I got these three images via c++ code; but the problem is the noise you can see in every other pixels. so i removed the noise by averaging the value of that pixels' neighbors and set it to the noisy pixels. so my problem is what is that noises? or maybe each pixel have 16 bit data and every other pixel has no data — l3enQ, Nov 11 '15 at 12:54
Or maybe it is a Bayer matrix and there are actually 4 channels - RGBR like on a digital camera and that might explain the extra data... — Mark Setchell, Nov 11 '15 at 13:06
maybe that is the case. the original color image is almost green and blue. so if it is the case, how can I read it in the C++ and assign it to the pixels of picture? — l3enQ, Nov 11 '15 at 13:11
The method is called "de-mosaicing" but my thought was only hunch https://en.wikipedia.org/wiki/Bayer_filter — Mark Setchell, Nov 11 '15 at 13:15
Thanks for the great hint. It seems correct. so I will try to read the file and demosaicing it. i'll let you now how I get on — l3enQ, Nov 11 '15 at 13:20
Thank you very much. It worked. I tested it with Matlab. here is the code of Matlab > I = imread('mandi.tif'); J = demosaic(I,'bggr'); imshow(I); figure, imshow(J); — l3enQ, Nov 11 '15 at 13:55

What is the file format of the 16bit bitmap hex file?

1 Answers1