The computer with the correct id’s is a windows. I’m running on linux mint. root -n doesn’t change the results.
I just tried on lxplus. Which is Linux:
[couet@lxplus9110 ~]$ root
------------------------------------------------------------------
| Welcome to ROOT 6.32.08 https://root.cern |
| (c) 1995-2024, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Nov 14 2024, 00:00:00 |
| From tags/6-32-08@6-32-08 |
| With g++ (GCC) 11.5.0 20240719 (Red Hat 11.5.0-2) |
| Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------------
root [0] TColor::GetColorByName("kRed")
(int) 632
root [1] TColor::GetColorByName("kRed-1")
(int) 631
root [2] TColor::GetColorByName("kRed-2")
(int) 630
root [3]
I logged via ssh to another machine with Debian 10 and got the same issue.
What is also interesting - when I use color wheel to pick up the color, on the top on the left side the name of the selected color is correct (like kRed-2 or something). The GetColorByName also returns the correct values 
Edit: I tried a completely different computer with a similar OS (also Mint) - there is everything correct.
So it seems to be a bug that for some reason creates wrong colors on my physical machine rather than something related for software.
I’m running your macro debug.C on Linux Mint too and noticed something: click on e.g. kRed-2 and the RGB values on the right side show 152,50,50, with Hue/Sat/Lum= 255,128,101, and the name says correctly “New: kRed-2”, and the macro prints “SELECTED COLOR 1181”; if I click ok and then immediately open again the “color selector”, the current RGB now shows 151,49,49, and HSL = 255,130,100; so the values were somehow shifted at some point. Clicking again on the kRed-2 circle changes back the values (152,50,50…) and clicking ok again prints “SELECTED COLOR 1181”, but the values are always changed to the “shifted” ones when opening the color selector. This shifting happens for some of the colours, not all. E.g. kRed-1 is (102,50,50) (“SELECTED COLOR 1182”) and gets shifted to (102,49,49), but kRed+1 (204,0,0) stays as (204,0,0) (and prints “SELECTED COLOR 633”).
I tried what you did:
- click on kRed-2 - RGB shows: 153 51 51 HSL shows 255 127 102 . The name is “kRed-2”
- Then I click OK (I need it to see your printout)
- The printout shows: SELECTED COLOR 630
- If I reopne the color wheel (is that waht you name “color selector” ?) then I see again 153 51 51 for RGB …
So it must be something Linux (or just Mint?) is doing differently, if even the initial RGB definition (or at least what’s being reported) of kRed-2 is different. I’m running the latest stable
$ root
------------------------------------------------------------------
| Welcome to ROOT 6.32.08 https://root.cern |
| (c) 1995-2024, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Nov 14 2024, 10:15:23 |
| From tags/v6-32-08@v6-32-08 |
| With c++ (Ubuntu 13.2.0-23ubuntu4) 13.2.0 |
| Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------------
root [0]
$ lsb_release -a
No LSB modules are available.
Distributor ID: Linuxmint
Description: Linux Mint 22
Release: 22
Codename: wilma
I tried the same steps I previously detailed on lxplus (linux machine) and I get exactly the same thing as on my local mac.
root is also 6.32.08 on this machine,
I tested it on Ubuntu (Kubuntu) and I get the same that you get: for kRed-2, RGB = 153 51 51, HSL = 255 127 102, printing SELECTED COLOR 630, and it does not change when reopening the wheel, so it does seem to be a problem specific to Mint.
Same here on Ubuntu Mate Desktop (not Mint), if I choose kRed - 2, I get SELECTED COLOR 1180
Found the issue: if you change in this function the 257 to 256, it will get solved:
void TColor::Pixel2RGB(ULong_t pixel, Int_t &r, Int_t &g, Int_t &b)
{
ColorStruct_t color;
color.fPixel = pixel;
gVirtualX->QueryColor(gVirtualX->GetColormap(), color);
// color is between 0 and 65535 inclusive. We need to move it to the 0 to 255 range (inclusive). So we need to resample the 65536 values into 256 indices. This would mean equal blocks of 256 high-res values per color index.
r = color.fRed / 257;
g = color.fGreen / 257;
b = color.fBlue / 257;
}
so maybe the problem is in all X11 ?
See maybe related comment new methods AllocColor() and QueryColors() that reduce the expensive · root-project/root@a09e286 · GitHub
and I proposed PR:
1 Like
Thanks for this PR. It is merged.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.