PixInsight Prerelease Version: 1.8.4.1189

[mschuster]

Hi Juan,

It was a mistake to mention 1:2 zoom in my post. That is not the issue.

At 1:1 zoom I would like to see one actual image pixel map to one actual physical monitor pixel always. Too me this means hi-res display.

Thanks,
Mike

[Juan Conejero]

At 1:1 zoom I would like to see one actual image pixel map to one actual physical monitor pixel

Then we'd have two image pixels per logical screen pixel. Pointing device coordinates (mouse for example) are in logical pixels, that is, they are mapped to a 2560x1440 virtual resolution. The same happens with all control coordinates and control dimensions represented on the screen. In other words, the logical pixel is an atomic unit. So under these conditions an increment of one pixel in the cursor's position would correspond to two image pixels and one viewport unit. You would see coordinates changing as 0, 2, 4, ... or -1, 1, 3, ... as you move the cursor over the image at 1:1 zoom.

This is obviously problematic, since at 1:1 zoom ratio everything on the platform expects one viewport unit to correspond to an increment of exactly one image pixel. However, I think it could be doable as a "special zoom" case. At least at first sight, the required changes shouldn't be severe if this is implemented as a special visualization mode with limited interaction capabilities. I'll think about this.

This problem does not happen with vectorial contents, since for vector-based representations the coordinate systems are continuous naturally. However, IMO the discrete nature of digital images is not well suited for OS X scaled modes in applications requiring accurate pixel-level interaction.

[bcole]

Interesting, I'll try to find where I was reading same problematics about another image processing software with the Scaled OSX resolutions.

I'll wait tomorrow to test the .1189 trial when available. I'll be in studio where I actually attach my Retina Macbook to an external (non-Apple) HiDPI screen, so I'll check how it all behaves between a native Retina scaled screen and another HiDPI external one.

[Juan Conejero]

Good news: I think I have managed to achieve an optimal solution for high-dpi modes on OS X. Here is an example:

http://forum-images.pixinsight.com/20151112/1.8.4-osx/Desktop-lena.png

This is a screenshot taken on a 27" iMac working in an emulated 1280x720 high-dpi mode. The physical resolution on this machine is 2560x1440, so one logical pixel corresponds to 2x2 physical pixels in this emulated mode. This is how a typical Retina display works on OS X.

The classic Lena image used for this example is an 8-bit grayscale image of 512x512 pixels. To understand how the new version works, look at the above screenshot at full size. When working on Retina displays in high-dpi modes, the new version 1.8.4 of PixInsight for OS X renders zoomed out images using the full physical monitor resolution. In this way, at 1:2 zoom ratio the image is actually represented 1:1 using physical pixels. For odd reduction zoom ratios 1:3, 1:5, etc, a fast nearest neighbor interpolation is used to achieve effective ratios of 1:1.5, 1:2.5, etc. For zoom ratios of 1:1 and above, images are represented using logical pixels. So at 1:1 the image is actually represented 2:1 on the physical screen using logical pixels.

This feature gives us access to the full display resolution without modifying the existing viewport and image coordinate systems at a high level. This means that all existing modules and scripts will continue working unmodified, with just one exception. The only exception is the pcl::ImageWindow::ViewportBitmap() member function. in Retina high-dpi modes, this function returns now a bitmap with twice the specified dimensions for viewport zoom ratios equal to or smaller than 1:2. This is a breaking change that has to be taken into account by all modules using this function. Since I already had modified all standard modules with dynamic image generation capabilities to draw directly on viewports, the incidence of this change is very limited (only the Annotation tool uses explicit double buffering at this point, and hence it's the only one needing some work). This function has no PJSR counterpart, so it does not affect JavaScript scripts.

Fortunately, the internal screen rendering routines are highly modular, which has allowed me to implement this change in less than one day of work, including exhaustive testing. I'm starting to prepare a full rebuild of 1.8.4.1190 for Linux, OS X and Windows right now... after a good cup of coffee and a walk to stretch the legs...

[bcole]

Thanks!

That's good news Juan, looks like I choose right moment to test this out!

Will check later in software distribution of my trial account and will test it on the retina and external HiDPI monitor and will report back here.

[mschuster]

This is great news! Lena examples look excellent!

Thanks,
Mike

PS: Some scripts draw and hit test BitmapBox controls which are viewport clients. I need to double check this.