What is the image dump format used by jetbook?

I was looking the file structure of Jetbook Lite and found some files with .bin extension with a size of 215040 bytes

They are the fullscreen images of option menus, the bookpile picture, etc. They are dumped directly to the screen like this:

cat filename.bin > /etc/fbdev0

I am trying to do some translations but I can't figure how to transform to that screendump format.

215040 bytes don't translate directly to a 640x480, 8 bits per pixel image. In fact, it doesn't translate to a integer depth color

Due some observations I think that they are 448x480, 8 bits per pixel stretched to 640x480.

Anyway, someone from Ectaco can point me to what tool was used to convert images to that file dump format and/or give more details about that raw image type that is being used?

jorlando wrote:I was looking the file structure of Jetbook Lite and found some files with .bin extension with a size of 215040 bytes

They are the fullscreen images of option menus, the bookpile picture, etc. They are dumped directly to the screen like this:

cat filename.bin > /etc/fbdev0

I am trying to do some translations but I can't figure how to transform to that screendump format.

215040 bytes don't translate directly to a 640x480, 8 bits per pixel image. In fact, it doesn't translate to a integer depth color

Due some observations I think that they are 448x480, 8 bits per pixel stretched to 640x480.

Anyway, someone from Ectaco can point me to what tool was used to convert images to that file dump format and/or give more details about that raw image type that is being used?

Hi,

Thanks for the question! Unfortunately this is definitely above my tech knowledge, it might be best to contact someone form tech support directly with the question. You can email [email protected] and hopefully they can help out.

Thanks, I'll ask. The format is confuse...

640 x 4 (16 gray tones, 4 bits) = 2560
448 x 8 = 3584

3584 - 2560 = 1024 bits.

I can't figure how these extra bits are used...

It seems to be 480 lines with 448 bytes each. Maybe it's some 5bit 6bit scheme to fit 3 pixels in 2 bytes? So 640 columns would be possible. The rest of the line may be zero padding to fill the screen buffer.

But that's only my quick guess.

I don't think so. I think that the extra bytes are due to some quirk of the LCD controller.

I found that 448 value looking some pattern repetition in the dump file.

The best that I could manage was to copy the first 256 bytes from a 4 bit grayscale bitmap and overwrite the dump. The result umas a rough quality image, with some artifacts that seems to indicate that some parts of the image are offset from the actual position.

The dump is 480x640, the problem is to figure the meaning of the extra bytes.

If the screen has 16 gray tones, it needs 4 bits.

640x480x4 = 1228800 bits

215040x8 = 1720320 bits

1720320-1228800 = 491520

491520 / 1024 = 480

So each line needs 1024 extra bits. Why? Addressing? Mode setting?

Let's hope that someone from support can give us the answer.

This message was edited 1 time. Last update was at 12/04/2010 18:03:33

Almost there...

There is really extra 128 bytes (1024 bits) at the end of each line in the image dump.

I wrote a small bash script to strip the extra bits.

To the resulting file I added the 118 bytes header of a 4 color 640x480 bmp image

I could open the resulting file without adding the header with irfanview as a raw image file, but since it can only open raw files with a minimum of 256 color the resulting image has the lower half empty and the upper half with two duplicate images of 320x240.

I will try to find a way to add extra bits to the raw image and to compare the stripped bytes to see if it is a constant value or something else.

====================================

#!/bin/bash

VALIDO=320

# extract image from jetbook`s internal image.bin files

for i in {0..214592..448}

do
dd bs=1 skip=$i count=$VALIDO if=4.bin.raw of=saida > /dev/null 2>&1
cat saida >> dump4.raw
done

exit 0

One image worths a thousand words...