Graphics program that lets you load custom palette and save raw binary?
category: general [glöplog]
I need to do some very temporary prototype graphics for a little project.
Ideally I would want a graphics program that let me choose a custom resolution, load a custom 256-color palette, put down some pixels and then save the result as raw one-byte-per-pixel data correctly indexed.
Any recommendations?
Ideally I would want a graphics program that let me choose a custom resolution, load a custom 256-color palette, put down some pixels and then save the result as raw one-byte-per-pixel data correctly indexed.
Any recommendations?
any os?
GIMP does it.
jasc paint shop pro.
corel paint shop pro x2 can probably also do it, it's just also got more useless bloat.
corel paint shop pro x2 can probably also do it, it's just also got more useless bloat.
I use Grafx2 for such a thing, although the BMP file it writes have a header and palette, but the image data is raw byte/pixel format and begins 54+1024 bytes into the file. If one really need to be without the header and palette, it's not rocket science to cut it away :)
What I like with Grafx2 is that you have complete control over the palette and can easily move around colours with automatic remapping in the palette editor. Different colour sorts, reverted order etc, all with direct remapping. Another benefit is that you can select the bit depth of the palette so you can easily simulate ST, STe/Amiga, Falcon etc. Oh, that it's open source, free of charge and exist for a lot of platforms isn't too bad either :-)
http://code.google.com/p/grafx2/
What I like with Grafx2 is that you have complete control over the palette and can easily move around colours with automatic remapping in the palette editor. Different colour sorts, reverted order etc, all with direct remapping. Another benefit is that you can select the bit depth of the palette so you can easily simulate ST, STe/Amiga, Falcon etc. Oh, that it's open source, free of charge and exist for a lot of platforms isn't too bad either :-)
http://code.google.com/p/grafx2/
Ah, forgot to mention that it should be a Windows program.
Thanks for the suggestions. Grafx2 seems to be small and free, so I'll give that a try for starters! :)
Thanks for the suggestions. Grafx2 seems to be small and free, so I'll give that a try for starters! :)
Why we didn't add raw output to GrafX2 yet :
It allows you to save, but not load back your picture as GrafX2 can't figure out the palette and resolution. But if you need a specific format, please tell us. For example we added .scr for cpc and some others for c64. The scr format for CPC actually saves the palette as a separate file, so you can still reload it easily.
Feel free to ask if you have any special need anyway :)
It allows you to save, but not load back your picture as GrafX2 can't figure out the palette and resolution. But if you need a specific format, please tell us. For example we added .scr for cpc and some others for c64. The scr format for CPC actually saves the palette as a separate file, so you can still reload it easily.
Feel free to ask if you have any special need anyway :)
what skrebbel said... get some abandonware version of paint shop pro 6 or 7
PulkoMandy: Thanks for the offer, but following evil's suggestion was more than good enough.
I just hacked together a quick util that stripped the BMP-header (and reversed the bitmap lines, I wonder what kind of weird idea is behind the reverse-line order of the BMP format) and it worked like a charm.
I just hacked together a quick util that stripped the BMP-header (and reversed the bitmap lines, I wonder what kind of weird idea is behind the reverse-line order of the BMP format) and it worked like a charm.
from GrafX2 sourcecode comments :
And yes... it's strange :)
I think it was related to the format being used for printing pictures and the printer wanting the data this way or something like that.
Quote:
At Microsoft, they said: "Let's put the colors in reverse order, and to piss them off, let's put them on a scale from 0 to 255 because the VGA standard uses 0 to 63 (logical!). And as that's not stupid enough, let's add an always-zero byte to force people to buy big hard disks... This way, they won't complain too much when we get Windows 95 out...
Then Bill said: "OK guys! But only if you put the pixels in reverse order, but vertically only, because it would be really too annoying.
And yes... it's strange :)
I think it was related to the format being used for printing pictures and the printer wanting the data this way or something like that.
Grafx2 or I-Mage...
http://memecode.com/image.php
http://memecode.com/image.php
The BMP format is the way it is because ...:
- The palette entries are stored as little-endian 32-bit words. In memory, they are laid out as 0xAARRGGBB (RGBA, 8 bits per channel), but on disk, they are BB GG RR AA, usually with AA = 00 due to the absence of a real alpha channel.
- The scan lines are stored in reversed order because in OS/2 (where the BMP format originally comes from) the coordinate system was laid out like mathematicians would do it, with the origin in the lower-left corner and the positive Y axis pointing upwards.
The only thing that's really strange about BMP is that each scan line is 32-bit aligned. So there might be some padding at the end of each line if the image size is not divisible by 4 (unless you happen to use a 32-bpp format).
- The palette entries are stored as little-endian 32-bit words. In memory, they are laid out as 0xAARRGGBB (RGBA, 8 bits per channel), but on disk, they are BB GG RR AA, usually with AA = 00 due to the absence of a real alpha channel.
- The scan lines are stored in reversed order because in OS/2 (where the BMP format originally comes from) the coordinate system was laid out like mathematicians would do it, with the origin in the lower-left corner and the positive Y axis pointing upwards.
The only thing that's really strange about BMP is that each scan line is 32-bit aligned. So there might be some padding at the end of each line if the image size is not divisible by 4 (unless you happen to use a 32-bpp format).
you can write out the pixels in top-to-bottom order in BMP files, if you specify a negative height in the bmp header..
Quote:
if you specify a negative height in the header
bmp is evil
AGAIff on Amiga :)
keyj, nice info :-)
bartman, if i would code a bmp reader, i'd choke on that :)
bartman, if i would code a bmp reader, i'd choke on that :)
keyj, I am not sure if the coordinate system was the reason for reverse-order vertical scanlines but from what I heard it was because the on-chip framebuffer of VGA chips was upside down, so it didn't require another hefty operation of reversing when writing. I might be wrong though this is just hearsay :).
Decipher: No, the CGA/EGA/VGA framebuffer is laid out from top to bottom, as one would expect. (Countless PC democoders can confirm that ;) But you may be right anyway, it's possible that some other graphics chip had that unusual framebuffer layout -- given that OS/2 originally comes from IBM, I'd suspect the 8514/A, but that's just a wild guess.
Regarding top-down bitmaps: Yes, that's a viable alternative and works OK, but I remember that this is an addition to the format that wasn't available until Win32 or so. This means that some older or hand-crafted BMP readers (like skrebbel's hypothetical one ;) might not handle those files correctly.
Regarding top-down bitmaps: Yes, that's a viable alternative and works OK, but I remember that this is an addition to the format that wasn't available until Win32 or so. This means that some older or hand-crafted BMP readers (like skrebbel's hypothetical one ;) might not handle those files correctly.