Resolution - DPI, PPI LPI (was: Wide PNG's displaying only coloured stripes?)

2007-02-06 Thread Ian Wood
This is getting into a pretty complex realm. I hope what follows is  
useful rather than rant...


On 6 Feb 2007, at 13:16, David Bovill wrote:


There are lots of time when you need to make these calculations - due
usually to information or interfaces provided by other software (often
defined primarily for print) - in my case I need to pass inches to the
shell and therefore convert to inches from the rect in Rev,

So the question is exactly what is involved in moving from lets say
640 x 480 image rect to a value in inches that you must supply to a
piece of print orientated software? At one time I thought it was just
72 dpi = an inche - but then I never got straight the use of points
and pixels and dots per inch.


A 'point' is a typographic real-world measurement, and is ~0.3mm. So  
12pt type should be around 4mm high.



I know what dpi are in print world - I
know (I think) what pixels are in the screen world. That is i think
I do :)

   - Pixels are little glowing spots on your screen


Yes.


  - Dots are little non-glowing spots of colour (usually on paper)


Yes, but strictly speaking this is for for inkjet printers - laser  
printers and commercial printing are actually measured in *lines* per  
inch and the images themselves are measured in *pixels* per inch.



   - the rect and loc etc in Rev refer to pixels of glowing colour


In general, ALL screen measurements refer to pixels, regardless of  
the program, and these pixels don't have a fixed size.



   - inches and other conventional measure refer to fixed distances
in space (relativity not withstanding)


Yes, generally with no relevance to images shown on screen.


  - to get from pixels or dots to some real physical measure you need
to know the number of pixels or dots per unit of space on the output
device concerned (paper or screen)

   - dpi is this factor and the dpi of monitor screens used to be
72dpi I think all though tis should really be pdi for pixels per inch
or gdpi for glowing dots per inch. 96 is another  number entirely.


Puts on pedant hat:

DPI only applies to scanners and inkjet printers.
When you talk about the actual image file you are talking about  
*pixels* per inch.
PPI is almost a 'made-up' measurement - the file may have a ppi  
measurement, but all it does is tell the program doing the printing  
'print it at this size'.
The only 'real-world measurement' that is in ppi is the pixel density  
of fixed-resolution displays such as LCDs.


72ppi  96ppi - it *used* to be roughly true that Macs used screen  
resolutions that generally worked out at 72ppi (e.g. 1024px across  
14 width of screen) and Windows machines generally used screen  
resolutions that gave 96ppi. But this is long-gone.
What it left behind, though, is that these are normally the figures  
used for working out how big text of a certain 'point' size should be  
shown on screen. This is the reason why Macs are assumed to be 72ppi,  
as they were heavily geared towards desktop publishing, and the most  
common font sizes are multiples of 12 - fitting into 72ppi was easy  
to do.
Obviously, as you can run the same CRT monitor at 800x600, 2048x1600  
or whatever, those assumptions are just assumptions.


If it's being shown on screen the only sensible measurement is the  
total pixels and how much of the screen that takes up. If you have to  
show things on screen in a specific real-world size then you have to  
get in to all the stuff where you get people to measure distances on  
the screen with a ruler, as per one of the recent threads. And it  
*will* involve measuring both vertical and horizontal distances,  
given how many screen resolutions end up having non-square pixels. :-(



Can someone help me here - I think I am in the wrong tree - how do I
know the dpi factor to use in a conversion?


What are you trying to convert? If you have some specific examples of  
what you want to do, I can probably say how to do them - I'm a  
photographer and designer who also programs, so this is my home  
field. ;-)


Hoping I've not gone overboard,

Ian
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Resolution - DPI, PPI LPI (was: Wide PNG's displaying only coloured stripes?)

2007-02-06 Thread David Bovill

No thanks a lot for the info!

In simple terms I have a piece of graphing software which I can
control in various ways - one is to set the size of the resulting
image. The image will be scaled proportionally to fit into this
size. Now the size is in inches so you can basically pass the
programme size=41.6667,41.6667 and it will scale the image to print
it within a square of about 41 inches.

Now I wanted to be able to figure out how many inches to set the size
in order to get 4000 x 4000 pixels and wrote a function:

on convertSizeToInches @pixelSize
   set the numberformat to 0.
   repeat with itemNum = 1 to the number of items of pixelSize
   put (item itemNum of pixelSize) / 72 into item itemNum of pixelSize
   end repeat
end convertSizeToInches

Now looking at the resulting image which should be 41.6667 inches wide
- it ends up being 4014 pixels according to the Finder and the
formattedwidth property of the image. This means then that the
software is using 4014 / 41.6667 = or just over 96dpi. Now i guess
what you are saying is this is just arbitrarily set by the graphing
software and there is no real way of figuring it out from first
principles?

I have a similar problem with GoogleEarth where I need to figure out
how many pixels on screen is a kilometer at a given height?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Resolution - DPI, PPI LPI (was: Wide PNG's displaying only coloured stripes?)

2007-02-06 Thread Richard Gaskin
With all the DPI, PPI, and LPI we forgot the beloved twips.  Fortunately 
there's little to learn at the moment on that since they're going away:

http://visualbasic.about.com/cs/visualbasicfaq/a/dykpixeltwip.htm
We'll miss them. :)

Resolution independence is a big hairy mess.  Useful, but a mess just 
the same. During this transition we can expect it to be almost as 
complicating as Unicode considering the breadth of its scope and the 
ever-increasing range of display devises.  Heck, with just the Macs in 
my office I have three different PPIs at play.


Apple has some UI notes on resolution independence:
http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/

The upside is that for the long term it seems we'll eventually need some 
sort of scaling factor built in to handle all of the vectors throughout 
the engine, and once that's done it should be a snap to extend that to 
allow us to build zoom-in/zoom-out features into any of our apps.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution