Resolution concern?

[Bifurcator]

Moglex Wrote:
I'm not sure I uderstand how you have done the print from file or print from browser tests.

In Mac OS X, select the file icon, select Print from the Finder menu, examine the output.
In Safari (browser), right-click and select: Open Image In New Window or just drag & Drop it from the desktop etc., select Print from the File menu, examine output.
Each of these call up a customized version of Canon's printer driver. I think it's like embedding but I haven't looked into it.



If you use the standard 'print to file' with your printer selected then PS will print an image of what it woud send to the printer to the file so you would expect to see exactly the same result when you printed it.

But as Garbz pointed out, that isn't the case.



I must admit that if you get the same effect when printing from the browser that is extremely puzzling.

Not if you accept the facts as now established in this thread. That dithering is NOT preformed by Photoshop - but rather the driver and the printer as Helen B. was kind enough to explain.



How can you set a browser to effectively pixilate your source (i.e. get it to print at 122DPI)?

Because the printer driver and printer handle that. Not the browser, and not photoshop.



Well, I've learned a couple of things along the way although I'm still pretty certain that the printer/driver does not perform intra-pixel dithering.




But now even I agree we seem to be getting a little topically impertinent. All I was interested in establishing was that "dithering happens", what it basically looks like, and that dithering is most of the reason why ~100 PPI prints can look OK-ish.

 

[Moglex]

Actually it proves the point perfectly. It's not photoshop's job to custom taylor the output to the printer. It has no idea what the printer will do. In fact a layer of abstraction present in windows means that it doesn't even know what the printer is. It prints to the print spooler with the appropriate address and the windows print spooler / driver takes care of the rest. This abstraction also allows very little backwards communication. The only thing photoshop knows about the printer is that the driver has selected a certain paper size, but this could be changed in the next window too to totally fudge up the printing. The examples prove that the printer Bifurcator is using clearly resamples the data, where as Distiller (the PDF printer) does not.

I'm afraid you are wrong on a very important technical issue and it's one upon which the whole question pivots.

In WIndows (and, by extension in any other GUI), the programmer can find out two very salient facts about the paper on which s/he is printing.

1) It's size
2) The vertical and horizontal resolution of the prionter concerned.

From (2) it has all it needs to know about the printer in order to handle intra-pixel dithering (or interpolation to put it another way).

If you are outputting to a file for PDF then PSP, etc will NOT do intra pixel dithering because it has no idea where the output will be displayed.

The whole point of PDF is that it is completely device independant.

If the program sent its output taylored to Bifucator's printer, imagine what would happen when the PDF file was displayed on screen, or on a printer with a totally different resolution.

As I said, your test proves absolutely nothing because you have told PS to output in a device independant format so that is what it has done.

 

[Moglex]

In Mac OS X, select the file icon, select Print from the Finder menu, examine the output.
In Safari (browser), right-click and select: Open Image In New Window or just drag & Drop it from the desktop etc., select Print from the File menu, examine output.
Each of these call up a customized version of Canon's printer driver. I think it's like embedding but I haven't looked into it.

OK, how do you know that it calls up a version of the printer driver?

I'm afraid that what you seem to be doing is starting from the premis that the printer or driver does the dithering, then doing or hearing of a number of tests and in each case stating: That proves that the printer/driver is doing the dithering.

And no test so far performed by you or anyone else has shown that,

But as Garbz pointed out, that isn't the case.

But, as I demonstrated, Garbz was technically and logically incorrect.

I must admit that if you get the same effect when printing from the browser that is extremely puzzling.

Not if you accept the facts as now established in this thread. That dithering is NOT preformed by Photoshop - but rather the driver and the printer as Helen B. was kind enough to explain.

No, those 'facts' have not been established.

What Garbz wrote was incorrect and with Helen B you are doing the same thing again: taking whatever result comes up and saying it proves your point.

Helen B's post does not in anyway address the issue of where dithering is performed.

How can you set a browser to effectively pixilate your source (i.e. get it to print at 122DPI)?

Because the printer driver and printer handle that. Not the browser, and not photoshop.

Now you're answering a question with a reassertion of unproven facts.

