True colour image not converting properly/translation?

[Enjay]

2.8pre-37-gf0feee3

Load the attached file and summon actors test01, test02, test03 and test04.

The actors are simple 1 frame actors that use a translation. The actors use graphics TESTA0, TESTB0, TESTC0 and TESTD0 respectively.

TESTA0 is a true colour PNG.
TESTB0 is a palette optimised PNG
TESTC0 is a Doom graphic
TESTD0 is a full palette (unoptimised) PNG

All the sprite images look the same and all use colours in the Doom palette. Sprites B-D look as intended with the translation (dark-grey bodies, red helmet). Sprite A, however, does not. There is an area of the sprite that remains green. It uses the colour R11, G23, B7 before translation. In the game palette, this is colour 127. For some reason, it seems that the true-colour nature of the graphic is upsetting ZDoom and the dark green is not being translated.

---

I don't know if it is relevant or not but when I looked at the above screenshot (in its original resolution) in Paint Shop Pro, PSP told me that the green colour was R15 G23 B0 which is palette entry 12, not 127.

[The Zombie Killer]

I thought true colour PNGs weren't supported in software mode for anything other than UI, HUD or weapons

-TZK

[Enjay]

ZDoom should not show them in true colour but it should convert them to the game palette properly. It seems, as if the conversion is going wrong and a colour that is the exact same match for palette entry 127 is getting converted to some other value (probably 12) instead.

This also affects GZDoom BTW. Normally I don't think that it would be a problem in GZD because the sprite would be shown in its original colours. However, because the sprites in this example are using translations, GZDoom converts them to the game palette before applying the translation and, again, the conversion seems to get this entry wrong and so the translation looks much as it does in the screenshot in GZDoom too.

[The Zombie Killer]

Maybe there's an issue in the code somewhere that's causing it to convert it to the palette entry specified, minus the last number?
Eg, like you said 127 is turning into twelve. See if something like 100 turns into 10.

-TZK

[Enjay]

I can't check but I'm sure if it was something like that, the translation in my example would be much more mixed up. Quite a large number of palette entries are included in the translation but knocking the last digit off of them would put all of them out with the ranges specified in the translation so the sprite would appear pretty much in its original totally wrong colours (which is a green body and blue helmet).

[Gez]

Do not expect palette translation to work for non-paletted images.

A simple palette translation does not care about the color themselves. It merely take the indices and change them. In particular, it will not care that color n°127 is #0B1707. It will not look at a truecolor image, scanning for #0B1707 pixels. In fact, it will not look at all at a truecolor image.

ZDoom does not convert truecolor images to the palette before it needs to render them. I think blending and translucency operations can be performed in truecolor space and then the result is converted to the palette, yielding a closer result to what is expected than if palettization happened at the start.

[The Zombie Killer]

Now that I think about it, I've experienced this bug before as well, I was trying to recolour a baron of hell variant, and it would show up weird, then I converted it to a paletted image and it worked. I hope it gets fixed, I hate working with palettes.

-TZK

[Enjay]

Do not expect palette translation to work for non-paletted images.

However, I think the issue is actually with the conversion to the Doom palette (at whatever point it is done), not the translation. Consider this screenshot which is just the test file with the translation commented out in the DECORATE:

---

The one on the left is the true colour sprite, the on on the right is paletted. Even without looking in a paint program, you can see that the dark green area is a different colour between the two sprites. On checking, again, the R11 G23 B7 area on the true colour image (a colour that is exactly in the Doom palette) is being converted to R15 G23 B0.

I should imagine that this is undesirable in a number of situations (because a true colour sprite cannot be guaranteed to be displayed in the originally intended colours). It is particularly obvious in the translated example because it removes the area from the range of the translation, making the colour very obviously different from the translated areas.

[Enjay]

Textures too it would seem (not too surprisingly).

Try the attached. It contains 2 copies of the Doom palette graphic from the Wiki used as wall textures. The one on the left is a true colour image, the one on the right is paletted. Again, entry 127 is using the colour of entry 12 in the true colour image. I haven't compared all the colours.

[Xaser]

I wonder if it would be worth feature-requesting some way to specifically tell the engine to pre-palettize certain images upon load time, but I say this without knowing how much effort it would take. I can imagine it would get a fair amount of use since I seem to run into a lot of cases of "I'd love to use PNG here but can't because of translations", unless I'm mentally skewing things. Which is always likely.

Then again, this may not be that great of an idea anyway because it would kill cross-game compatibility, which can still be faked to some degree by using a paletted original image and pairing it with a saturation translation (the latest build of Psychic does this with Bloodmoney and elemental casting effects). Pre-palettizing would ensure that the desired color range to translate would map to different indices per-game, unless you could specify exactly what palette to pre-palettize to... hrm.

Mountains upon mountains of suggestions, of course.

[Enjay]

I don't know how useful that would be versus saving the image in the Doom (etc) palette in the first place.

Either way, I think the crux of this particular reported issue is nothing to do with translations (which, in retrospect, is only relevant because the colour being missed out of the translation made the error obvious to me) is that a colour that is actually in the Doom palette is being changed to a different colour in the palette when the image is displayed in Doom. Surely a pixel in a colour that is a 100% match with one in the game palette should be shown in its own colour rather than being interpreted as a different palette entry?

[Xaser]

I don't know how useful that would be versus saving the image in the Doom (etc) palette in the first place.

I was about to say that it would allow you to utilize the untranslated version in true-color still, but that would literally be impossible if it's pre-palletized to begin with. Doh! Scratch that idea.

[Blzut3]

The reason for the difference is ZDoom uses a 15-bit lookup table for palette matching. This is done for speed and the end result is usually accurate, but as you can see it can be slightly off.

[Graf Zahl]

And before anyone asks, no, it can't be fixed. Translations are not supported for any image that come with their own palette. If all used colors in the image's palette are unique in the game palette it *may* work, but only as long as you don't change the PLAYPAL.

[Enjay]

Although I mentioned translations in the initial report, I have since corrected myself. The bug is not that translations are messed up. I understand that them not working with true colour images is expected behaviour. Fair enough.

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).

Blzut3 explained where the error probably comes from (the 15-bit lookup) but 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.