-map shuffles colormap

[FrankM]

Hi all,

I am struggling with the following. I have two Windows BMP files, both 4-bit indexed using the "standard" windows colormap. I have to combine both (compose), but if I do this without further action the resulting file is a 24bit DirectClass BMP. I need this BMP to use exactly the same colormap as the original images, so I used -map. This applies the colormap, BUT shuffles the colors. I was a bit surprised by this, although I can see some reason for it: the set of colors is equal to the original map, so why bother with the order.

Well... in this case the image must be fed by some kind of hardware (PLC) that is programmed to act on index numbers (and not read the associated colors). So it want index 11 for yellow, 9 for red and 0 for black. Is there any way I can accomplish this? The "sad" thing is that the colormap remains intact throughout the complete process: although the image changes to DirectClass the colormap stays unchanged (but obviously it is not used). As soon as I use the -map action the colormap changes.

Hope someone can help me here. I'll attach some colormap info below. Please note: if there is a way to revert the image back to PseudoColor without applying a map and without the image being optimized, that is a solution too...

Kind regards,

Frank

===
Reading 3 files: a unique pixel file and the two images involved in the composition (first will be destination)

Code: Select all

0 :         0,0,0,0          0,0,0,0          0,0,0,0
1 :     32896,0,0,0      32896,0,0,0      32896,0,0,0
2 :     0,32896,0,0      0,32896,0,0      0,32896,0,0
3 : 32896,32896,0,0  32896,32896,0,0  32896,32896,0,0
4 :     0,0,32896,0      0,0,32896,0      0,0,32896,0
5 : 32896,0,32896,0  32896,0,32896,0  32896,0,32896,0
6 : 0,32896,32896,0  0,32896,32896,0  0,32896,32896,0
7 : 32896,32896,328  32896,32896,328  32896,32896,328
8 : 49344,49344,493  49344,49344,493  49344,49344,493
9 :     65535,0,0,0      65535,0,0,0      65535,0,0,0
10:     0,65535,0,0      0,65535,0,0      0,65535,0,0
11: 65535,65535,0,0  65535,65535,0,0  65535,65535,0,0
12:     0,0,65535,0      0,0,65535,0      0,0,65535,0
13: 65535,0,65535,0  65535,0,65535,0  65535,0,65535,0
14: 0,65535,65535,0  0,65535,65535,0  0,65535,65535,0
15: 65535,65535,655  65535,65535,655  65535,65535,655

After the composition the list is the same, but as soon as I apply the colormap of the first image (unique pixel) this happens:

Code: Select all

0 :         0,0,0,0          0,0,0,0          0,0,0,0
1 :     32896,0,0,0      32896,0,0,0      32896,0,0,0
2 :     0,32896,0,0      65535,0,0,0      0,32896,0,0
3 : 32896,32896,0,0      0,32896,0,0  32896,32896,0,0
4 :     0,0,32896,0      0,65535,0,0      0,0,32896,0
5 : 32896,0,32896,0  32896,32896,0,0  32896,0,32896,0
6 : 0,32896,32896,0  65535,65535,0,0  0,32896,32896,0
7 : 32896,32896,328      0,0,32896,0  32896,32896,328
8 : 49344,49344,493      0,0,65535,0  49344,49344,493
9 :     65535,0,0,0  32896,0,32896,0      65535,0,0,0
10:     0,65535,0,0  65535,0,65535,0      0,65535,0,0
11: 65535,65535,0,0  0,32896,32896,0  65535,65535,0,0
12:     0,0,65535,0  0,65535,65535,0      0,0,65535,0
13: 65535,0,65535,0  32896,32896,328  65535,0,65535,0
14: 0,65535,65535,0  49344,49344,493  0,65535,65535,0
15: 65535,65535,655  65535,65535,655  65535,65535,655

[FrankM]

Should I consider this being a stupid question? (I had expected at least one answer...)

Regards,
Frank

[anthony]

At this point IM generates a color map for pallette image basied on its own internal handling of the colors, and not according to any specific color ordering by input programs and files.

It does this on the premise that the image format does not care about the color ordering (except is spacial cases), and that is a valid premise.

If you like to take this further you will have to report the problem to the sevelopers list, though I expect it would not be a high priority. The other alturnative is for you to try and figure out the IM BMP coder and fix it yourself.