Color wrong

[mritter0]

Am I going insane?

WinUAE OS3.9 AGA 1280x1024x32 RTG

I open an icon in IconEdit that is 8bit optimized. Displays just fine. Displays fine in windows (folders).

I use Icon2C to convert icon (just need the normal image) to C source code. It says it is 8bits. Compile program. Colors ALL messed up. I am not specifying a palette since using 7 totally different images with their own palettes.

Why are the colors wrong? AGA is 256 colors. Can't GadTools handle 8bit images? Can't Icon2C handle 8bit images properly? I am banging my head against the wall on this one.

[thomas]

I am not specifying a palette since using 7 totally different images with their own palettes.

That's your problem. The image structure only holds the pen numbers for each pixel. Colors for the pens are taken from the screen's palette.

So, to handle built-in images in your program you have to

- either convert all images to use the same palette before you convert them to C. In your program open a screen using this palatte, then you can directly DrawImage() the images into that screen.

- or write a routine which remaps an image from its palette to a given screen's palette. Then use this routine with each image before you draw it into your window.

Another way to use images with proper colors in your program is to keep all images as files on disk and use datatypes.library to load these images. Then datatypes will take care of the remapping.

[mritter0]

The pens dawned on me last night in bed. I am using a bare bones program just for testing. Opening in a window on Workbench, not a custom screen.

Will LockPubScreen() and GetPens() (or whatever. I will try them all) fix it? I think I am missing a simple step.

[thomas]

I fear there is no simple method to make this work. You have to remap your images to the screen's palette and there is no help from the OS for this, at least not before OS 4.0.

Check the pixelarray.c example on my homepage: http://thomas-rapp.homepage.t-online...les/index.html

[mritter0]

Now I am really frustrated. I used 2 of my old programs (Tool Type Editor and Icon Copier) to load/display the icons.....worked like a charm. Unfortunately, I no long have the source code. I figured it out 20 years ago. I will figure it out again.


Great web site, btw!

[thomas]

Erm, icons are different from images as they do not depend on a specific palette.

If you use 4-colored OS 3.1-style icons, they always look kind of right because only one color can be changed. Black and white are fixed, pen 0 is transparent and only the fourth pen can change its color.

If you use 8-colored MagicWB-style icons, they look right if you have MagicWB installed because MagicWB fixes all 8 pens.

If you use NewIcons or GlowIcons then newicon.library or icon.library (in OS 3.5+) takes care of the remapping.

But if you want to built images into your program, then nobody but you can remap the bitmaps.

The only way to let the system remap your images is if you load the images from disk with datatypes or as icons.

[mritter0]

I am using 8bit icons, so yes, icon.library is handling the palette. Sucks. I really don't want the images external.

Icons are just (struct Image *) images, same as a picture. Icon.library uses datatypes.library for 8bit and 32bit, yes? But I am still in the same boat with internal images.

Back to the drawing board....

[thomas]

Icons are just (struct Image *) images, same as a picture.

No.

This is only true for OS 3.1 and below built-in icons. And similar to your internal images, they look differently on each user's palette.

Beginning with NewIcons the .info file is extended with an (undocumented) part which contains image data as well as palette data. Newicon.library transparently remaps the image into the screen's palette and pokes the remapped image into the struct Image pointed to by the struct DiskObject. But this remapped struct Image is a different one than that stored in the .info file. And the pens only stay valid until you FreeDiskObject() the icon.

In OS 3.5 icon.library was extended so that you can access the new image/palette part with OS functions. In OS 4.0 the new part was extended to understand 32bit images, too. These are not supported by OS 3.9 and below.

Icon.library uses datatypes.library for 8bit and 32bit, yes?

No. It contains its own code to load and remap images from .info files.

[mritter0]

I tried some more hacks, but no luck. I have one more I am going to try; maybe.

I use datatypes now to load the images and it works fine. Just not my preferred method of having external images. I don't want the user to be able to change/modify them.