I've tried to concieve this site as a functional tutorial.
In digital image editing, the meaning of words such as "resolution" or "size" can slightly vary according to context subtilties, sometimes within a same sentence, which can still be confusing to some... And annoying when slowing down collective work ;-)
Also, there is no "official" use of these terms, and anybody usually swaps them for each other, which worsens confusion. - In the end, someone who doesn't understand exactly what measurement is expressed every single time they utter any of these words, can hardly keep up with what is debated over.
So let's start with the beginning:
A digital picture is mainly a string of numbers, defining a dot matrix. Each dot is a number expressing a pixel - a point of a certain hue, brightness and saturation, located in the picture correspondingly to the number's location in the matrix. The larger amount of numbers in the matrix, "the tighter the grid", and finer is the detail. That is what the concept of "resolution" is about. Most often it means either "amount of pixels" (or digital dimension), either "fineness of detail". Despite the great similitude of such concepts, I'll try to bring attention to the subtle differences. We'll see further on.
A string of number is nothing physical
(how it is physically stored in cards or hard drives, or wired, or networked,
reaches out of context).
Therefore that grid, or matrix, is a mathematical abstraction, although very visual
(and truely visualized, for example, when displayed on a dot matrix monitor).
That string of numbers, among the head-spinning amount numbers constantly hurtling
inside any piece of digital circuitry, is isolated and kept together as a
formatted piece of data called file.
Finally, all we need to know is that we consider and manipulate abstractions called
files, as if they were actual pictures.
The whole range of high-precision devices, whose function is to present the
abstraction of something digital as a perceptible and handlable
reality to our physically-bound senses,
have humorously been grouped under the gross term 'hardware'.
Since files are a concept granted for facts, we speak of their content
we view and process through our computers as virtual reality.
Now, more numbers means a bigger file. The only reason why this is important is that consequent storage devices ('memories') may be costly, and file transfers aren't instantaneous (they're 'a certain amount of numbers [or 'bytes'] per second only).
So:
Finer detail = tighter 'grid' = more 'dots' = more "pixels" = longer string of numbers
= more 'digital storage room' occupied in the hardware ("memory") = larger "filesize" or "heavier" file = finer detail.
Let's say that the "memory" issue in this last paragraph
is highly true for uncompressed, unlayered file formats, e.g. BMP,
and relatively true for others ;). Compression is profusely used nowadays
but won't be reviewed here because there'd be so much to say.
The whole question is: how much detail do we exactly need, on final support ? It all depends on the work's purpose and destination, and maximum expected paper size (or viewing size, if destination isn't paper). The destination of the work should be known and remembered throughout the whole work. If it varies in time, these "resolution" or "memory" issues have to be looked back at.
Either we edit digital pictures for the web, and it would make no sense that they contain more pixels than an average monitor can display. Either we design to print that picture, making it physically exist.
Paper has a physical dimension usually expressed in centimeters or inches. On paper, the eye needs a minimum fineness of detail, that is, a minimum amount of dots per inch, to percieve the image as a good imitation of reality, and not see the dots, or pixels, anymore. The total amount of dots needed to fill the paper depends on, 1- the dimension of the paper picture, 2- the fineness of detail required. The amount of pixels in the digital file must be the total amount of dots to print on paper - at least. One can say that the detail fineness (DPI) is the relation between physical and digital dimensions. The relation is such:
DETAIL FINENESS (dpi) = DIGITAL DIMENSION (pixel) ÷ PAPER DIMENSION (inch)
where Detail Fineness means fineness expected from picture on final physical support,
and Paper Dimension stands for final picture dimension on physical support.
As a three-term formula, it can be turned around to deduce any parameter from the two others.
DIGITAL DIMENSION (pixel) = PAPER DIMENSION (inch) × DETAIL FINENESS (dpi) PAPER DIMENSION (inch) = DIGITAL DIMENSION (pixel) ÷ DETAIL FINENESS (dpi)
The principle behind this simple formula must be well understood, and got familiar with ...because it gets trickier when applied counterwise, at scanning. If you scan.
Supposing you don't scan: The picture is computer generated, or comes from a digital camera - just the same. It has never existed physically before, and therefore comes only with pixel dimensions. If dpi or pixel data comes along, ignore it, replace it - whatever. It's irrelevant until you set it. All you need is be sure you get the right amount of pixels from the source. Quite easy.
But now, let's say you scan. A scanner is a device which creates a digital file from a physical source. So what you need is to get the right total amount of pixels out of the scanning device. If you can directly type in the required resolution, in pixels, into the scanner's interface, that's convenient. But most of the time, you're supposed to know the accuracy required from the scanning head. That is, the fineness of the detail the scanner can read from the surface of the original support (e.g. paper, film). It is usually set in 'dot per inch' too, and the formula is quite similar to the former:
DETAIL ACCURACY (dpi) = DIGITAL DIMENSION (pixel) ÷ ORIGINAL DIMENSION (inch)
where Detail Accuracy means detail accuracy of the scanning process,
and Original Dimension stands for dimensions of the picture on the original physical support.
The combinations of those two rules has to be kept in mind from the beginning throughout the whole physical / digital / physical chain. Here's an example:
DIGITAL DIMENSION (pixel) = MAX. FINAL PAPER DIMENSION (inch) × FINAL DETAIL FINENESS (dpi)
DIGITAL DIMENSION (pixel) = ORIGINAL SUPPORT DIMENSION (inch) × MIN. SCAN ACCURACY (dpi)
=>
MIN. SCAN ACCURACY (dpi) = DIGITAL DIMENSION (pixel) / ORIGINAL SUPPORT DIMENSION (inch)
=>
MIN. SCAN ACCURACY (dpi) = FINAL DETAIL FINENESS (dpi) x MAX. FINAL PAPER DIMENSION (inch) / ORIGINAL SUPPORT DIMENSION (inch)
It is the similarity of units, in the absence of exact terminology, that makes it so hard to grasp. Any of the both 'size' or 'resolution' being lightheadedly used to express any of the different formula operand. ('size' can even stand for the filesize, the amount "digital storage space" occupied in the hardware).
That means: minimum scan accuracy [dpi@scan] grows when excpected final detail fineness [dpi@print] grows. minimum scan accuracy [dpi@scan] grows when maximum final physical dimension [inch@print] grows. minimum scan accuracy [dpi@scan] grows when original support dimension [inch@scan] shrinks. Since original support and expected final support can be of very different dimensions (take a 135mm film and a 6"x9" poster), a confusion between "dpi at input" and "dpi at output" can be deadly.
What pushes the confusion further, is the 'million pixel' counting. Megapixel is a new buzz word of expressing a captor's resolution as the total amount of pixels (= the product of the matrix's both dimensions), instead of both dimensions distinctly. That 'matrix surface' doesn't correspond to any wide-used expression of a physical support's size, or a physical/digital/physical chain's detail fineness, as a surface-related measurement.
It sure makes perfect sense to express a camera's resolution in
pixels (it delivers a file, nothing physical, inch and dpi being inconsistent data if given at
that stage). But expressing the total amount of pixels instead of both matrix dimensions
(like
Understanding through the Dynamic Table:
So I've tried to make the relations between
pixel size, paper size, dpi, and so on, appear as clearly
as possible on a two-dimension table. That's what that
Dynamic Table
is about.
Relations between values should be simply understood by following
horizontal or vertical two- or three-cells groups at once.
What makes the ensemble seem chaotic is that
the modification of one single parameter often spreads in all directions,
branching out from other cells and through the whole table.
Some of these relations are presented here below, as reliable, unalterable formulas.
A professional needs to handle these relations intuitively.
Try poking numbers around in the table, noticing how the rules listed
below always apply. First try to isolate the action of each of these rules,
as its effect instantly spreads from any altered cell to its whole columns
(try with the 'Pixel Lock' on and off). Then to its whole row (playing
width the ratio-related parameters).
Hopefully you'll end up grasping a familiar picture of the whole relation complex.
The following rules always apply, no matter what* :
1 CM = 2.54 INCH WIDTH(px) = WIDTH(inch) × RESOLUTION(dpi) HEIGHT(px) = HEIGHT(inch) × RESOLUTION(dpi) WIDTH(inch) = WIDTH(px) ÷ RESOLUTION(dpi) HEIGHT(inch) = HEIGHT(px) ÷ RESOLUTION(dpi) WIDTH(px) × HEIGHT(px) = SIZE(million px) :-) RATIO = WIDTH ÷ HEIGHT WIDTH² = SURFACE(SIZE) × RATIO HEIGHT² = SURFACE(SIZE) ÷ RATIO *if they don't, that's a bug ;-)
"Dot per Inch" may here be understood as "Pixel per Inch".
In the table's red and blue columns, the relation of units
I haven't included the less usual unit 'dot-per-cm': 1 dpcm = 2.54 dpi. Voilą.
Now pay attention to the disposition of the elements in the table:
- The 1st colored row expresses paper dimensions, in inch.
property of the physical domain (nothing digitally relevant).
- The 2nd colored row expresses detail fineness, in "pixel per inch" (dpi).
factor linking the one above with the one below.
- The 3rd colored row expresses pixel dimensions, or size in pixels.
property of the digital domain (nothing physical).
- The Red column expresses Width
in all units and domains (physical/digital).
- The Blue column expresses Height
in all units etc.
- The Green column expresses 'surface' only in pixel, because it isn't common to express a
picture's size in terms of surface.
It doesn't make more sense, in my opinion,
to express pixture's pixel size as a surface, and
I'd like to bring down all those "awesome" millions of pixels
we're fed up with in advertisement:
You'll notice, in the dynamic table,
how small changes are induced in other parameters (including width and height in pixel)
by a change of size from, let's say, 6 to 8 millions of pixels.
- Since not everybody is used to juggle with inches,
a top row expresses the corresponding values in
centimeters.
- The 'Pixel Lock' checkbox should definitely not be left appart !
The Dynamic Table is designed for physical/digital or digital/physical domain units converion. For the whole physical/digital/physical chain (that is, from scanning to computer work, then from computer work to final destination), two Dynamic Tables would be needed simultaneously, with only pixel dimensions in common
Always remember than the only reality you alter inside a computer is the digital reality. That is, the amount of detail recorded as numbers in the file, and supposed to be large enough to retrieve an acceptable impression of reality on a given final support. That is, the dimensions of a more or less abstract "pixel grid" or "dot matrix".
Changing DPI or Inch Dimensions in a picture file's properties, merely sets up printing parameters. They can be changed again and again later on, without the slightest bit of precision loss in the recording.
However, any alteration of the pixel size of a file completely reorganises the string of numbers, discarding some, duplicating some, and interpolating in both ways with random success. The loss of precision is obvious when decreasing pixel dimensions, but it is never inexistant when increasing them. It does affect the product's detail, in an either noticeable or unnoticeable way. So, resampling (= any operation altering pixel size) should be cautiously thought over before applying. Also Avoid, when possible, multiple resampling of a picture through your working on it, when it can be done all at once. And when to do it? Upsampling (= to increase the amount of pixels) early in the work, or downsampling at the end chain gives best fineness to the affect you'll add further on, but makes the file "heavier" (= slower to open, save, process or copy).
Digital display issues:
A computer display (a monitor), gives a view of the digital domain.
In in most cases when the destination is a monitor (and certainly for web applications),
it doesn't make any sense to speak of dpi or inches (or centimeters;).
A dot that you view on your computer display corresponds to an actual number (or pixel) in the file
only if the interface's "zoom ratio" is set to 100%. Whith such zoom tuning,
it is often impossible to view entirely a picture file that would have been sized for future printing,
since it has a pixel dimension exceeding the one of your monitor's "grid" (in other words, it contains
more pixels than your computer can display - in current mode or at all).
You can watch pixels more closely by setting a zoom ratio far higher than 100%,
on a viewing software that wouldn't interpolate the view at high ratios
(e.g.: Photoshop, yes - ACDSee, no).
Some more random hints:
It is vain to hope enhancing an image's detail by just increasing the
resolution of a digital picture file.
However, if the final destination
requires a higher resolution, then the resolution should be increased
prior to any digital effect other than color filters. So although the original
image won't gain in detail, the effects will. With enough skill
the overall quality can be noticeably enhanced.
Now check out these : the
Dynamic Table
or the
Static Table.
That's it.
There could be no end to the exploration of units,
but this was good basics I hope.