bitmap creator

Hello I need to creat a litle bmp image for a graphic discplay KS0108.I was looking in the exemples of the glcd v2 library but I cant find a easy way to build the image.h which contains an array with the bitmaps of a bmp.How can I just drow a simple image on paint and then convert that small image to display on display? Any help Thanks for your time

If you have a small image in BMP you need to open it in a hexidecimal editor to see the bytes values.
But be aware that the BMP header must be skipped.

Advise, write a small program that do the extraction for you and write out the bytes in a .h file

The layout of a BMP file can be found on - http://en.wikipedia.org/wiki/BMP_file_format -

(It might look overwhelming, just go step by step,

  • first extract the size (green part)
  • then extract the offset (green part)
  • start reading at the offset: read binary in, write ascii out, add commas etc (yellow part)
  • etc.

If it works you can post it here of course!

Succes,
Rob

The the glcd v3 library comes with a tool to do the bmp to .h conversion for you. It comes with a java app down in glcd/bitmaps/utils/java. Unfortunately, there are a few issues with Nautilus on Ubuntu (which based on your avatar and signature I assume you are running). Nautilus does not set the current directory to the currently selected/viewing directory. I as well as many others consider this a bug, the Nautilus maintainers do not consider this a bug and say that no program should make assumptions as to the current directory when started. (other tools don't take this view) That issue can be worked around. But there is also some kind of drag and drop JAVA issue when used with Nautilus that we have not been able to work around which prevents the java app from being able to get the bmp file for conversion.

It does work on Windoze, so if you are willing to use Windoze you can fire up the java app and then simply drag and drop the bmp file into the java app window and it will do the conversion to a .h header file and update the appropriate header files under glcd/bitmaps

I do have a yet unreleased command line version that will do a bmp to .h conversions as well. It is basically a slightly modified version of Sami Varjo's bmp2glcd conversion tool: http://sourceforge.net/projects/bmp2glcd/

to work with the arduino ks0108 v2 and glcd v3 libraries.

PM me and I'll send you more information if you are interested in that tool.

--- bill

Is this anything like the .xbm format? If so, ImageMagick would handle the conversion ("man convert").

Chagrin: Is this anything like the .xbm format? If so, ImageMagick would handle the conversion ("man convert").

Blast from the past. It had been a long time since I looked at that. After going back and carefully reviewing the data formats, it does appear that the pixel ordering and byte ordering is the same. However, (before my time on the glcd library) the glcd library deviated slightly from the XBM format in order to make it simpler to use bitmaps. The format of the data was modified to include the size information as well as the bitmap data. This allows the bitmap API to use a single/simple pointer to a bitmap and not have to pass around the sizing information. So it appears that the only difference between the bitmap format that the glcd library wants and XBM format is that that the first two bytes of the glcd library data array represent width and height. It wouldn't be that difficult to write a perl or awk script to modify an XBM file header into a glcd library bitmap header. It has to insert the width and height into the data array and also change the declaration to use PROGMEM.

But for now, assuming there are not lots of files to convert, it could easily be done by hand in just a few seconds per file.

--- bill

Ok in actually going and looking even closer at the XBM format along with the library bitmap rendering code,
I realized that the XBM format is not compatible with the existing bitmap rendering.
The existing bitmap format in the bitmap headers is stored in the exact same format as GLCD memory:
Top to bottom and left to right.
XBM format is stored in the bytes the same way a CRT paints pixels. From left to right and top to bottom.
While both formats have their 0,0 origin in the upper left corner, they don’t map the pixels in
the data array the same way.

If you would like to be able to draw XBM bitmaps on the glcd,
here is a working example of a rendering routine that can render XBM bitmaps on the glcd display:
While it isn’t optimized for speed since I tossed it together in just a few minutes, it does perform
acceptably well.

void DrawXBM(uint8_t x, uint8_t y, Image_t xbm, uint8_t width, uint8_t height, uint8_t color_fg, uint8_t color_bg)
{
uint8_t xbmx, xbmy;
uint8_t xbmdata;

	for(xbmy = 0; xbmy < height; xbmy++)
	{
		for(xbmx = 0; xbmx < width; xbmx++)
		{
			xbmdata = ReadPgmData(xbm + xbmx/8 + xbmy*((width+7)/8));
			if(xbmdata & _BV((xbmx & 7)))
			{
				GLCD.SetDot(x+xbmx, y+xbmy, color_fg); // turn pixel on
			}
			else
			{
				GLCD.SetDot(x+xbmx, y+xbmy, color_bg); // turn pixel off
			}
		}
	}
}

This routine can be tossed directly into your sketch. It would require changing the declaration of the array
in the .xbm file to have a PROGMEM but that is all.
This routine does not assume the width & height are part of the data like the existing DrawBitmap()
and you call it directly by name DrawXBM() rather than GLCD.DrawXBM()

Supporting XBM format seems like a good thing to do.
I’ll start a discussion for it over on the glcd v3 thread here:
http://arduino.cc/forum/index.php/topic,56705.0.html

— bill

bperrybap: Ok in actually going and looking even closer at the XBM format along with the library bitmap rendering code, I realized that the XBM format is not compatible with the existing bitmap rendering. The existing bitmap format in the bitmap headers is stored in the exact same format as GLCD memory: Top to bottom and left to right. XBM format is stored in the bytes the same way a CRT paints pixels. From left to right and top to bottom. While both formats have an their 0,0 origin in the upper left corner, they don't map the pixels in the data array the same way.

Wouldn't it be easier to just flip the image? The convert command includes -flip (vertical) and -flop (horizontal) options.

Chagrin: Wouldn't it be easier to just flip the image? The convert command includes -flip (vertical) and -flop (horizontal) options.

I guess my description may have been a bit misleading/wrong. The GLCD format isn't really top to bottom and then left to right. It is left to right but 8 pixels high at a time. (The 8 pixels are top to bottom)

So it isn't as easy as flipping the image. Flipping the image does not alter how the image pixel data is stored in the byte array. flip and flop only transpose the image data but not the format of the stored pixel data bits. Even if the image is flipped, the pixels will still be stored left to right 1 pixel at a time from the right edge to the left edge and then top to bottom instead of left to right 8 pixels at a time.

The dilemma is that both formats store pixel data from left to right but not by the same amount in height. The XBM format moves from left to the right of the image 1 pixel height at a time while the glcd format moves from left to right with a 8 pixel vertical "page" height at time. glcd format does not paint top to bottom of the full image 1 pixel wide and then go left to right. glcd paints an 8 pixel tall path from left to right. So each byte in XBM is 8 pixels in a 1 pixel tall row until you hit the right edge of the image, while with GLCD each byte is 8 vertical pixels tall until you hight the right edge.

So what happens if you attempt to interpret the XBM format as glcd format, is that the second byte of data will draw 8 vertical pixels just the right of the first 8 pixels rather than below the first 8 pixels. So the image isn't just rotated, it is all scrambled. The only way to fix this is to interpret the XBM data differently than the glcd format data.

Had glcd format drawn from top to bottom of the image then gone left to right, the image data would have worked, it would have just been rotated. The reason they went left to right 8 pixels at time for glcd format is that is the optimum way to write to the display for speed.

I looked over all the formats supported by convert and nothing jumped out at me as this format.

--- bill