Charts.ToImage quality

@Hannodb,
Yes, we need a sample file to reproduce the issue. You can use fake data to simulate various operations.

@Hannodb

From your screenshots, it seems that the issue is caused by different display settings(In some cases, the DPI will change). The API CellsHelper.DPI can give the info about it.

Hi Peyton

I was able to add that check on our automatic process. Both locally and on the server, it shows as 96. However, when I ran the process for the staging environment on the server, the charts no longer displayed as small anymore. I’m not sure it that was because someone altered the DPI and its now back to normal, and if there is some other issue. I see the DPI is an overridable setting. I’ll see if I can reproduce the issue if I change its value.

I’ll come back later with the results

@Hannodb

It is nice to know that it is working on the server. If you still find the issue, let us know with details and samples, we will check it soon.

Actually, it’s not nice, because it makes it that much harder to track down what the problem was.

I’m not sure what the CellsHelper.DPI is suppose to be.
I changed the “Change the size of text, apps, and other items” on all three my screens to 125% and ran the process again. I expected CellsHelper.DPI to have another value, but it was still 96. Perhaps I’m thinking of the wrong setting, is there some other setting I need to change to affect the CellsHelper.DPI?

I’ve tried setting the value of the property, but it doesn’t seem as if the setter has any effect, the value remains 96.

If I can change the DPI and recreate the issue in the process, that would be great, because then we know what it is.

@Hannodb

Has the server been restarted and then been logged in from a client with 100% display setting for the first time?

You may try to restart the server, log in it from a client with other display setting(e.g. 150%, 200%), then check the issue again.

@Hannodb

Actually, the CellsHelper.DPI is

using (Bitmap bitmap = new Bitmap(1, 1))
{
    using (Graphics g = Graphics.FromImage(bitmap))
    {
        //DPI
        float res = g.DpiX;
    }
}

It seems that it only changes on some Windows version for some mechines.

You can directly set value to it. But don’t get the value before setting value. However, this may not be the same case as the issue.

Please try the following:

Unfortunately, I cannot do that. I’m the software developer, and do not have those rights on the server. Even if I did, I won’t be able to just do it, because production processes are running on that machine.

Be that as it may, if it happens again, I will ask the IT team to investigate the “Change the size of text, apps, and other items” setting on the machine.

Thanks anyway. I hope this was the issue, so that we can resolve it if it happens again.

@Hannodb

Please share your findings if you can reproduce the issue. Thanks.
Feel free to contact with us at any time.

Unfortunately, the issue is not gone. It happened again. Appearently, we had patches installed on the server before the issue emerged. Most of it seems to be MS Office related. Here is the list of patches, I’m not sure if this would help tracking down the issue:

OfficePatches.jpg (725.1 KB)

That’s unfortunately the only new information I can provide for now.

@Hannodb

What is the value of CellsHelper.DPI now on the server?

We need the source file(you may prepare a source file with fake data that can reproduce issue on the server), code and the output files on the server(both the distorted one and the correct one).

Ok, so I have news that is simultaneously good and bad.

  1. Our IT guy was able to sign in on the server without using remote desktop. Setting the Display settings on the server reproduced the issue. (Although, it did not affect the DPI output, even on 150% it still showed 96)
  2. The problem is we have no idea who is changing the display settings, and our process should not be held hostage to server settings that anyone can change.

I’m not sure if setting the DPI is going to make a difference though. Isn’t there some other setting we can check to force the graph to fill the entire image?

@Hannodb

It seems that after the server is booted, it’s display settings may be affected by the first login client if you use remote desktop.

Will the issue go away if you set display settings back to 100%?

It appears so. When we set it to 150% and ran our process, the graphs were shrunken. When we set it back to 100% again, and reran the process, the graphs looked fine.

Could you please log the following output on the sever with different display settings?

using(Bitmap b = new Bitmap(100, 100))
{
    Console.WriteLine($"Image resolution: {b.HorizontalResolution}, {b.VerticalResolution}");
    using(Graphics g = Graphics.FromImage(b))
    {
        Console.WriteLine($"Graphics DPI: {g.DpiX}, {g.DpiY}");
        Console.WriteLine($"Graphics PageScale: {g.PageScale}");
        Console.WriteLine($"Graphics PageUnit: {g.PageUnit}");
        float[] matrixElements = g.Transform.Elements;
        Console.WriteLine($"Graphics transform: ");
        for(int i = 0; i < 6; i++)
        {
            Console.Write($"{matrixElements[i]}, ");
        }
        Console.WriteLine();
    }
}

Just waiting for the IT guy to become available again, but this is the values on 100%

Image resolution: 96, 96
Graphics DPI: 96, 96
Graphics PageScale: 1
Graphics PageUnit: Display
Graphics transform:
1, 0, 0, 1, 0, 0,

@Hannodb,
Thanks for your details. We will investigate and analyze your issue in details. Once we have an update on it, we will let you know.

@Hannodb

Thanks for your sharing. Waiting for your outputs/findings with other display settings.

Sorry for the long delay, I had to wait for our infrastructure guy who was on leave.
Here is the output for 150%:

Image resolution: 96, 96
Graphics DPI: 96, 96
Graphics PageScale: 1
Graphics PageUnit: Display
Graphics transform:
1, 0, 0, 1, 0, 0,

It seems like the display settings made no difference.

@Hannodb,

Thanks for providing details of other display settings.

Let us evaluate your issue further. We will get back to you soon.