Created attachment 114616 [details] Updated map file for Norway (with transparent background) KGeography doesn’t handle images with transparency correctly. It looks like the colour of transparent areas aren’t properly recognised. I’ll attach an example image. This is an updated version of the map for ‘Norway’. The only difference is that the background colour (220,220,220) is marked as transparent (but it’s still saved as a colour). How to reproduce: 1. Note that the norway.kgml has a definition for ‘Not Norway’, defined as the colour (220,220,220), the same colour used as the (transparent) background colour in the attached image file. 2. Note that the tools/colorchecker.py scripts reports ‘The map is correctly formed’ when run on the ‘norway.gml’ when the existing ‘norway.png’ is replaced by the attached file. (If I change the background colour to a *different* colour, the tool complains, so it seems to work fine.) 3. Note that KGeography correctly loads the image, and shows it with a transparent background (which looks *much better* than the grey rectangle of the existing map file). 4. Click on the background of the map to get the following error message: You have found a bug in a map. Please contact the author and tell the /usr/share/kgeography//norway.kgm map has nothing associated to color 220,220,220. So it looks like KGeography *sees* the colour as 220,220,220, the colour defined in the .kgm file. But at the same time it doesn’t *handle* it like a normal 220,220,220 colour.
When, using the Gimp, I remove the alpha channel off your updated Norway png file, I can see that previously gray zone that is tagged "Not Norway" exhibits same color as Østfold. That is consistent with the palette showing two colors less than previous map, where only one zone was merged (Nord Trondelag). KGeography strongly relies on palette.
(In reply to Laurent G. from comment #1) > When, using the Gimp, I remove the alpha channel off your updated Norway png > file, I can see that previously gray zone that is tagged "Not Norway" > exhibits same color as Østfold. Don’t use Gimp’s ‘Remove Alpha Channel’ feature. It replaces the alpha channel with the colour you have currently selected as the background colour. To properly remove the alpha channel, you can use ImageMagick’s convert command: convert infile.png -alpha off outfile.png Then you’ll see that the actual colour for the transparent part is 220,220,220 (a light grey colour), just like KGeography reports (but doesn’t handle properly).
So I turned to ImageMagick identify. We get 282: (219,185,228,255) #DBB9E4FF srgba(219,185,228,1) 241468: (220,220,220, 0) #DCDCDC00 srgba(220,220,220,0) 7353: (241, 14, 14,255) #F10E0EFF srgba(241,14,14,1) But when we read the kmap file, we assign to the division/zone the color 220,220,220,255, as does the function inline Q_DECL_CONSTEXPR QRgb qRgb(int r, int g, int b)// set RGB value { return (0xffu << 24) | ((r & 0xffu) << 16) | ((g & 0xffu) << 8) | (b & 0xffu); } We may warn the use of transparent color in a map, especially as it bring nothing to the game, does it ?
(In reply to Laurent G. from comment #3) > We may warn the use of transparent color in a map, especially as it bring > nothing to the game, does it ? I’d rather see it supported. Currently, the (non-transparent) map is displayed with an ugly light-grey background, which doesn’t blend well with the background. (And it’s even uglier with a dark theme.) I see several maps use a light-grey background colour. I’m not sure why, but perhaps KGeography once had a light-grey colour for the area behind the map images, so that they would blend with the background? But now Qt supports transparent images (and the attached image looks great in KGeography, with both Breeze and Breeze Dark themes), so I see no reason *not* to use transparent background for the map files (except for this bug, of course).
I'd rather not support transparency. Since you can *not* know what color is the background you can't be sure it won't match one used in the map itself. Having a solid background fixes that.
(In reply to Albert Astals Cid from comment #5) > I'd rather not support transparency. Since you can *not* know what color is > the background you can't be sure it won't match one used in the map itself. > Having a solid background fixes that. I’m not sure what you mean by that. When you create the map, *you* decide which colour(s) should be transparent, just like you decide the other colours in the image file. And the ‘colourchecker.py’ tool correctly handles the colours. (If I used a different colour for the transparent background, in either the PNG file or the .kgm file, it would complain.) So there’s no problem ensuring that the file is valid, i.e. that the transparent colour is named in the .kgm file.
Hum. If we go your way, Karl, we have two choices : 1) Make transparency level mandatory in division colour specification in kgm. And adapt checker accordingly. Not nice. 2) Cross-check colour from kgm with colour from png to store transparency too in division. Doeable but I don't like it that much. What I had in mind, ten years ago, was to allow recoloring at run-time, so I hesistate between those 2 alternatives, and the status-quo also. Albert is still the lead.
(In reply to Karl Ove Hufthammer from comment #6) > (In reply to Albert Astals Cid from comment #5) > > I'd rather not support transparency. Since you can *not* know what color is > > the background you can't be sure it won't match one used in the map itself. > > Having a solid background fixes that. > > I’m not sure what you mean by that. When you create the map, *you* decide > which colour(s) should be transparent, just like you decide the other > colours in the image file. You were saying maps looks nice when the background is transparent, but since we allow for random themes, i could very well have my widget theme "background" color to be red, so when overlaying a transparent https://bugsfiles.kde.org/attachment.cgi?id=114616 over it, it would look ultra weird because the top part would be the same color as the background itself. That's why a solid background color makes sense
Closing as per my explanation of why a background is better. I've also just commited to master an improved colorchecker.py from Laurent that will warn about it