How to Increase the Resolution of Output .png Files?

[xanderdunn]

I'm creating a plot with:

namespace plt = matplot;
auto figure = plt::figure(true); // open figure in quiet mode (headless)
plt::hold(plt::on);

//figure->size(2400, 1560);
plt::title("Sample");
auto axis = plt::gca();
        axis->plot(feature_vector);
}
plt::hold(plt::off);

figure->save("./artifacts/plots/name.png");

Adding figure->size(2400, 1560); does not appear to have any effect on the resolution of the output file, which is still 640x480. How do I make the output image higher resolution?

[alandefreitas]

You can temporarily set this to true to see how it affects the gnuplot output.

The quiet mode doesn't necessarily mean it's headless. It just means it won't draw unless you call draw(). Otherwise, it will redraw the figure whenever something changes. This problem might have something to do with that.

[xanderdunn]

I happen to be running this code on a headless machine. It has no display. Setting quiet mode to true stopped the pesky qt server messages showing up in my terminal, so it met the needs of my situation with no display.

It looks like I can pass TRACE_GNUPLOT_COMMANDS as a compiler macro to set trace_commands = true, and see if this causes figure->size(2400, 1560) to work as expected?

[alandefreitas]

I happen to be running this code on a headless machine. It has no display. Setting quiet mode to true stopped the pesky qt server messages showing up in my terminal, so it met the needs of my situation with no display.

This might work. I'm just not sure. I think gnuplot is using opengl in the end, and the opengl APIs usually don't work well with headless contexts, although it's technically part of the standard.

In any case, save() is just temporarily setting your gnuplot terminal to the png terminal, which is non-interactive, and calling draw() to save the image. The order in which these things are being called might affect how the size command is being set.

It looks like I can pass TRACE_GNUPLOT_COMMANDS as a compiler macro to set trace_commands = true, and see if this causes figure->size(2400, 1560) to work as expected?

This might work. Trace commands is constexpr though. So this might fail if the binary is compiled with trace_commands = true because TRACE_GNUPLOT_COMMANDS would just be affecting the header file in this case. Depends on the order in which you call the commands and include the definitions.

[xanderdunn]

This might work. I'm just not sure. I think gnuplot is using opengl in the end, and the opengl APIs usually don't work well with headless contexts, although it's technically part of the standard.

I am currently successfully saving .png files on a headless machine with the above code. Is there a better way of doing this for a headless machine? I don't need any interactivity. I'm happy to change the backend or whatever else would be better suited to a headless, non-interactive situation.

[alandefreitas]

Is there a better way of doing this for a headless machine?

I don't think there's a better way at the moment. Using a non-interactive gnuplot terminal with the gnuplot terminal should be the best way to do that.

If the terminal is not using the proper size, then it's something we need to debug.

[nourgaliev]

figure->save("./artifacts/plots/name", "png");

worked for me, i.e., resolution is set properly. Otherwise - it ignores my resolution.

[ndrnml]

I've also run into that issue. And interestingly if you change it to

figure->save("./artifacts/plots/name", "pngcairo");

it will ignore the size again.
If you set TRACE_GNUPLOT_COMMANDS to true you can also see the difference in commands it produces.
png:

set terminal png size 1000,1000 enhanced

pngcairo:

set terminal pngcairo enhanced color font "Helvetica,10"

unfortunately it doesn't only affect the size of the figure but also the quality and certain renderings of the graph.
@alandefreitas Do you want me to create an issue for it?

[ndrnml]

I guess this is a gnuplot limitation?
found this in gnuplot.cpp:

        // Terminals that have the size option *in the way we expect it to work*
        // This includes only the size option with {width, height} and not
        // the size option for cropping or scaling
        SV_CONSTEXPR std::string_view whitelist[] = {
            "qt",      "aqua",     "caca",    "canvas", "eepic",
            "emf",     "gif",      "jpeg",    "pbm",    "png",
            "sixelgd", "tkcanvas", "windows", "wxt",    "svg"};
        ...

As you can see pdf and pngcairo is not part of this list

[alandefreitas]

Yes. I believe the assumption gnuplot makes is that the size option doesn't make sense for vectorial graphics. However, that's not entirely correct since they often embed images.