Issue with graph marker style 33

ROOT
1

Hi,

I’m having an issue when trying to use marker style 33 (full diamond) with TGraphErrors. It seems like the markers are offset by 1 pixel to the right and 1 pixel down, leading to a pixel of whitespace above the marker and one pixel on the right of the marker being cut off.

For reference, the resulting markers look like this:

test
test698×476 2.17 KB

Zoomed in:
test2

But, I would expect them to look like this:

test3
test3698×476 2.17 KB

Zoomed in:
test4

This is the code I’m using to make the graph shown:

void main() {

    double xx[5] = {1.0,2.0,3.0,4.0,5.0};
    double yy[5] = {1.0,4.0,9.0,16.0,25.0};

    double ex[5] = {0.0,0.0,0.0,0.0,0.0};
    double ey[5] = {1.0,2.0,3.0,4.0,5.0};

    auto gr = new TGraphErrors(5,xx,yy,ex,ey);
    auto c1 = new TCanvas("c1","c1");

    gr->Draw("AP");
    gr->SetMarkerStyle(33);

}

Does anyone know of an easy way that I can correct this?

Thanks in advance.

ROOT Version: 6.32.02
Platform: Ubuntu 24.04.03

2

I don’t see that problem when I run your macro. Try first with a more recent version of ROOT; if that doesn’t solve it:

  • Maybe it’s an artifact on your display: maybe you have scaling on your screen (if you see the problem on an interactive session, but if you save the canvas you shouldn’t see it on the saved image); or try a different canvas size
  • Try a different marker size
3

I tried upgrading to the newest stable version of ROOT at time of writing, version 6.36.06, but it did not change the results when running the macro for me. I’ve tried your other suggestions as well, but no change there either :confused:

4

Increasing the marker size didn’t help? what do you get with gr->SetMarkerSize(2); (or 1.5, 3,…)? Do you not have a screen scaling different from 100%? if it’s 100%, how are you saving those images (should be something like c1->SaveAs(myimage.png)?

5

I previously used File->Save As in the original post to save my image, but I’ll be using the method you mentioned for any future images for the sake of consistency. Changing the canvas size and/or aspect ratio has no effect on how the markers appear for me. The issue is always present in the window that pops up when running the macro, and in the resulting .png file.

Changing marker size also does not lead to any change—i.e., there is the same “one pixel offset” that I described regardless of the marker size chosen.

For example, here is the result with marker size set to 2:

marker_size_2
marker_size_2698×476 2.34 KB

Marker size set to 3:

marker_size_3
marker_size_3698×476 2.49 KB

Set to 1.5:

marker_size_1p5
marker_size_1p5698×476 2.32 KB

Set to 0.75:

marker_size_0p75
marker_size_0p75698×476 2.25 KB

6

I tried your example on Mac. I generated 2 outputs: png and pdf.
With that small size the marker in the png output is a bit distorted because there
is not enough pixels to draw properly the diagonals. The PDF is fine because pdf is vector graphics. In both case I do not see any pixel shift.

7

Ok, when I save the plot as a .pdf there is no visible shift for me (see attached), which is helpful. I would still like to figure out why this shift is happening for the raster formats though, especially since it doesn’t seem to be occurring for anyone else?

test.pdf (13.5 KB)

8

Do you get it on screen or when you save your plot as, for instance, a .png file , with root running in batch mode ?

9

Ah, ok, I have not been running ROOT in batch mode, when I do this is what I get:

test
test696×472 2.31 KB

So it seems like this fixes whatever was causing the shift, although strangely it seems like there are now pixels getting cut off on the right hand side of each marker. Possible that that effect is an artifact of distortion due to the limited resolution?

10

When you generate a raster image in interactive mode a screen dump from what is produced on screen is done. When you run in batch the raster plot is produced via the TASImage package. So, when you see the problem in your raster file, very likely you should see also on your interactive screen output. Given you are running on Ubuntu the screen output is produced by X11. Regarding the “pixels cut off on the right hand side of each marker”, as I said the number of pixel for this marker size is very low, therefore none straight lines rendering is not optimal and (given the low number of pixel available) it is difficult to improve it. I can see several solutions:

  • keep the size and the marker style but generate vector graphics output (pdf, svg, postscript)
  • keep the marker style but increase the marker size
  • keep marker size but use marker a style without oblique lines (there is plenty)
11

Got it, ok, this makes sense, and I think you’ve answered all my questions. Thank you!

1 Like