XnView Software

CheckerColor1 and CheckerColor2 options are using reversed red and blue channels. Meanin that red is used as blue and blue as red (BGR).

Example: If you set CheckerColor1=255 which should result red checker, but instead you get blue checker.

The problem exist with both colour coded and non-coded values.

ckv

Hello !

• I think that you might set a complete colour code… For instance, here I have :

[View]
CheckerColor1=#FFD7FF ■
CheckerColor2=#FFFFE7 ■

… and that works perfectly…

KR
Claude
Clo

Clo wrote: ckv

Hello !

• I think that you might set a complete colour code… For instance, here I have :

[View]
CheckerColor1=#FFD7FF ■
CheckerColor2=#FFFFE7 ■

… and that works perfectly…

KR
Claude
Clo

It is a complete colour code. It is just a non-coded color value and it translates to 255 0 0 or #FF0000 as a coded value. If you use any of these values 255, 255 0 0 or #FF0000 you should get a fully red checker, but instead you get blue checker.

In your example CheckerColor1 has same value for red and blue, so sure it works. But CheckerColor2 has different values and this is what it looks like on my screen ■.

I had noticed that too, but I forgot to report it. Thanks, ckv!

ckv wrote:It is a complete colour code. It is just a non-coded color...

lol

ckv

Again…

…But CheckerColor2 has different values and this is what it looks like on my screen (light blue)

• Here it's "cream" on MY screen as it should !
- Gentlemen, I guess that something is wrong in your machines… or your graphic cards settings…

KR
Claude
Clo

Clo, if you set CheckerColor1=#FF0000, do you get red checkers?

ckv wrote:CheckerColor1 and CheckerColor2 options are using reversed red and blue channels. Meanin that red is used as blue and blue as red (BGR).

Right, I have the same problem here.

ckv wrote:CheckerColor1 and CheckerColor2 options are using reversed red and blue channels. Meanin that red is used as blue and blue as red (BGR).

ToolbarBackColor has the same bug.

Please disregard my post.

Not fixed in XnView 1.97 beta.

Only the # or $ formated colors work with CheckerColor1 / CheckerColor2 settings, but raw color and R G B formated values still doesn't work. E.g. CheckerColor1=16711680 or CheckerColor1=0 0 255 should result blue checker, but instead it's red.


This fix also caused a regression with all other formated # and $ color entries.

Example:

TreeBackColor=#0000FF
TreeFontColor=#FFFF00
TreeFontHiColor=#FF0000

These settings should result a folder tree that should look like this:


But in XnView 1.97 beta it looks like this:



Looks like this bug is fixed in the wrong place, as this quote from the changelog hints "INI Color entry with # or $ are reversed"

The problem was not that all # or $ formated colors are reserved, but only CheckerColor1 and CheckerColor2 color entries are reserved. Even the raw non fromated values are reserved with these two settings.

ckv wrote:Not fixed in XnView 1.97 beta.

Ok, i've not fixed the good thing. Could you send me your email by PM, please?

Fixed in XnView 1.97 beta 4