Digital Light & Color

I recently discovered that Picture Window 8 was not operating as a DPI-Aware program even though I thought it was. A DPI awareness feature was added to Windows a few years ago to support high resolution monitors whose Scale and Layout as specified in the Windows Display Settings is greater than 100%. Since high DPI monitors have very densely packed pixels, unless you magnify the display fonts and icons, they come out tiny and hard to click on or read. The default behavior for non-DPI-aware applications is for Windows to simply scale everything up which makes windows, fonts and icons larger, but does not take advantage of the higher resolution of the display and the results are blurry. This is what has been happening for all versions of Picture Window up until now. I had noticed the display did not seem as crisp as with some other programs, but had assumed it was some difference in the way I was resampling images for display.

To create a DPI-aware application, the program must do all the scaling since the display operates at full resolution. In and of itself, this is not that hard to do, but the real problems come when you have multiple monitors and their scale factors are different. This requires that when windows are dragged from monitor one to the other, the entire user interface be rebuilt on the fly, otherwise the fonts and icons will be too big or too small. As you can imagine, this is not a trivial task since every window and dialog box needs to be reworked.

I now have a version of Picture Window that operates as a DPI-Aware program that appears to works OK at full resolution, unless you have multiple monitors with different scale factors. It is likely to be a while before I can make all the necessary code changes to get this part working, so the next release may be delayed by a week or more.

Once this is fixed, if your monitor or monitors all have a scale factor of 100%, you will not see any difference, but for large, high dpi monitors the display will get much sharper and 1:1 images will display smaller.

Did all of us with 4K monitors miss this? A sobering thought. No wonder photographers keep quoting Cartier-Bresson: "Sharpness is a bourgeois concept."

Just as an off-the-cuff tip for everyone: open the Help-->About Picture Window Pro dialog. The pixel dimensions and depth of your display as recognized by the program are listed there.

In my case, on a 4K screen at 200% scaling in the Windows 10 display settings, that's 1920x1080@24bits/pixel shown in the dialog.

If I create a new image 3840x2160 in PWP8 and impose an 8 X 8 grid on it, set the image display factor to 1:1, then the image data is displayed at 200%, i.e. a part of the image exactly 1920x1080 would be displayed if PWP8 could display images full-screen at 1:1 without any window frames and other controls.

If I explicitly adjust the scaling behaviour for PWP8 in the shortcut's Properties-->Compatibility-->Change High DPI settings to "Scaling performed by Application", then no scaling is performed by Windows, everything appears 1/4 the size, and the About Picture Window dialog shows the real pixel dimensions of the screen as expected.

The whole business of high DPI screen scaling is confusing in Windows for a graphics program: I would expect the window frames and controls to observe the user's scaling preference, but I would want the actual image pixel data when displayed at 1:1 to be at 100%, each pixel in the data to be one pixel on the screen.

So I will really appreciate when this extra programming work is complete. Microsoft certainly doesn't seem to make it easy for the programmer.

What Microsoft has done is actually not unreasonable. The mode where Windows scales everything is good for older applications or those that do not need higher resolution. The mode where the application scales everything is good for applications willing to do the extra work to take advantage of the full resolution. If I had not accidentally overlooked this issue when I started out, I would not have to do so much rewriting now.

Well, I didn't mean to imply that MS had implemented unreasonable requirements for program design (I'm not a programmer), but I wonder, for instance, how Apple (I'm not a Mac user) handled the introduction of the high DPI "Retina" displays a few years ago: did graphics programs have to be redesigned, or was compatibility some how stuffed into an operating system layer beneath the application programs (a bit like what they apparently did in embedding color management by default for all graphics programs, no special arrangements required)?

Anyway, I'm just happy and grateful you are doing something about this issue.

Good question -- I have no idea what approach Apple took.