6 replies to this topic

[sitedude]

I am trying to find a simple way to replace images on an Innotab (kids vtech device)

The images are stored in a SQLite database in Blob Format.

The images are Bmp 5-5-5 (without a header)

I am able to view them using an AutoIT script

http://pastebin.com/v2dyRyBG

The above link is the auto it script

the "SELECT thumbnail FROM Games_info where pkey='3'" pulls the blob file from the database

Here is the blob file I saved directly from the database

http://wikisend.com/download/239802/blobthumbnail

Does anyone know an easy way to possible edit this blob file? Or a way I can make a 57x57 a 5-5-5 bmp blob without a header so i can insert it into the SQLite db?

[Endurion]

The file contains two dwords with width and height, and then the plain image data (2 bytes per pixel).

If you don't have a program that can work with that kind of data, the simplest way would be to write a programm to append/remove a image header of a format than can store that data.

I'd suggest BMP or TGA, both allow the pixel data in exactly that format.

[sitedude]

Thats a great idea! Would Paint Brush do the trick? I have Gimp also. I heard that the header of a bmp is the first 54 bytes. So If I some how made a 5-5-5 image then used a hex editor to remove the first 54 bytes that would work?

Can you recommend a program to save in bmp 555 format?

[sitedude]

Also I think I could use this command to trim the first 54 on a modified image

tail -c +54 image > image2

[Endurion]

The problem is that most paint programs do not cater to 16 bit 5-5-5 (or 5-6-5 ) color depth.

Here, try this, it's a hex dump of 16bit bitmap header for a 57x57 image. Since you seem to do Linux/Unix I think you can use one of the shell tools to convert it to binary. The problem I fear is that bitmaps do use padding (4 bytes per line), so that probably won't work.

42 4D 0A 1A 00 00 00 00 00 00 36 00 00 00 28 00
00 00 39 00 00 00 39 00 00 00 01 00 10 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00

Edited by Endurion, 08 December 2012 - 01:53 PM.

[Servant of the Lord]

The problem I fear is that bitmaps do use padding (4 bytes per line), so that probably won't work.

Just 'cause I'm curious, are you saying every bitmap format aligns each line of pixels to 4 bytes?
Or that, regardless of the length of a line, there are 4 empty bytes at the end of each one?

And is the first bit or the last bit of a 16-bit 555 bitmap pixel the ignored bit?

[Endurion]

The problem I fear is that bitmaps do use padding (4 bytes per line), so that probably won't work.

Just 'cause I'm curious, are you saying every bitmap format aligns each line of pixels to 4 bytes?
Or that, regardless of the length of a line, there are 4 empty bytes at the end of each one?

And is the first bit or the last bit of a 16-bit 555 bitmap pixel the ignored bit?

Not every bitmap format, only the Windows BMP format AFAIK.

Every line of pixels is padded to a full multiple of four bytes. The padding bytes are added at the end of a line. 16-bit bitmaps are always stored as 5-5-5, xRRRRRGGGGGBBBBB, unless the color masks in the header say otherwise. For simplicity sake the color masks in the sample hex dump are set to 0, then xRRRRRGGGGGBBBBB is the default.

Edited by Endurion, 08 December 2012 - 11:55 PM.