TransparencyColor setting in JPEGView.ini doesn't change color properly for BMP and GIF

[OCD-Man]

I would like to thank you for taking over this project. I am not a programmer, but I will always give you as much useful info about an issue as I can manage to discover. I will do my best to help in any way I am capable of.

I have now discovered that the real issue is that the Transparency feature of many of the formats JPEGView supports is not supported by JPEGView.

I will start with describing that problem which is in the title for this issue.

Image formats I tested that are supported by JPEGView, which are also transparency capable formats:
BMP, GIF, PNG, TGA, TIFF, WEBP, HEIC (HEIC is supported through WIC)

The TransparencyColor setting in the JPEGView.ini file only changes the transparency color for PNG and TIFF files of all the file formats in the above list. But for all the other formats, changing the Transparencycolor setting doesn't have any effect, which for most of those formats is always black, but for some formats it is a different color.

I discovered the problem when using a GIF image file, but then decided to try another format that supports transparency, and PNG worked. So to help you a bit, I decided to go though all the formats that JPEGView supports, which are also transparency capable formats. In the process I discovered that there are differences in the unchangeable transparency color for some formats. Then I read the WEBP Rendering issue posted here, and there I saw that JPEGView didn't support Transluscency in WEBP, which is when I realized that JPEGView doesn't support the transparency feature of WEBP and many other formats that are transparency capable.

So I used paint.net to make a fully transparent spot at the bottom half of a picture, as well as a transluscent spot at the top half of the same picture. I then saved the picture in all the different formats I listed above. Here is a zip file of the same picture all image formats.
Transparency test.zip

Also here is a list of all the formats (also in the zip file) that JPEGView doesn't seem to have transparency support for, along with the transparency color and info about how the transluscency is rendered for each format. (Transluscency = Partial Transparency)

BMP - Transparency color is always Black. Translucency shows as fully Solid.
GIF - Transparency color is always Black. Gif is the only format where the format itself doesn't support Transluscency, so the image I provided will show the semi-transparent part as fully transparent, and therefore is also rendered as black.
TGA - Transparency color is always Light Greyish Beige. Translucency is kept, but with the same unchangeable transparency color for the transluscency.
WEBP - Transparency color is always a strange pattern of colors. Translucency shows as fully Solid.
HEIC - Transparency color is always Black. Translucency shows as fully Solid.

I should mention that I am using Windows 7. So for the HEIC format to work with JPEGView, I had to install Copytrans, which installs a WIC codec for HEIC and HEIF, and allows HEIC files to have thumbnails.
www.copytrans.net/copytransheic/

So for HEIC, I noticed that even the thumbnail has a black transparency color and renders the transluscency as fully solid, and Windows 7 Photo Viewer also shows a black transparency color and renders the transluscency as fully solid. That tells me 2 things:

1. The HEIC codec installed by Copytrans possibly doesn't support Transparency. And if that is the case, then JPEGView may never be able to use that particular HEIC codec to support Transparency in HEIC files on Windows 7/8. And it seems there may be the same issue with the Windows 10 HEIC codec considering that someone had to make an HEIC codec plugin for the paint.net image editor to replace the Windows 10 HEIC codec in order to support transparency with HEIC in paint.net.

2. It seems when transparency is not supported, a color is actually chosen by the codec to fill in the transparency since it has to fill in the empty data in order to be able to render the picture without the use of transparency. And the transluscency is set to render as fully solid by simply setting the alpha channel back to the maximum setting of 255. The one exception to this in JPEGView for any of the image formats I listed is the TGA format which seems to render the transluscency over a color chosen by the codec which seems to be happening from the codec just filling in all the fully transparent pixels that make the transluscent area look transluscent rather than changing the alpha channel up to 255 for those transparent pixels to become solid again. So it seems that transluscency with TGA is also not supported in JPEGView even though it is rendered differently than with other image formats.

I don't know if a program has to be programmed to use all the features that an image codec supports for an image format, or if a program must only be programmed to use the codec, and it is instead up to ONLY the codec itself to support all the features of an image format. But if it is the latter, then I suppose the codecs used by JPEGView may be the only thing that needs to be changed to support Transparency.

