Partial error in eve tutorial


I am running the following example: root $ROOTSYS/tutorials/eve/alice_esd.C, altough the same issue appears with the other alice examples.

Everything seems to work except the “Event Control” tab, which appears empty. It should have some elements such as buttons to move between events.

My console output is the following, which also shows my root version:

  | Welcome to ROOT 6.25/01               |
  | (c) 1995-2021, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Nov 23 2021, 11:42:00                 |
  | From tags/v6-25-01@v6-25-01                                      |
  | With                                                             |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |

root [0]
Processing /opt/root/install/tutorials/eve/alice_esd.C...
*** Opening ESD ***
Info in <TFile::OpenFromCache>: using local cache copy of [./files/alice_ESDs.root]
Warning in <TASImage::GetMask>: No image
Info in <TFile::OpenFromCache>: using local cache copy of [./files/alice_ESDgeometry.root]
Info in <TGeoManager::TGeoManager>: Geometry Geometry, default geometry created
Warning in <TASImage::GetMask>: No image
Warning in <TASImage::GetMask>: No image
Loading event 0.

I have found that if I add another invocation of make_gui() after the first (and only) one, something happens.

Another tab appears with the two buttons, however the icons don’t seem to load. I have checked that the icons are where they are supposed to be. The buttons seem to work OK.

My goal is to make a gui such as this one, but I have failed to populate the contents of a tab as it happens here after trying many different things, so I hope I can be enlightened.

I think @matevz can help.

Hmmh, here is where the icons are loaded:

Do you have your ROOTSYS set? I’m not sure how one gets to such assets when running from system-wide install in /usr/, if this is what you have. Probably there are some other variables one should be using.



Yes, the icons are where they are supposed to be (atleast the files).

If you want to reproduce the issues you can use my development environment docker image here:

docker pull

You should be able to reproduce the issue by running:

docker run -e -it

and inside the container run:

root $ROOTSYS/tutorials/eve/alice_vsd.C

Perhaps there is something wrong with my root install but so far its working flawlessly.

Thanks for looking at it @matevz.


I tried and got into serious trouble with xauth and selinux and even after somehow slamming those two into obedience remote GLX still wouldn’t work. Anyway, I did get to the same errors you get printed out Warning in <TASImage::GetMask>: No image.

It’s hard to debug stuff in the container but I suspect something gets screwed up in loading of the image somewhere here:

possibly in the init_icon_paths() func:

Can you try removing the iconpath etc in the EVE tutorial so it will just pass the image file name, without the directory, something like this (for both icons):

      b = new TGPictureButton(hf, gClient->GetPicture("GoBack.gif"));

Does other gui work ok for you, eg new TBrowser? Everywhere else in root code people just ask for image file without dir, I have no clue why I added the path prefix there :frowning: … or :slight_smile:

Sorry for the trouble.


this change has no effect as far as I can tell. Other GUI seems to work OK, including a custom GUI root standalone application I made (which is what I want to place into a tab in the event viewer), the problem only appears when interacting with the TEve frame.

I will test this in other root version to see if it still appears.

Thanks for looking at this.

After testing it in an older version (v6-24-06) and getting the same result I did some digging and found this issue TGPictureButton does not load image from disk · Issue #6985 · root-project/root · GitHub, which describes matches my problem. It looks to be fixed in an upcoming release.

I could not find an easy fix for the current version though, if somebody know how please let me know. It seems to have something to do with the version libafterimage present on some systems.

Good catch! Why don’t you enable builtin afterimage, as advised there? Or you are picking up some existing root build / packages?

I suspect what will be fixed in the new release is error message, that should be saying image format not supported :slight_smile:


To be honest I don’t know how to do this, I can’t find related documentation, only Building ROOT from source - ROOT, which tells you know to use an external executable, so since I am not using this compile flag I assume I am using the builtin afterimage?

I am compiling root only with the flags -DGDML=ON -DCMAKE_CXX_STANDARD=17, could you be so kind to tell me how to enable the default afterimage?


Hmmh, I’d expect that if you don’t specify anything, you get the builtin one.

Oh, my assumption is wrong, in your container there is this:

root@4a85fa396480:/# ldd $ROOTSYS/lib/ | grep -i image => /usr/lib/x86_64-linux-gnu/ (0x00007f35cd282000)

root@4a85fa396480:/# type afterimage-config
  afterimage-config is hashed (/usr/bin/afterimage-config)

root@4a85fa396480:/# afterimage-config --cflags

In my build afterimage is statically linked into libASImage, this is where .a is built:

matevz@black dev-1-bld> ll $ROOTSYS/lib/libAfterImage.a
-rwxr-xr-x. 1 matevz zh 736970 Oct 29 14:16 lib/libAfterImage.a

But I don’t have afterimage stuff installed on my system … so maybe just afterimage-config being in the path is enough for it to be picked up. I agree the docs are on the curt side.

Ah well, indeed, look at this:

Maybe you should just pass -Dbuiltin_afterimage=ON?

Alternatively, can you take libAfterImage (and -devel) out of the container? [ This is Fedora package name, I do not know how one controls these things in container build scripts. ] Without system installed after-image root will fallback to builtin one.


it works!

I used -Dbuiltin_afterimage=ON as you suggested and it is fixed now.

thanks a lot!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.