Printers and resolution - a historical perspective.

[Moglex]

1) Printers can, and do, interpolate.

Indeed, we can be reasonably certain that some printers interpolate.

2) What happened a quarter of a century ago is no longer relevant.

Oh, I'm afraid that is far from the case.

Decisions made during the design of architectures can and do have consequences for incredible lengths of time after the reasons for those decisions have slipped into history.

You have to remember that todays chips are around 1,000-4,000 times more powerful than those around when these GUI's were developed. Machines tend to have 16,000 times the memory.

Hard disks are up to 200,000 times larger.

The hard disk on one of those early cameras couldn't even hold an uncompressed image from a modern 35mm camera, now you can store several in memory.

These constraints framed the way elements of the GUI were designed.

3) Things change.

Indeed, but the fundamental software model of the GUI hasn't.

Changes happen,

A statement of the blindingly obvious, if I may say so!

such as device dependent journal files (that are resolution dependent) being replaced by EMF and EMF+ files that are not device dependent, and that carry more information than a simple bitmap.

Indeed. However, these are vector graphic files and as such are not relevant to dealing with bitmapped images.

I am still waiting, by the way, for backup for your statement that there are other ways for programs such as PSP and PS to print rather than the methods using bitmaps that are to be found in the Windows reference material.

Unless and until you can provide such backup there is still no demonstrated path for PSP/PS to send information to the PAD (printer and driver) in such a way that the PAD would know to expand it.

By the way, I wrote 'may be laughable'. The point of the sentence was to suggest that printer drivers can interpolate.

But as I pointed out, the statement is incorrect, here in 2008.

 

[Helen B]

I wrote: "They [printer drivers] can interpolate if they are asked to."

Moglex asked:
"Perhaps you would be kind enough to provide a source to back that up?

I'd certainly agree that you could write a driver that interpolated - indeed you could write one to do The BBC's payroll if you so desired.

What is unclear is what point there would be to doing so."

I was under the impression that the ability of printer drivers to interpolate/scale was a commonly-known fact. The ability to do so is necessary because of the existence of device-independent print files.

