True colour image not converting properly/translation?

[albiongeck]

Perhaps there could a be settings entry for a more accurate lookup with increased performance hit?

[Enjay]

Just moving the description of the actual (suspected) bug to the new page.

...The bug is not that translations are messed up.

The real bug (as far as I'm concerned) is that ZDoom is incorrectly converting a colour in a true colour image when it is fitting it to the Doom palette. If a true colour image contains an area that is R11, G23, B7 (ie exactly the same colour as palette entry 127) when ZDoom converts the graphic to the Doom palette, it converts this area to R15, G23, B0 (palette entry 12).

...surely if an area in a true colour image is an exact match for one of the palette entries, that's what it should be mapped to when the graphic is shown in the game palette? I also think that it is reasonable for modders to expect that behaviour.

Perhaps there could a be settings entry for a more accurate lookup with increased performance hit?

I don't know how expensive this would be processor-wise but perhaps if it is just for a handful of palette entries, then they could specifically be checked for. e.g. as far as I know, R11, G23, B7 is the only colour in the Doom palette that shows this problem (though I haven't checked thoroughly). Perhaps an "is the colour R11, G23, B7, if so map to 127, if not do the 15-bit lookup instead" check might not be too problematic? For all I know, a similar check for all the 256 colours in the palette may not be too expensive. Perhaps an "is this pixel one of the following 256 colours" check before the 15-bit lookup might be suitable?

[randi]

It's not about the lookup table, per se. More accurately, truecolor to palette conversion operates in RGB555 colorspace and not RGB888 colorspace. This is small enough that it can be done using a 32k lookup table, and the whole conversion can be done just by lookup up each color in the table without much work. Plus, the lookup table was already there for blending effects, so it made sense to use it here too.

To use RGB888, a lookup table is prohibitively large. In a worst case scenario, using RGB888 is 256 times slower than RGB555, because it would need to scan every palette entry for every pixel in the image.

[Enjay]

So is there any way to deal with a known inaccuracy such as this or would having any specific colour check make things prohibitively slow?

It's not really bothering me particularly but I can imagine, for example, an enemy that has most of its sprites in the Doom palette but, perhaps, the firing frames have a nice flash and so use a true colour frame for those graphics so that they can look prettier in GZDoom (I've done things like this myself). However, in ZDoom, if the sprite used colour index 127/R11G23B7 somewhere on it, the colour of the actor would change (albeit subtly) as it switched between the paletised images and the true colour ones.

[Graf Zahl]

It's too slow, plain and simple. To do a proper lookup it'd have to check each and every pixel in the image for each and every color in the palette. Right now the lookup is one simple indexing operation, it'd have to be changed into a loop that runs 255 times, once for each palette entry.

[Enjay]

Fair enough. It's a minor problem. It would be nice if it could be addressed but if doing so would have an appreciable performance hit I can understand not addressing it. I guess it's just something to keep in mind when using true colour images.

Just out of curiosity, what is done differently with paletised images? I don't mean pngs in the Doom palette. I mean an 8 bit png that is using a palette other than the game one. If such an image has an area that is R11G23B7, it gets mapped correctly in the Doom palette. So, there must be something different being done to handle the palette matching in such images.

[Graf Zahl]

A full lookup of 256 colors is a vastly different thing than a lookup of, say 128x128 separate pixels. It's affordable when using a palette.

[Enjay]

So, for a paletised png, ZDoom looks at the image palette and matches the entries in it to the game palette rather than looking at each pixel in the image and doing the match there (which, presumably it has to do for a true colour image)?

If so, I can see how that would be less expensive and get more accurate results too. thanks for the info.

[Graf Zahl]

Yes, precisely.