If you will have to program JPEGView to use the transparency feature which the codec will also have to support, then the only info I have is that you need to support the "alpha channel" to render the image with transparency. There are 256 values for the alpha channel (0-255), with 0 being completely transparent and 255 being completely solid. Everything in the middle is refered to as partial transparency or transluscency. The Gif format is only capable of fully transparent or fully solid. All the other formats I've listed can use all 256 alpha channels. But some formats can have the same limitation with transparency as GIF if saved in 8-bit color such as PNG which is capable of being saved anywhere between 8-bit and 32-bit color. I think I heard somewhere that 32-bit color for an image is 24bits + Alpha channel. I do find that when I save a PNG in 24-bit color, the transparency doesn't look the same as 32-bit color when using paint.net (nothing to do with JPEGView), and continues looking different all the way down to 8-bit.

I came across the following webpage that shows a list of image formats that WIC supports as NATIVE CODECS. Since Windows 7 Photo Viewer (I only assume is using the WIC codec for BMP) renders BMP with transprency, I tried adding BMP to the list of files to open with WIC in the JPEGView.ini file, but that didn't allow bmp files to render with transparency. I don't know if JPEGView would have to be programmed to stop loading the BMP codec that it is currently using for what I tried to work, or if JPEGView is already using the WIC codec for BMP, which would mean that it is up to you to program JPEGView to support Transparency.
https://docs.microsoft.com/en-us/windows/win32/wic/-wic-about-windows-imaging-codec

One last thing is that the photoviewer called Imageglass is capable of rendering transparency for even HEIC. And at the top of the following webpage they say that they use the Magick.NET library to support the list of image formats. So maybe having JPEGView support the Magick.NET library or something similar would be the quickest answer to the problem of JPEGView not supporting transparency for all transparency capable formats.
https://imageglass.org/docs/supported-formats

[OCD-Man]

I just found a WIC codec for WEBP. It also allows Windows 7 to have thumbnails for webp which I haven't seen yet. However the codec wasn't programmed with support for color profiles, and the project for this codec was abandoned 9 years ago before color profiles support could be added.

Transparency is working with Windows 7 Photo Viewer, but adding webp to the list of WIC file extentions in the JPEGView.ini file doesn't actually make JPEGView use the WIC codec to render the WEBP image. I could tell that for sure because I tried renaming the webp.dll file in the JPEGView exe folder, and the result was a blank window when attempting to load a WEBP file.

It would be interesting to know if JPEGView would be able to render transparency for WEBP when using this WIC codec for WEBP. That's because the Copytrans WIC codec for HEIC doesn't support/render transparency in both Windows 7 Photo Viewer as well as in the thumbnail that the codec creates. But for this WIC codec for WEBP, transparency is rendered in both the thumbnails created by the codec as well as Windows 7 Photo Viewer.

So my point is that this would be a definitive test to see if it is just the codec that needs to be updated to support transparency, or if JPEGView still needs to be programmed to support transparency for each codec.

If you think this is something you would like to try, then it would be great if you could make a sort of a test compile of JPEGView with WEBP support completely disabled in a way that allows the WIC codec for WEBP to load, and it would be nice if you could attach it here for me to play with as well. Here is the link for the WIC codec for WEBP.
https://codecpack.co/download/WebP-Codec-for-Windows.html

Version 1.0.25.1 is the earliest version of JPEGView that still has WEBP support, but unfortunately it doesn't have WIC support yet. So I couldn't test this with any older version.

Also this looks like the github for the codec which is very old, which shows it shouldn't be used as a solution for JPEGView since it is also missing features.
https://github.com/webmproject/webp-wic-codec

[OCD-Man]

This is an update for how transparency is rendered with each image format.

I used a different transparency color in the settings ini file and have found that there is a difference in my analysis of the way TGA image files render that different color. It took a long time, but I have concluded exactly what the issue is with the color rendering part of the TGA problem. Webp has had transparency support addeed by pull request #27 and just has one small easy to fix issue left.

So I have updated the above posted list of formats that have issues rendering transparency to reflect my new analysis of TGA and Webp.

Also I am using the current latest version of JPEGView 1.0.40 64bit portable .7z file with Windows 7 Home Premium 64-bit.

I used the images I uploaded above to make the below analysis for each image format.

HEIC