The Epson printer driver for the 2200 allows scaling, as do many other printer drivers. Photoshop often does a better job, particularly when it is under the user’s control – ie you choose the resampling method, and then apply sharpening after resampling (‘output sharpening&#8217. This is what I was referring to when I said that it is worth finding out what the best procedure was.

If you just let ‘a black box’ do the final scaling for you, you aren’t in control of the sharpening. If you are in control of the scaling you are more in control of the sharpening. Then you need to know what resolution to send to the printer to avoid further resampling as much as possible. The ‘sweet spots’ for many Epson printers, when controlled by the printer driver and not a third-party RIP, are 288, 360 and 720 ppi for the file resolution. The printer resolution can be set to 1440 or 2880. As an aside, newer printers, like the 3800, can use the same profiles for both 1440 and 2880. The previous generation of Epson printers needed different profiles for 1440 and 2880 dpi printing.

Referring to EMF:

However, these are vector graphic files and as such are not relevant to dealing with bitmapped images.

Here's what Microsoft say about them:
"EMF: Enhanced Metafile

The Enhanced Metafile format is a 32-bit format that can contain both vector information and bitmap information. This format is an improvement over the Windows Metafile Format and contains extended features, such as the following:

Built-in scaling information
Built-in descriptions that are saved with the file
Improvements in color palettes and device independence"


Best,
Helen

 

[Moglex]

I wrote: "They [printer drivers] can interpolate if they are asked to."

Moglex asked:
"Perhaps you would be kind enough to provide a source to back that up?

I'd certainly agree that you could write a driver that interpolated - indeed you could write one to do The BBC's payroll if you so desired.

What is unclear is what point there would be to doing so."

I was under the impression that the ability of printer drivers to interpolate/scale was a commonly-known fact.

A commonly held misconception I think is more likely. I think I can see where it's coming from.

The ability to do so is necessary because of the existence of device-independent print files.

'fraid not.

The metafiles of which you speak are simply played back uning exactly the same GUI API as originated them.

The Epson printer driver for the 2200 allows scaling, as do many other printer drivers. Photoshop often does a better job, particularly when it is under the user’s control – ie you choose the resampling method, and then apply sharpening after resampling (‘output sharpening&#8217. This is what I was referring to when I said that it is worth finding out what the best procedure was.

I think I have worked out where all the confusion is arising.

Do you believe that when you tell an application to print and a dialog box comes up allowing you to select such things as scaling and positioning that you are talking to the printer driver?

Because you are not. (A clue is that these dialog boxes differ from application to application for the same printer).

Certainly these boxes will allow you to set things that directly affect the PAD, but scaling is something that is handled by the application (which is why the facility is available on some applications and not others).

If you just let ‘a black box’ do the final scaling for you, you aren’t in control of the sharpening. If you are in control of the scaling you are more in control of the sharpening. Then you need to know what resolution to send to the printer to avoid further resampling as much as possible. The ‘sweet spots’ for many Epson printers, when controlled by the printer driver and not a third-party RIP, are 288, 360 and 720 ppi for the file resolution. The printer resolution can be set to 1440 or 2880. As an aside, newer printers, like the 3800, can use the same profiles for both 1440 and 2880. The previous generation of Epson printers needed different profiles for 1440 and 2880 dpi printing.

Before even I attempt to answer this, can you explain what you mean by a 'file PPI'?

The image in the file has a resolution measured in pixels in the x and y coordinates. The concept of pixels per inch for a file is meaningless as an unrendered image has no physical dimensions so you can't aportion pixels to them.

Referring to EMF:
Here's what Microsoft say about them:
"EMF: Enhanced Metafile

The Enhanced Metafile format is a 32-bit format that can contain both vector information and bitmap information. This format is an improvement over the Windows Metafile Format and contains extended features, such as the following:

Built-in scaling information
Built-in descriptions that are saved with the file
Improvements in color palettes and device independence"

Yes, I had my wires crossed there.

This is the windows extended metafile format.

As I said above, I'm afraid that doesn't get you anywhere.

In the first place it is simply recording function calls and parameters passed to the GUI together with extra descriptive material to allow Windows to optimally set the device context when an output device is selected at replay time.

It then simply replays the commands it received, so there is no magic way of using the facility to make the driver do scaling for you.

Secondly, no photo editing software worth its salt would want to output to a device independant format. It wants to know as much as possible about the device it's writing to so that it can optimise its operation for that device.

So we still seem to be in the position that there is no demonstrated path for an application to get the PAD to do the expansion/interpolation required to print an image that is smaller than needed to fill the space required.

 

[Helen B]

"Before even I attempt to answer this, can you explain what you mean by a 'file PPI'?

The image in the file has a resolution measured in pixels in the x and y coordinates. The concept of pixels per inch for a file is meaningless as an unrendered image has no physical dimensions so you can't aportion pixels to them."

I'm using 'file ppi' as the shorthand for the ppi that is assigned to the file in the editing application, such as Photoshop. Although an unrendered image has no physical dimension, the image file may contain information on what the physical dimension should be. The 'ppi' that I am referring to is the pixel dimension divided by the length dimension.

Best,
Helen

 

[Moglex]

"Before even I attempt to answer this, can you explain what you mean by a 'file PPI'?

The image in the file has a resolution measured in pixels in the x and y coordinates. The concept of pixels per inch for a file is meaningless as an unrendered image has no physical dimensions so you can't aportion pixels to them."

I'm using 'file ppi' as the shorthand for the ppi that is assigned to the file in the editing application, such as Photoshop. Although an unrendered image has no physical dimension, the image file may contain information on what the physical dimension should be. The 'ppi' that I am referring to is the pixel dimension divided by the length dimension.

Hmmmm

This is no getting slightly surreal! (probably because I'm misunderstanding something along the way).

Are you saying that you change the 'PPI' inside PS to get the best result on paper?

If so, how do you change the 'PPI' - i.e. how do you make the change (e.g. change resolution on resize) and how do you calculate what it should be?

BTW: I'm still no closer to seeing anything that suggests that the PAD must do the interpolation. And, believe me, I've tried!

 

[Helen B]

Hmmmm

This is no getting slightly surreal! (probably because I'm misunderstanding something along the way).

Are you saying that you change the 'PPI' inside PS to get the best result on paper?

If so, how do you change the 'PPI' - i.e. how do you make the change (e.g. change resolution on resize) and how do you calculate what it should be?

BTW: I'm still no closer to seeing anything that suggests that the PAD must do the interpolation. And, believe me, I've tried!

Nobody is saying that the printer driver must do the interpolation.

Re Photoshop etc.

Why do you think that a mundane operation is surreal?

Most photo editing software has the ability to resample to new pixel dimensions, and also to change the image length dimensions without resampling. The length information is usually included in the file header - including the file header for the Windows BMP format. It doesn't have to be there, but if it is, it can be used.

An example: you can take a 5102 pixel by 7654 pixel, 24 mm x 36 mm file (ie 5400 ppi) and change the header info so that it is read as a 17.7 inch by 26.6 inch, 288 ppi file (still 5102 x 7654 pixels).

Now, in Photoshop (or whatever) you can select certain ppi settings that produce the optimum output on paper. As I have mentioned a couple of times in this debate, for the Epson 2100 (UK) 2200 (USA), using the Epson printer driver, the magic ppi settings are 288, 360 and 720. 288 ppi produces the most accurate rendition on paper (ie the pixels printed on the paper most closely represent the pixels in the file). 720 ppi produces the highest resolution, however. If you use a third party RIP, the results will be different.

The practical application of this is that in this case it is better to produce the print-ready file at the correct length dimension in Photoshop at 288, 360 or 720 ppi, then sharpen (viewing the image at real-life size), then open the printing system (irrespective of which piece of software you are looking at).

Best,
Helen

 

[Moglex]

Nobody is saying that the printer driver must do the interpolation.

Oh, I think they are.

Bifurcator and garbz both seem(ed) to be quite convinced that it was the PAD that would scale (and thus interpolate) the source image from the ap to the resolution required by the printer.

That's what these threads have been about!

No one is denying that interpolation takes place.

Re Photoshop etc.

Why do you think that a mundane operation is surreal?

Because it (assigning some imaginary size to an image in memory) is a pretty pointless thing to do.

Most photo editing software has the ability to resample to new pixel dimensions,

True.

and also to change the image length dimensions without resampling.

If it does that it is merely replacing one fiction with another!

The length information is usually included in the file header - including the file header for the Windows BMP format.

It's actually some fictitious resolution that is included but it's true you could calculate some equally fictitious dimension from it.

It doesn't have to be there, but if it is, it can be used.

Well, true it could be used but I very much doubt that you'll find any application that does. That's because it's basically BS.

From my 350D jpg's are saved with a resolution of 96 but 'developed' RAW files are saved with a resolution of 180 - both numbers are spurious and are probably there because the programmers thought they ought to fill the slots with something but had no idea what so they just looked in some other file and copied that. (I'm quite serious about that, BTW).

An example: you can take a 5102 pixel by 7654 pixel, 24 mm x 36 mm file (ie 5400 ppi) and change the header info so that it is read as a 17.7 inch by 26.6 inch, 288 ppi file (still 5102 x 7654 pixels).

OK, so you have now manually entered some figures that are consistent with the image. That is: if you printed your image on a piece of paper 17.7 x 26.6 without any resampling it would print at a resolution 10 187.74 source PPI.

This should lead to the pixels being perfectly aligned source:dest at the left but gradually drifting in and out of alignment 6 times across the print.

Now, in Photoshop (or whatever) you can select certain ppi settings that produce the optimum output on paper. As I have mentioned a couple of times in this debate, for the Epson 2100 (UK) 2200 (USA), using the Epson printer driver, the magic ppi settings are 288, 360 and 720. 288 ppi produces the most accurate rendition on paper (ie the pixels printed on the paper most closely represent the pixels in the file). 720 ppi produces the highest resolution, however.

Or, to put it as a general case for all printers:

If the size of the image (in pixels) to be printed is a submultiple of the size of the image that the printer places on the paper you will obtain the most accurate representation.

However, I'm not quite sure that you're doing what you think you're doing.

To get that pixel perfect alignment you would need to know the precise size of the image on paper (this is obviously likely to be different from the size of the paper).

You'd then need to resize the image to the submultiple of the printer resolution of your choice.

This would, unless you were very lucky lead to an 'unaligned' resample.

Then, when you printed, there would be an 'aligned' resampling.

The practical application of this is that in this case it is better to produce the print-ready file at the correct length dimension in Photoshop at 288, 360 or 720 ppi, then sharpen (viewing the image at real-life size), then open the printing system (irrespective of which piece of software you are looking at).

Well, I could believe that but from what you describe above it doesn't seem to me that that's what you're doing.

Of course, I could will have got the wrong end of the stick somewhere.

What is evident, however, is that if you want to avoid doing any 'unaligned' resample you would need to do one of three things:

1) Be extremely lucky (i.e. the size of the image you wish to print just happens to be a submultiple of the size of the image on paper (measured in pixels)).
2) Crop your image so that (1) applies.
3) Modify the printed size so that (1) applies.

