Virtual pixels and scaling

Now that iPads and retina displays and variations in PC screen size can run from 1024 to 2560… the world as we know it has changed. Being able to zoom and having various pixel density display technology is not all there is to it. GPU cards also scale and smooth the rendering as does the code in the browsers, so maybe 5 or 6 hefty chunks of tech and software intervene to either software smooth or possibly inflict device-specific GPU driven rules of  image handling.

Depending on your device, the images above will either look identical, or ( as in an ipad zoom ) the one on the left is pixeled and the one on the right stays ok. Of course adding Anaglyph 3D to the mix of dependencies increases the problems of tending to visual accuracy even more, generally making all images blurry anyhow until you put on your retro 3D glasses. ( another story for later )

The solution does include the need for high bandwidth…

the image on the left is 25kb the one on the right is 150kb.

The problem is industry-wide and spans these cases:

1) HDTV – as more HDTV 1920 x 1080 displays get connected to the web, the more evident it becomes that variations on pixel density over distance will matter. A 32 inch 1080p looks stunningly accurate up close where the same image looks rather soft or jaggy and fuzzy with the same image up close on a 65 inch tv. Both resolution and device physical dimensions come into play. Virtual pixels help manage the dramatic differences in Dots Per Inch of display area.

2) iPhone4 The Retina display – 328 or so pixels per inch in a smartphone 4 inch or so form factor "fixes" a problem that doesnt much need fixing, but it does look nice and by practical means, zooming on that display is far more enjoyable.

3) iPad – just the ability to pinch zoom is a scaling "virtual-pixel" gamechanger – mostly because it processes to 'sharpen'  the image in post-zoom code ( you can easily see it doing that though it is not documented for coders to manage ). The ability to easily zoom and the inherent GPU device-specific scaling behaviors must be dealt with properly. We do several pre and post processing technology efforts for making this work.

In 300DPI publisher formats for 11 x 17 ( we get that a lot ) the accuracy vs size of dot density is not compatible with pixel-based displays, causes lots of processing problems for PageBlend to tend to. Much of our code and prep is based in knowing the issue and doing re-design to preserve the original feel of the art in the new context of 300 dpi source to 72 dpi screen typical less resolution delivery accuracy, and do that  with immediacy. ( Avoiding the Zinio + Zmags zoom image recovery cycle required by simple-minded PDF conversions )

The user experience should not be interrupted by image cleanup – post-fetch correction, when as in PageBlend, it can be seamless.

Basically when you have a book in PageBlend, extra effort, code and Bandwidth all are brought together to preserve the visuals with no post process lag to  "fetch the highres image ". It is immediate and across  PC to HDTV. Videos arrive and play right on time.

 

BANDWIDTH:

THE PROBLEM IS GENERALLY THE LAST MILE OR THE LAST 30 FEET ( wireless )

We are quite good at exerting command and control over creative and applying solutions, but it comes at some expense of one thing we cannot control…  the stark hard reality of user endpoint bandwidth. ( Google know this, they want to fiber connect a whole town to prove it too… )

It generally takes 5-6x the filesize and bandwidth to deal with this. But the problem is even more complex in that it doesnt matter if you have massive server horsepower like we do here… because the bottleneck will be at the LAN/WAN local wireless. This is not even a last mile problem, its a last 30 feet problem that is challenged by all the radios of competing wireless devices. If you have an iPhone, iPod, iPad, iMac all running on the same desk .. you have 4 radios competing at the same wavelength for communication attention to a single router in a single connection. All it takes is the kid in the next room to add a YouTube video to the load of the system and you are basically going to stress the dataflow… there is nothing anyone can do about that, so making the arrival bandwidth satisfy a profile happens at the designers desk. This means bumping the files a bit with no obvious loss of quality. We will not tell you how we do that, but rest assured its a big part of what we do.

We urge browser coders to please make the client-side tooling work with even less code for the HTDV enabled systems… that is required to allow is to satisfy this emerging need.

3D