No Change, same as above previous analysis. But I am using Copytrans to support HEIC in Windows 7, and Windows photo viewer has the same issues which means the issues may be with Copytrans rather than JPEGView. I don't see myself purchasing the HEIC codec on Windows 10, so it would be nice for you to test that with the image I provided above, and with random transparency color and background color setting in the ini file which I mention below for the issue with webp.

BMP

No change, same as above previous analysis.

GIF

No change, same as above previous analysis.

TGA

1. The partially transparent part is just a bit less transparent compared to png, tiff, and webp (which all 3 have the same correct level partial transparency). A small change can definitely be seen with the chosen color "45 110 165" by switching between the png and tga, where the tga will look a little bit darker due it being a little less transparent (at least that is my perception of why it looks different). Just for an example of the correct transparency, switching between PNG, TIFF, and webp shows that there is the exact same amount of transparency between those 3 formats in the partially-transparent (transluscent) part.

2. I have just discovered that the rendering of the transparency color completely ignores the "TransparencyColor=" setting. I give a few examples below just to show how I came to the conclusion that I came to.

The issue here is not only that the "TransparencyColor=" setting is being completely ignored, but instead of using that setting for the transparency color, it is using the reverse order of the 3 numbers used in a different setting for "BackgroundColor=". This should be easily fixed at the same time as fixing the webp problem below since they are similar issues. It took me a long time to discover that the color displayed wasn't completely chaotic and random. So here are the examples that will prove to you what I have said.

Example 1, These settings allows the Transparency color to be rendered this particular color correctly, which seems to be because the transparency color uses the same 3 numbers as the background color, but in the opposite RBG order. This I discovered while testing the webp issue in my below webp analysys.
TransparencyColor=165 110 45
BackgroundColor=45 110 165

Example 2, Instead of rendering the correct transparency color, the transparency color is rendered as completely white which is the same white as the reverse order of the background color. I tested anther transparency color "165 110 45" with the same background color and the transparency color was still white.
BackgroundColor=240 245 251
TransparencyColor=45 110 165

Example 3, Instead of rendering the proper transparency color, it is rendered as black like the background color is set to since the 3 numbers to indicate black are the same backwards and forwards.
BackgroundColor=0 0 0
TransparencyColor=45 110 165

Example 4, Instead of rendering the proper transparency color, it is rendered as white like the background color is set to since the 3 numbers to indicate black are the same backwards and forwards.
BackgroundColor=255 255 255
TransparencyColor=45 110 165

Example 5, The background color is blue, but instead of the correct transparency color it renders the transparency color as red where red would have a setting that uses the same 3 numbers as the background color, but in the opposite order "244 0 0". Setting the background color to Red "244 0 0" will reverse both colors so that the transparency color is blue.
BackgroundColor=0 0 244
TransparencyColor=45 110 165

WEBP

JPEGView renders the "TransparencyColor=" setting by parsing the 3 numbers backwards by using GBR parsing order instead of the RBG order used for PNG, & TIFF as well as for the "BackgroundColor=" setting. Therefore the color is wrong unless the 3 numbers are the same backwards and forwards, 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 guess this wasn't noticed due to only black and white being tested, or not confirming that the correct color was rendered.

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 this should be a simple fix since all that is needed to fix this webp issue is to reverse the order programed by KrokusPokus in pull request #27 (I only assume he must have programmed the order to parse the numbers) to make it so webp rendering parses the RBG order of the "TransparencyColor=" setting as R then B then G instead of 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=".

After that the main thing left is adding transparency for GIF & BMP which I wonder why that wasn't done 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

To be clear, the following TransparencyColor setting renders as brown in png & tiff, but as blue in webp images:
165 110 45

So to get the transparency color to be the correct brown color for "165 110 45" when rendering a webp image, the numbers need to be rearranged backwards "45 110 165" at which point you can see that the color is an exact match to background color setting of "165.110.45".

[sylikc]

I just tested this with the latest build and

• PNG: Transparency works and is correct
• HEIC: Transparency works and is correct
• BMP: transparent spot shows black, which is not background color OR transparency color
• TIFF: Transparency works and is correct
• TGA: Transparency works and is correct
• WEBP: Transparency works and is correct
• GIF: transparent spots both show black, which isn't background or transparency