I have made the boot image, and have got it down to 4 colors. What I don't understand is how it is possible to use KoS "convert.exe" (which requires a 2166 byte file) from the image I get out of photoshop. If I make the image 4 colors exactly and convert to BMP it comes out to be 2120 bytes. then as I add a single additional color to the image and then save as a 4bpp BMP file, it is physically impossible to come up with 2166. I have found that 15 colors yields 2164 and 16 colors yields 2168 bytes. I am really starting to get frustrated with this.

Is there another converter. The FAQ makes references to 3 converters, and I can only find KoS's. Any help would be great. I really want to try this, but it is a real pain... I made this image in about 1 hour, and have been working for the last 3 to get it the right file size.

Jason

p.s. I have included the file at 4 colors exactly...if anyone could convert it for me. I thought that i'd ask ;)

Hi !

I use PS to create that "2168" byte files that you mention ...
Photoshop tries to reach 4 Byte alignement, so it adds 2 zeo bytes at the end -> 2166 + 2 = 2168

So i use "hexworks" to load the file and delete the last two fill bytes, and ... VOILA ... i end up with a usable 2166 Byte file .
If i would need this every day i would wait for a good tool or write my own, but as i only change my bootup logo maybe once in a year or so ?!?!? I did it, and it worked ...

Nils

P.S. the other trick is to use PSP, it seems to produce the right 2166 byte image as a default, i never tried it, but people say so ...

Hexworks worked! Thanks a million. though, the image isn't bright. The white shows up dim. and about 3 pixels inthe whole image are bright. Plus all the edges of the images are notchy.

I will have to keep playing with it I guess. though, I followed the pixels to come up with the fact that the bright ones are the exact same color as the dim ones in the image. any other words of wisdom?

-J

Interesting. It sounds like KoS needs his converter to handle different variations in the BMP file format, and he's using Paint Shop Pro as his only baseline test. First step would be to allow a file that's two bytes too big...

As far as the discrepancies in color for the pixels, it's probably just that your paint program's palette isn't in the order that KoS's converter is expecting them in. Try PSP and see if that takes care of your problems.

I'd suggest to KoS that he allow .GIF input because it's better-standardized, but there's a lot more code involved in GIF decoding, and I don't think he's ready to put that kind of time into it.

This is all still very preliminary, the converter programs will develop and get better over time, and allow more types of input. When they settle down a bit, I'll update the FAQ. For now, KoS has the only Win32-exe that'll do the conversion. Bobo has a Java one, but he needs to have it linked from his main page... it's not linked at the moment (do a BBS search on Bobo's posts to find where he announced it), and Andy's isn't available yet.

___________
Tony Fabris

Hi !
Like Tony mentioned below, you probably have a pallete problem ...
As i had too, when i started, i created a simple image with OKAY pallette, that i use as a starting point, it is attached to this post ..
So simply do a copy of your image and paste it in the attached image, and its pallete will be used ...

Nils

Andy's isn't available yet.

Yeah, sorry guys. I've been having some pains in my wrist for the last week, so the thought of using my mouse for long in the evening after 8 hours in the office has put me off finishing my converter/uploader. It currently does little more that KoS's one, I am the process of adding the download functionality (I haven't yet decided whether to turn download.c into a DLL callable from VB or to re-implement download.c in VB directly). I shall probably go the DLL route as long as I can work get callbacks from C++ to VB working.

__
Unit serial number 47 (was 330 in the queue)...

How is the grey's that you sent me going to help?

I chose the colors I used by making them equally apart from one another. I took 255 and divided by 3. Then added that number ~85 to zero, then again, then again to get the 4 following colors:

000,000,000 Black
085,085,085 Dark Gray
170,170,170 Light Gray
255,255,255 White

I only used those colors and you would think that you could easily map them to the 4 distinct colors of the empeg. What 4 colors will Kos's program differentiate to the colors of the EMPEG? I think that If I have that info, then everything will be fine.

What 4 colors will Kos's program differentiate to the colors of the EMPEG?

KoS's program doesn't go by colors, I don't think, it goes by palette indices, so the order of the colors is more important than their actual shades.

In fact, I don't think it pays attention to the palette at all, come to think of it. It just locates the pixels in the .BMP file format and shuffles them around to fall into the correct places in the file that the Empeg wants. It completely strips any palette data out and ignores it. So whatever the values are (as stored in the BMP) are whatever falls into place on the Empeg screen.

Correct me if I'm wrong KoS...


___________
Tony Fabris

tony you're right... the palette is stripped... i only use the position of the colors in the palette (i think so ) ... is the program useful as it is with the color problem or isn't it tooo handy so ?

hey tony.. what have you meant with the "different variations in the BMP file format" ?

yup i've tested the program only with PSP and it worked for me

the thing with the two bytes and the end of the file would be no problem to change... can someone mail/send me please one file that's in that format so i can implement that in the program ?

the wohle thing with the GIF decoding is a bit to big for me... would be to much work for me i think...
if you can save the image as a GIF-file, you could save it also in BMP format, right?.. or why do you prefer the GIF-format ?

What have you meant with the "different variations in the BMP file format"?

It just appears that some programs like to save their .BMP files differently than others do. Hence the Photoshop version with the extra two-byte padding.

If you can save the image as a GIF-file, you could save it also in BMP format, right?.. or why do you prefer the GIF-format?

The only reason I mentioned it is because the .GIF file-format-specification is stricter and more well-documented, which might prevent problems like the one we just encountered.

___________
Tony Fabris

IT WORKED!!! I downloaded the evaluation of PSP 6 and just saved pretty much the exact same image (BMP) in PSP from photoshop, and Viola! It looks awesome on the screen. The funny thing is, I can't decide whether to go with the white background or the black. They both look AWESOME! Thanks Guys, for all your help!

KoS's program doesn't go by colors, I don't think, it goes by palette indices, so the order of the colors is more important than their actual shades.

I know this isn't very helpful at the moment, but my app goes by colours, not by palette indices, so this BMP should would work on my app when it finally appears.


__
Unit serial number 47 (was 330 in the queue)...

I was just sent an e-mail by David T-G, and he suggested that the library at http://www.imagemagick.org might help us out with these projects. I haven't tried yet, but it seems feasible. Anyone want to look at the stuff?

___________
Tony Fabris

Looks like a good site. I don't think I'll need it though. Loading the image in is dead easy, I just use the built-in picturebox control in VB (which allows you to load BMP, JPEG or GIF). It took me a while to work out how to get the actual data of of the picturebox once it was loaded, took a few API calls.

The manipulation of the image that is required is fairly straight forward because my app requires the user to provide a 128x32 bitmap. All that I need to do then is reduce the colours if there are two many and optionally reverse the palette.

__
Unit serial number 47 (was 330 in the queue)...