I won't post C source code since I don't have any, but I will tell you the way the file format works and you can write your own. You're going to have to make some personal decisions about how your code manages the thresholds and you need to know the reasons behind your decisions before you implement.

Okay, here's how it works.

The Empeg display has four shades of color. Each of the VFD pixels is either off or on, and there is a 200hz "time-dither" to produce shades of gray that fall in between "off" and "on". Theoretically, you could have many shades of gray inbetween, but almost all of those shades are very flickery-looking, so the Empeg folks gave us only two shades of gray in addition to black and white. Those shades are 11.1% (pixel is lit 1/9 of the time) and 20% (pixel is lit 1/5 of the time). So you have "off" (black), two shades of gray, and "on" (white), for a total of four colors.

In truth, as I discovered, the two shades of gray don't visibly appear to be 11% and 20% gray, the actual perceived brightness is quite a bit higher than that. So you can't use a straight mathematical conversion from bitmap->logo because there's no hard-and-fast way to determine how the pixels from your monitor translate into empeg screen shades.

In the end, I simply eyeballed the colors and chose arbitrary cutoff points in my editor. Depending on your screen and your eyeballs, you might choose different cutoff points. Here's what my current cutoff points are in my software:

GrayCutoff0 = 30
GrayCutoff1 = 93
GrayCutoff2 = 200

What this means is that all bitmap values between 0 and 30 (on a scale of 0-255) will be black on the empeg. Everything between 31 and 93 gets assigned the empeg's 11% gray level. Everything between 94 and 200 get assigned 20% gray, everything above 201 goes white.

Then, when I show these colors on the Windows screen, they get displayed as these shades:

GrayDisplayValue0 = 0
GrayDisplayValue1 = 91
GrayDisplayValue2 = 115
GrayDisplayValue3 = 255

Eventually I plan to make these values user-configurable, so that folks can adjust the editor to their monitors and eyeballs.

Okay, now that you understand how the cutoffs work, now on to the actual file format.

The file format is as follows:

4 bytes: Ascii characters "empg".
2048 bytes: "Home" image logo data.
2048 bytes: "Car" image logo data.
Total: 4100 bytes.

The way the logo data is arranged is as follows.

Each pixel is represented as a straight number from darkest to lightest: 0 for black, 1 for dark gray, 2 for light gray, 3 for white. The pixels are combined (inefficiently, I might add) so that two pixels are stuffed into the two nibbles of one byte. Like so:

Pixel 1: Lower nibble of first byte.
Pixel 2: Upper nibble of first byte.
Pixel 3: Lower nibble of second byte.
Pixel 4: Upper nibble of second byte.
(etc.)

So the code to translate RGB values into bytes for the file goes something like this (shown in pseudo-code since I only have a VB version which is mostly useless if you plan to code in C):

(Create a fresh file here, and write the
four bytes of the ascii characters "empg" to the file)

For Y = 0 To 31
For X = 0 To 127 Step 2

(Get GrayLevel from source image at (X, Y))
Select Case GrayLevel
Case 0 To Cutoff0
RawNibble = 0
Case (Cutoff0 + 1) To Cutoff1
RawNibble =1
Case (Cutoff1 + 1) To Cutoff2
RawNibble = 2
Case Else
RawNibble = 3
End Select

(Get GrayLevel from source image at (X + 1, Y))
Select Case GrayLevel
Case 0 To Cutoff0
RawNibble2 = 0
Case (Cutoff0 + 1) To Cutoff1
RawNibble2 =1
Case (Cutoff1 + 1) To Cutoff2
RawNibble2 = 2
Case Else
RawNibble2 = 3
End Select

BothNibbles = (RawNibble2 * 16) Or (RawNibble)
// (That's a "binary" OR in VB, I think a "+" would work too?)

(Write the "BothNibbles" byte to the file here)

Next X
Next Y

(Go on to the second image here and do the same
thing a second time.)

Does that help?

___________
Tony Fabris
_________________________
Tony Fabris