I asked how you managed to get a browser to send somthing that has a raw resolution of 122 PPI to the printer, not how it was handled after you'd sent it.

Well, I've learned a couple of things along the way although I'm still pretty certain that the printer/driver does not perform intra-pixel dithering.

Yes, I know you're confused.

I am reasonably certain that the printer/driver doesn't do the dithering because, as I've already explained, they never see the data at the resolution of, (in the case of your test), 122PPI. They only see a stream of data from the program at the resolution of the printer.

It is the advertised jjob of the printer to put dots of the colour the programmer specifies at the loctions the programmer specifies.

It would be an intolerable state of affairs if a programmer carefully constructs a bitmap to print a certain array of colours and the printer off it's own bat decides to print something entirely different.

And yet that is what you seem to have convinced yourself is happening.

But now even I agree we seem to be getting a little topically impertinent. All I was interested in establishing was that "dithering happens", what it basically looks like, and that dithering is most of the reason why ~100 PPI prints can look OK-ish.

But you could have said that right from the start and I would have agreed (whilst mentioning that my test didn't actually work that way).

Instead you undertook a great many time consuming tests to try to prove where the dithering is done.

All of these were doomed to failure because of the 'black box' nature of the printing process. (Which, incidentally, is why even as a programmer/software architect with decades experience of computer printers I cannot be 100% certain of what is going on).

 

[Bifurcator]

OK, how do you know that it calls up a version of the printer driver?

Because it says so on the panel?


But, as I demonstrated, Garbz was technically and logically incorrect.

I think just the opposite.


You undertook a great many time consuming tests to try to prove where the dithering is done.

No, the tests were done to show that dithering occurs - period. And really, it only took a few minutes.

 

[Helen B]

Helen B's post does not in anyway address the issue of where dithering is performed.

Please explain my observations based on your premise that the printer software does not do the dithering.

Thanks,
Helen

 

[Moglex]

OK, how do you know that it calls up a version of the printer driver?

Because it says so on the panel?

Right, so it calls up the driver in order to interrogate it about the printer's capabilities and attributes (specifically its resolution and paper size).

That's expected and it's all you can infer.

It in no way tells you anything about where the dithering is being done.

But, as I demonstrated, Garbz was technically and logically incorrect.

I think just the opposite.

I have provided a precise logical explanation of exactly why Garbz conclusion was wrong.

By all means show an error in the logic but just saying the explanation is wrong with no backup is pointless.

You undertook a great many time consuming tests to try to prove where the dithering is done.

No, the tests were done to show that dithering occurs - period.

Well, we knew that dithering was done. there was really no need to prove it. Computer graphics would never have got off the ground without dithering. You keep now saying that its all about whether dithering is done or not and all else is irrelevant whilst at the same time becoming ever more insistant that it is done by the driver/printer.

And really, it only took a few minutes.

Nonetheless, time, and it was consumed.

 

[Moglex]

Please explain my observations based on your premise that the printer software does not do the dithering.

I think it would be rather more to the point if you were to explain why you think your observations imply it does.

Bifurcator, Garbz and youself all seem to believe you can see inside the 'black box' of the printing system and draw the conclusion you want from data that simply does not support such conclusions.

You all seem to be absolutely convinced that the processing is done in the driver/printer based on hunches and intuition.

I am not quite as certain as you three despite a working life involved with computers including many types of printer and an intimate knowledge of the programming interface used by modern GUI's which, as I have explained, insists that you to send data to the printer driver at the resolution of the printer thus making it virtually impossible for the driver to know what the originating resolution was and hence making it all but impossible for it to perform intra-pixel dithering/interpolation.

This detailed and logical objection has been repeatedly ignored in favour of 'experiments' that are asserted to show what is happening inside the black box but without any satisfactory explanation of how they are showing such a thing.

 

[Garbz]

Since when does photoshop know about the resolution?
I have never seen anything change when I go to the printer driver and change my resolution. Photoshop doesn't even know if I am printing in black and white or not.

While you may be right I add this for consideration. A program which prides itself on the ability to control even the finest detail, the colour output, the proofing settings, and giving you a selection of 5 interpolation modes internally when you resize an image, all of a sudden miraculously obfuscates an element from the user which provides key control over how the final image is displayed and manipulated in the final steps?

I must say I am take your previous comment with a metric tonne of salt. If photoshop interpolated the image I am certain it would give you the choice of how!

 

[Moglex]

Since when does photoshop know about the resolution?

This is where it's difficult talking to non technical people.

The very fact that you could even ask such a question demonstrates why I can't get accross to you the fact that the interface between programs and the windows GUI (which then feeds to the monitor/printer driver which then feeds to the monitor/printer), simply does not provide a method for a program to say to the output device: "This is the resolution of what I'm giving you, please print it at some other resolution".

Every single time that a program wishes to output a picture (bitmap), it has to interogate the GUI (which will, in tunr, interrogate the driver for the device) to find out what the resolution is.

It then has to manipulate the bitmap so that it displays at the appropriate size on the output device.

If you're displaying a normal photo file on a monitor it is pretty certain it will need to be shrunk. If you are displaying it on a printer it is pretty certain it will need to be expanded.

This something that is fundamental to all graphics programs dealing with bitmaps.

I have never seen anything change when I go to the printer driver and change my resolution.

Of course you haven't! Photoshop optimises its display for whatever it's displaying on.

What on earth would you expect to happen?

The picture on the screen to suddenly become more or less detailed?

Photoshop doesn't even know if I am printing in black and white or not.

Oh, I can promise you it does.

The colour depth of the output device is extremely important information without which it's impossible to even begin to print. It needs that information to set up the internal data structures it needs to communicate with the GUI.

While you may be right I add this for consideration. A program which prides itself on the ability to control even the finest detail, the colour output, the proofing settings, and giving you a selection of 5 interpolation modes internally when you resize an image, all of a sudden miraculously obfuscates an element from the user which provides key control over how the final image is displayed and manipulated in the final steps?

Perhaps you'd like to suggest a selection of parameters it would offer you for your consideration and specification?

If the program writers have (doubtless after years of research and experimentation) determined that there is an optimum method to perform a task then that's how they'll do it.

If you ask it to rotate an image it will allow you to select a degree, direction and possibly a centre of rotation but it won't give you a choice of algorithms to use (except possible a higher speed one for intial proofing) because one algorithm has already beed determined to provide the best quality in all circumstances.

If photoshop interpolated the image I am certain it would give you the choice of how!

As I said, if you can suggest which parameters you would like to be able to change or which algorithms you would like to be able to choose from, and under which circumstances you would pick each, I'd be inclined to see your point.

 

[Helen B]

I am not quite as certain as you three despite a working life involved with computers including many types of printer and an intimate knowledge of the programming interface used by modern GUI's which, as I have explained, insists that you to send data to the printer driver at the resolution of the printer thus making it virtually impossible for the driver to know what the originating resolution was and hence making it all but impossible for it to perform intra-pixel dithering/interpolation.

Before I go any further I just want to check whether there are some crossed wires. Where does the thing that you are calling the 'printer driver' reside on the type of inkjet printers that you are talking about? I'm talking about software within the OS of the computer, not the printer. When I read the above paragraph, I get the impression that you have divided everything at the printer cable, so to speak.

I'm also thrown by your reference to the GUI. Don't you mean the OS?

Best,
Helen

 

[manaheim]

Oh god... this again.

I've said this a few times but the other folks either still disagree with me or haven't read my post.

SOMETIMES resolution matters.

My client demands the most resolution they can possibly get, and no less than 10MP at this point. Why? Well, to be frank, it almost doesn't matter. They're paying me, so if they'd like their images shipped with a pound of bacon, I'd be on my way to the grocery store as we speak.

I'm being glib, but there are cases where resolution is required for certain processes. My client tends to crop a lot because they are not always certain what they want from the scene you are shooting... sometimes down to 1/4 of the shot. I daresay that happens less with my images than their other vendors because I have learned what they are looking for, but it still occurs.

My client also prints extremely large prints sometimes, and while technically it shouldn't matter if pixels become giant dots, their clients pay them a ton of money and are ridiculously picky, so the fewer the big dots the better.

Does this mean that you should rush out and buy the largest resolution cam you can get? No. Does it mean you should dwell overly heavily on the fact that a D40 is 6MP an a D60 is 10MP? No. It just means that you can't take any extreme statement too seriously and need to consider all the options and what you plan to do with the device.

Both of these extremes:

• IT DOESNT MATTER EVER... A 3MP CAMERA WILL BE FINE!!
• ...and YOU NEED THE BIGGEST RESOLUTION YOU CAN GET AND ALL SHORT OF THAT WILL SUCK!!

Are equally flawed statements.

Again: Yes it matters, sometimes. More resolution does open up some extra options to you, the question is really whether or not you need those options.

 

[Helen B]

The practical importance of the 'who does what' issue for me is the optimisation of the process. In some ways it doesn't matter exactly which piece of software does what, but it is important to me to know the 'best' way of getting from the resolution of the original to the dots of ink on the paper.

Best,
Helen

 

[Moglex]

Before I go any further I just want to check whether there are some crossed wires. Where does the thing that you are calling the 'printer driver' reside on the type of inkjet printers that you are talking about? I'm talking about software within the OS of the computer, not the printer. When I read the above paragraph, I get the impression that you have divided everything at the printer cable, so to speak.

No, there are four specific logical 'blocks' of program code to consider.

1) The application - e.g. Paintshop Pro or Photoshop
2) The Graphic User Interface (GUI) - the part of the operating system that is responsible for accepting calls from the applications, doing some processing and passing them to the appropriate driver.
3) The printer driver - a piece of software that takes information and converts it from the format specified by the GUI to the format required by the printer.
4) The printer - which will contain its own software as required to render the user's data onto the paper.


