JPEG Images take on GUIBkColor

[KJohn]

I'm running on Vista and I'm using 3.3.0.0.

In Vista, the default GUI background colour is 0xF0F0F0. Now if any JPEG image is present in the GUI having pixels with the shade 0xF0F0F0, it takes on the set GUI background colour. For example, if you decide to use 0x201204 (which is quite dark compared to 0xF0F0F0) as the GUI's background colour, the pixels in the JPEG image control that were originally 0xF0F0F0 take on the new set background colour. The JPEGs I used to test this theory were converted from PNGs using Irfanview (if that is relevant).

I had encountered this a couple of times in the past but I was never able to explain what exactly was happening. I was wondering if I should file a bug report for this.

[jpm]

not sure to understand completly can you post a script with the .jpg illistrating what you are facing

[KJohn]

not sure to understand completly can you post a script with the .jpg illistrating what you are facing

#NoTrayIcon
#include<GuiConstants.au3>
#include<GuiConstantsEx.au3>

GuiCreate("JPEG Pixel", 210, 110,-1, -1)
GUISetBkColor (0x101010) ;a dark shade first (remember the colours in the actual picture!)
GuiCtrlCreatePic("autoitback.jpg", 5, 5, 200, 100)
GUISetState()
Sleep(3000)
GUISetBkColor (0x606060) ;watch the pixels in the image change colour
Sleep(3000)
GUISetBkColor (0xA0A0A0) ;again - just to be sure
Sleep(3000)

And the image:

Please note that the dominant shade in the jpeg is 0xF0F0F0...

[wraithdu]

I think this may be why. From the help file -

The background is always set to transparent.

[KJohn]

Koshy John,

Your .jpg has a transparent background for the most part - so you are seeing the GUI background colour change through it, not the .jpg itself. I filled in the .jpg with a solid colour and it stayed constant throughout the GUI colour changes.

M23

Like I said, it happens only when the said colour in the JPEG matches the default GUI background colour (which in Vista and possibly in XP too is 0xF0F0F0). So filling it in with any other colour obviously won't reproduce the issue. I wasn't aware that any pixel shaded 0xF0F0F0 in a JPEG automatically made it equivalent to being transparent. In the first place, I wasn't even aware that JPEG supported transparency.

[KJohn]

I think this may be why. From the help file -

The background is always set to transparent.

I find it difficult to clearly understand the scope of the remarks for this function in the help file but I also found this:

To have a transparent picture it is needed to create the GUI window with WS_EX_LAYERED extended style. The left-top pixel will be used as the transparency color. If several pictures are created the last picture is defining the transparent color.

This window (in my example) does not use the WS_EX_LAYERED extended style.

About your quote again, my example exaggerated the problem by using 0xF0F0F0 as the dominant shade (if the help file is taking that as a definition for background). You will find that the problem exists even if there are only a pixel or two in a huge jpeg image. In such a situation, the coder will be left wondering about what is causing his image to corrupt.

[jpm]

Please note that the dominant shade in the jpeg is 0xF0F0F0...

in fact if you run with window standard theme everything look good. It seems related with the Vista Aero theme.

Certainly some complicated theme behavior for me beyond what AutoIt have to handle

[jvanegmond]

Koshy John,

I did not think .jpgs supported tranparency either, but I have just created a couple of .jpgs coloured with 0xF0F0F0 and they behaved perfectly. So if it is not transparency, it looks as if it is behaving like it!

M23

Edit: A bit of Googling shows that it is possible - but well outside my knowledge boundaries:

A way to make a JPEG transparent is "to store an alpha channel (transparency percentage) as a separate color component in a JPEG image. That could work since a small error in alpha makes only a small difference in the result. The problem is that a typical alpha channel is exactly the sort of image that JPEG does very badly on: lots of large flat areas and sudden jumps...A transparent JPEG done this way could easily be double the size of a non-transparent JPEG."

Taken from http://www.faqs.org/faqs/jpeg-faq/part1/

So perhaps your .jpg is of this type? As I said before - well outside my comfort zone, so I will retire gracefully and leave it to the experts.

Melba23, please read your sources well before you use them. The quoted text that you copied and pasted here on this forum only deals with "What if we wanted to add transparency support to JPG". I'll just quote the important bit that is right above it here, so you can read it again.

Subject: [12] Can I make a transparent JPEG?

No. JPEG does not support transparency and is not likely to do so any time

soon. It turns out that adding transparency to JPEG would not be a simple

task; read on if you want the gory details.

I've also just tried to add an alpha channel in JPG the same way as you would with TGA, but naturally, that is lost in the saving process. Edited February 5, 2009 by Manadar

[Melba23]

Manadar,

Sorry if you felt I was misleading anyone - that was not my intention. I did point out that such matters were way above my level of knowledge.

My only goal was to try and help solve the problem of the OP's .jpg that showed transparent-like behaviour. There is a saying: "If it looks like a duck and quacks like a duck..." - a .jpg that appeared to show transparency needed some explanation.

I promise not to interfere in such matters again - I will leave to the big boys like you and remain firmly in my box.

M23

[KJohn]

in fact if you run with window standard theme everything look good. It seems related with the Vista Aero theme.

Certainly some complicated theme behavior for me beyond what AutoIt have to handle

I imagined it might be something like that... Probably some speed optimization in the window drawing api code that didn't account for this unique possibility. Thanks for looking into it though, jpm!

Maybe Jon can bring it to Microsoft's attention sometime.

[jpm]

I imagined it might be something like that... Probably some speed optimization in the window drawing api code that didn't account for this unique possibility. Thanks for looking into it though, jpm!

Maybe Jon can bring it to Microsoft's attention sometime.

I will assume windows7 may be ...