Consider the following image:

enter image description here

It looks quite good here on the site. (So probably this site and also my browser know how to display it with best quality).

Now the image can be uploaded into Mathematica to variable im and displayed in the notebook - three times

  • as im (letting everything on Mathematica's "will" how to display it)
  • as Show[im,ImageSize->ImageDimensions[im]] (to display it in its own dimensions)
  • as Show[im,ImageSize->ImageDimensions[im]/1.34] (to display it scaled by manually adjusted constant 1.34)


enter image description here enter image description here enter image description here

As you can see - the same picture but all three cases are displayed differently and with different quality. I would expect the best quality when the ImageSize is set to its own dimensions of image but as can be seen this case is the worst. Best quality was achieved by manually adjusting the scale constant. Also notice that the constant I chose makes the image looking almost identical as it is displayed in this site.

Why Mathematica do not know how to display image in its best possible quality? How to find the constant 1.34 by code and not manually?


Arguments that we can not compare image viewers with page-based software are unreasonable. Page-based software Chrome displays the image exactly same with exactly same
dimensions like image viewer IrfanView in perfect pixel dimension of the original image. (I did not use any special settings for IrfanView or Chrome anyway both agree on how to display the image.)

enter image description here

  • $\begingroup$ I find this discussion interesting but not suited for Comments; this conversation has been moved to chat. $\endgroup$
    – Kuba
    Sep 13, 2022 at 9:06

1 Answer 1


As I understand, you have these issues with version 13.x on Windows. The reasons for such behavior were previuosly discussed in the following questions:

Specifically for the image rendering quality I propose the following workaround which doesn't affect other parts of the system:

With[{resolution = 
   "Resolution" /. First[SystemInformation["Devices", "ScreenInformation"]]},
  GraphicsBoxOptions -> {BaseStyle -> Magnification -> 72/resolution}]]

Note however, that rendering of the image is also affected by the ImageResolution setting, which in the case of your image is set to {100, 100}:

Options[im, ImageResolution]
{ImageResolution -> {100, 100}}

By default, when the resolution isn't specified in an image itself, it is set to Automatic, what is equivalent to 72. dpi. independently of the true resolution of your monitor. The above workaround is developed for this case, since the situation when the resolution setting is absent is common. Hence with the above workaround you should also set ImageResolution -> Automatic for your image:

Image[im, ImageResolution -> Automatic]


The pixel-perfect rendering means that each pixel of the image corresponds to exactly one screen's pixel. Let us compute pixel size of the rendered image and compare it to the true pixel size:

screenshot = Import["https://i.stack.imgur.com/hL5Hm.png"];

crop = ImageTake[screenshot, {419, 847}, {94, 592}];
ImageDimensions@ImagePad[crop, -BorderDimensions[crop, 0]]
{486, 416}
{487, 416}

As you see, the rendering is still off by 1 pixel. This is really surprising, because ImageSizeRaw of the GraphicsBox produced in the Notebook is set to {487., 416.}:

Options[ToBoxes@Image[im, ImageResolution -> Automatic], ImageSizeRaw]
{ImageSizeRaw -> {487., 416.}}

Apparently, this is another bug of the FrontEnd rendering algorithm.

Alternatively, without changing the default settign for GraphicsBoxOptions, you could set ImageResolution equal to the true resolution of your monitor:

With[{resolution = 
   "Resolution" /. First[SystemInformation["Devices", "ScreenInformation"]]},
 Image[im, ImageResolution -> resolution]]


screenshot2 = Import["https://i.stack.imgur.com/DWJzA.png"];

crop2 = ImageTake[screenshot2, {348, 777}, {94, 593}];
ImageDimensions@ImagePad[crop2, -BorderDimensions[crop2, 0]]
{486, 415}

As you see, in this case the situation is even worse: the rendered image size differs from what is expected not only in the horizontal, but also in the vertical direction.

Response to the discussion in comments

@AlexeyPopkov, in a dpi scaling (aka device independent) world, pixel perfect is fleeting. It might be spot on for you on one machine, but wrong on another. Maybe that is good enough for a single user, but that would problematic when exchanging notebooks. – ihojnicki

We can easily see that Chrome by default always renders the image with pixel-pefect quality, so this argument is not convincing:

chromeImage = WebImage["https://i.stack.imgur.com/zGk92.png"]


{487, 416}

The same is true for the other browsers as well as small applications like MS Paint and IrfanView. Why then such a giant application as Mathematica can't do this?

Response to the discussion in comments #2

@AlexeyPopkov, so the native ImageSize for a bitmap is calculated using the following: N[ImageDimensions@img/Information[img, "ImageResolution"] * 72]. When the RasterBox is drawn, the viewbox is converted back to pixels using N[imagesize /72 * CurrentValue["WindowResolution"]]. If you want a 1:1 transform, Information[img, "ImageResolution"] must match CurrentValue["WindowResolution"] OR you manually specify an ImageSize. i.e., Image[im, ImageSize -> N[ImageDimensions@im/CurrentValue["WindowResolution"]* 72]]. – ihojnicki

@AlexeyPopkov, the difference between Chrome and Mathematica? Units. Mathematica, everything is in points (1/72nd of an inch). Paint uses pixels. Chrome uses a device independent pixel known as an angular measurement. AM is effectively 1/96th of an inch on a typical computer display. – ihojnicki

@AlexeyPopkov, probably because it was snapped to the pixel grid. The document's coordinate space uses real numbers, not whole integers. There is no user control over that. Could be a clipping bug (I know there are some on 96 dpi displays on Windows). – ihojnicki

Indeed, the check reveals that the rendered image is simply cut off on the right and bottom by 1 pixel. Implementing your second approach:

  Image[im, ImageSize -> N[ImageDimensions@im/CurrentValue["WindowResolution"]*72]], 
  "Output", Background -> Black]]


screenshot3 = Import["https://i.stack.imgur.com/6tXlr.png"];

rendered = ImageCrop@ImageTake[screenshot3, {312, 735}, {92, 591}];
{486, 415}
Max@Abs[ImageData[RemoveAlphaChannel[im]][[;; -2, ;; -2]] -

So it is a clipping bug.

  • $\begingroup$ So the constant 1.34 I found manually seems to be roughly 96/72=1.3333. I consider it to be a bug - impossibility of displaying images in precise pixel dimensions on monitor and also bad quality of rendering when resizing images. $\endgroup$ Sep 10, 2022 at 9:54
  • $\begingroup$ @azerbajdzan I agree, it should be counted as a bug. WRI appears to be giving this issue a low priority. Please report it to the support: the more reports from different users, the higher priority is given to the bug. $\endgroup$ Sep 10, 2022 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.