Re: [RFC] Reading images

[Pascal J . Bourguignon]

Alexander Malmberg writes:
> Pete French wrote:
> > > When the device is not 72 dpi.
> > 
> > O.K., rephrase the question - when is a screen device ever assumed
> > to be anything other than 72dpi ?
> 
> When is a screen device ever assumed to be 72 dpi? I don't assume that
> it is, postscript doesn't, and dps doesn't. They were designed to be
> independent of such things.
> 
> That said, most implementations do assume that a screen is 72 dpi. 

Falsely.

> For a long time, it has been a reasonable assumption. 

For a long time it's been way off.

72 dpi = 25.4/72 =  0.35277 mm of so called pitch.

Currently, low end CRT have a pitch of 0.20 mm, or 25.4/0.20 = 127 dpi!
Almost the double than Pete's assuming...


> It hasn't really been true, but it has been close enough that users
> haven't been bothered much by it (with a few exceptions; text is
> often the first thing to cause trouble, so in eg. windows and X, you
> can scale text (sortof), but nothing else).

It's far enough  so that it have been bothered users  for a long time,
but users are known to be sheeps able to pay to use bothering hardware
and software, and the fortune of Bill Gates is build on this fact.
 

> However, although the assumption is reasonable today, I don't think it
> will stay that way. 

When you have a 15" LCD with 1024 x 768, that makes: 85.3 dpi.  If you
was a  little richer an have  today a 17"  LCD with 1280 x  1024, that
makes almost 100 dpi.


If you have a PDA with a 320  x 320 screen, you've got a 148 DPI, more
than the double of your expected 72 dpi!


> Thus, I want to warn people that they shouldn't write code that
> assumes that a screen is 72 dpi. That assumption is not part of the
> rendering "interface" we have, and if you write code that way, it
> won't work on systems where the screen is not 72 dpi.

There is  still one legacy we should  overcome.  In NeXTSTEP/OPENSTEP,
the pictures making the elements of scrollbars and some other buttons,
were bitmaps designed for a  given screen resolution, instead of being
defined  vectorially.  I  assume the  same is  done in  GNUstep.  This
should be  corrected.  How could we expect  application programmers to
be resolution-independant, if the scrollbars and window-title bars are
drawn in a fixed number of pixels?
 

> There has been some discussion in the GNUstep ml:s about extending some
> of the backends to handle non-72 dpi rendering, but I don't think anyone
> has done any serious work on it yet. back-art should be able to render
> things ok, though, and a long time ago (early version of back-art, which
> is why there are no images) I did hack the x11/ server part to scale
> things:
> 
> before:
> http://w1.423.telia.com/~u42308495/alex/backart/backart_scale_3.png
> after:
> http://w1.423.telia.com/~u42308495/alex/backart/backart_scale_1.png
> 
> Looked nice at 1808x1356 on a 17" screen. :) Event handling wasn't done
> properly, though, so you had to guess when trying to click something.
> 
> > Though I think the bit below answers
> > that... is this a GNUstep specific problem by the way ?
> 
> Screens that aren't 72 dpi? No. It seems that many other gui:s are
> trying to shift to device independent/vector based/scalable rendering.
> We're already there, we just need to be careful not to make invalid
> assumptions.

In MacOSX, at least  the icons can be scaled at will,  and all but the
olders 32x32 look very nice at whatever scale.

> > I am sure that under OpenStep it was stated that the screen was
> > assumed to be 72dpi no matter what the actual screen resolution was

Actually no.   The original NeXTdisplay  was 96dpi, and that  was what
was  assumed for  the bitmaps  in NeXTSTEP.   For sure,  the  open API
specification OpenStep says nothing about specific device resolutions.


> I can't find any mention of it in OpenStep after having a quick look at
> it. It might have been stated for OPENSTEP. Either way, if it was
> stated, I consider it an implementation limitation, fairly reasonable at
> the time, that GNUstep has fixed.
> 
> > (which of course depends
> > on the visible area fo the physical screen and the resolution, plus whatever
> > monitor controls the user has tweask and is thus effectively unknown).
> 
> True. The user would have to configure it. Actually, strictly using the
> real dpi of the screen isn't perfect either. Eg. a user with impaired
> vision might want to scale things up beyond the real dpi of the screen.
> 
> > > In practice, most systems pretend to be 72 dpi for performance and
> > > simplicity, and because they can still get away with it (although
> > > screens are approaching resolutions where you really need to scale
> > > things properly; one of our strengths is that we already have a device
> > > independent rendering model, so as long as people stick to the
> > > interfaces, we can easily handle the switch to non-72 dpi screens).
> > 
> > If thats true, then what do you think the correct behaviour of
> > initWithFocusedViewRect:(NSRect)rect should be then ? The documentation
> > doesnt specify it one way or the other.
> 
> Not explicitly. You might want to look at the documentation for the DPS
> operators sizeimage and readimage, though.
> 
> > The easiest way is to do it in
> > screen pixels I guess - but then how do I guarantee to create a 512
> > square image under those circumstances ?
> 
> Depends. If you just want to use it to render back to the device, it's a
> good thing that the image is in device resolution. 

It  WAS a  good thing  at a  time  when RAM  was measured  in 8MB  and
processor frequencies in 25 or  33 MHz.  But nowadays, RAM is measured
in 256MB  ifnot in GB, and  frequencies in GHz: you  better spend some
time on scaling  and smoothing bitmaps than to stay  idle, and even if
you do that, you'll have enough cycle left to compute seti work units.


And don't forget than 3 or 4 years from now, everybody will have 64bit
processors with 5 o 8 GHz frequencies, and 8GB of RAM.


> If you want an image with a specific size in pixels, you'll need to
> figure out the transformation between user space and image space
> (that's the 'Matrix' entry) so you know what size the original
> rectangle you draw in should be.
> 
> - Alexander Malmberg

-- 
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.