Webp Transparency color incorrect, incorrectly processes RBG as GBR, similar issue with TGA

[OCD-Man]

I originally wrote the following comment in pull request #27 since it was related to a problem with that fix for webp transparency, but since that pull request had already been closed when I wrote that comment, it seems you didn't see it. So I figured a new issue is the way to go. I assume this should be a quick fix.

Original comment in pull request #27 :

There is still an issue with the rendering of the Transparency Color with this fix. Yes it does render a color based on the "TransparencyColor=" setting in the ini file, but it renders the wrong color for almost all colors. I will explain exactly the reason this is happening.

I assume you didn't check if it was the correct color being rendered, or maybe you only tested with a "TransparencyColor=" setting of black "0 0 0" and white "255 255 255" which will render correctly.

The issue is that JPEGView renders the "TransparencyColor=" setting for webp files by parsing the 3 numbers backwards as GBR instead of the RBG order used for PNG & TIFF as well as for the "BackgroundColor=" setting. Therefore the color is rendered incorrectly unless the 3 numbers are the same when the order of the 3 numbers is reversed, such as with black "0 0 0" or white "255 255 255" or any other color where the first and last numbers are the same such as "124 57 124".

I first noticed that my personally chosen color was white instead of a very light blue. I then tested black just to see why issue #6 was considered completely solved and was closed, and I saw that black was working. Then I tried another color and got the wrong color, but at least it had changed the color. At that point a memory came to mind of the same issue with setting a color for subtitles in a .ass file. I remembered learning that .ass subtitles parsed the RBG numbers backwards as GBR. So I tried the GBR reverse order of the 3 numbers in the "TransparencyColor=" setting and I got the correct color that should have been shown with the previous order of those 3 numbers.

I assume it should be a simple fix to change the parsing of the 3 numbers of the "TransparencyColor=" setting so that they are parsed as R then B then G instead of a G then B then R.

I hope you can at the same time fix the almost identical issue with TGA files, with the only difference being that on top of the incorrect GBR parsing order, TGA files render the transparency color by parsing the 3 numbers from the incorrect setting for "BackgroundColor=" instead of from the correct setting for "TransparencyColor=".

You can read more about the TGA issue (with examples) in the update I just made to my analysis of transparency color rendering for WEBP and TGA images in issue #13. I am talking about the second TGA issue.

After that the only related thing left is adding transparency for GIF & BMP which I wonder why you didn't do at the same time as Webp.

For testing, it would be easiest to see the problem by setting both of the following settings to the same color in order to see the difference in color within one open image. You may have to stretch the window in order to see the background color, or just open a small image such as the one uploaded in issue #6.

BackgroundColor=165 110 45
TransparencyColor=165 110 45

[sylikc]

right right... my bad. I recall seeing this comment but didn't find it again. I'll look into it in a week or two. I'm currently knee deep in the KeyMap.txt, strings.txt and JPEGView.ini revamp

[sylikc]

As always @OCD-Man thanks for the detailed issue reporting... I've tested the fix and it looks good. You can test it in one of the nightly builds or wait for the next release!