Te interface between (1) and (2) for the printing of a bitmap requires the programmer to supply the GUI with a block of memory containing the specification for every pixel at the resolution of the printer selected.

It is for this reason that I maintain that intra-pixel dithering/interpolation is carried out by the application. (as opposed to inter-pixel dithering - creating the colour gamut from 3-9 inks - which is carried out by the printer's internal software).

I'm also thrown by your reference to the GUI. Don't you mean the OS?

Best,
Helen

The OS is made up of several major parts.

Windows, for example, contains, amongst other things:

The GUI
The CUI (Character User Interface)
The memory manager
The file manager
The scheduler

And a raft of other stuff.

Linux. Unix and the OSX will contain similar chunks of code.

 

[Moglex]

The practical importance of the 'who does what' issue for me is the optimisation of the process. In some ways it doesn't matter exactly which piece of software does what, but it is important to me to know the 'best' way of getting from the resolution of the original to the dots of ink on the paper.

Well, the people who originally designed the architecture of the entire system: computer - application - GUI - driver - printer worked out at the outset which part should have responsibility for which function.

The application has the responsibility for specifying the colour of every dot to be printed.

This is logical because the application 'knows' what it's trying to do and can, if ncessary interogate the user or allow her to set parameters to give it clues.

It can then determine the precise capabilities of the printer and do its level best to ensure it specifies optimum specification for each pixel the printer is to print. It has no responsibility for telling the printer how to print that pixel because it has no understanding of how the ink/toner/whatever needs to be applied to get a particular effect.

The printer has the responsibility for determining the optimum way of rendering the pixel on the paper/tranparancy/whatever. It has no responsibility for deciding what colour the pixels are because it knows nothing about the application that requested them nor any clues the user may have given that application.

The GUI and Driver are (from the POV of bitmaps) merely there to facilitate communication from the application to the printer. (The driver and part of the OS/GUI also handles communication between the user and the printer over matters such as the paper type/size selected.)


Hope that all helps.

 

[TamiyaGuy]

@TamiyaGuy
I guess I know what you mean but pixel resolution does indeed matter more than you seem to be implying.

Heh, sorry. I think I went off on a bit of a rant again... . I do agree that megapixels do matter in certain cases (for example large prints or cropping), but there are plenty of other things in a camera that have just as large an effect on print quality as megapixels.

And one thing's for sure in my mind: The number of pixels in a camera has a smaller meaning than the camera manufaturers lead you to believe.

Great thread, this. I've learnt many things from Bifuricator and Garbz.