Standardize the color order in the sixel palette
In a standard sixel implementation, colors are assigned to the system color table in the order that they are defined. The first color defined in stored in entry 1 (not 0), the second in entry 2, continuing until it wraps around and stores the last color in entry 0. The reason for this ordering is because color table 0 is used as the background color, so it's best to avoid overwriting that unless absolutely necessary.
So lets consider an example palette on a hypothetical system with a color table size of 4.
#0;2;0;0;0#1;2;100;0;0#2;2;0;100;0#3;2;0;0;100
As far as the sixel image is concerned, the color numbers are going to map as follows:
- #0 is black
- #1 is red
- #2 is green
- #3 is blue
But the actual system color table will end up looking like this:
- Color table entry 0 is blue
- Color table entry 1 is black
- Color table entry 2 is red
- Color table entry 3 is green
This is not going to have any effect on the initial image (assuming you're not using the background color for anything), but let's see what happens when you output another image without defining a new palette. By default, the sixel color numbers will map to the color table entry with the same value, i.e. #0 will map to entry 0, #1 to entry 1, etc. So your second image will end up looking like this:
- #0 is blue
- #1 is black
- #2 is red
- #3 is green
You see the problem? If you want to reuse a palette across images while maintaining the same color mapping from the first image, you have to define them in the correct order, which means starting with color number 1. So the example palette given above should really be defined like this:
#1;2;100;0;0#2;2;0;100;0#3;2;0;0;100;#0;2;0;0;0
On non-standard sixel implementations the order shouldn't matter, because they'll likely always store #0 in entry 0, and #1 in entry 1, regardless of the order. But if you want to make sure the sixel color numbers are correctly mapped on a standard pixel implementation, it's essential you define the colors in the correct order.
And note that color 0 is always going to be problematic, because it depends on the color table size. If you know for sure that the terminal has a table size of say 256, then the 256th color that you set will update entry 0. But if color table happens to be bigger than that, then entry 0 will keep it's default color. It's probably easiest to just avoid relying on #0 as a usable color if you're planning to share a palette across multiple images.