Again, if you are happy with the first resampling to be unaligned that's fine but the steps you are undertaking don't appear to be generating an image that will yield to the second resampling being aligned.

 

[Alpha]

I'm sorry but what's the relevance of this, even as background, to modern printers using software processors?

 

[Bifurcator]

Oh, I think they are.

And again, of course, you think wrong.

That's what these threads have been about!

Then you've wasted your time because you can't communicate.

No one is denying that interpolation takes place.

You did. Till you were called on it... then you changed it around.

 

[Moglex]

And again, of course, you think wrong.
Then you've wasted your time because you can't communicate.

You are again arguing by diktat and ad hominem.

You did. Till you were called on it... then you changed it around.

How on earth could anyone possibly say that interpolation didn't happen?

I'm sure you'll be able* to point to a post where I said something so absurd.

Unless, of course, you are just making it up?



* Actually, I'm damn sure you won't.

 

[Helen B]

Moglex,

It's fairly obvious that your understanding of this issue is a lot poorer than you think it is. That makes it very difficult, time consuming and pointless to have a discussion with you.

Sorry.
Helen

 

[Moglex]

Moglex,

It's fairly obvious that your understanding of this issue is a lot poorer than you think it is. That makes it very difficult, time consuming and pointless to have a discussion with you.

Sorry.
Helen

Helen

I'm sure you think you know exactly what you're doing but digging around in a few Microsoft manuals and regurgitating stuff that you don't understand doesn't really help make your case.

Along with Bifurcator and garbz you have singularly failed to provide one shred of evidence that the photo editing program can devolve image interpolation to the driver or printer.

You also seem to be somewhat confused about what actually happens when you invoke interpolation as you demonstrated with your example that would have caused the source image to drift into and out of alignment iwth the desination. This is possibly due to an understandable llack of understanding of what happens within the sort of code that does this work.

No need to be sorry.

All the best

Moglex.