Resolution concern?

[Moglex]

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.

Hmmm, it is pretty important.

A lot of people say that it's not the be all and end all because the lens quality is important as well - as is sensor noise and other sensor qualities.

This is quite true.

However, since the lens resolution and film/sensor resolution combine to give you and actual resolution the higher the sensor resolution the better (all other things being equal).

If you double the linear sensor resolution by moving from 6MP to 24MP you will not by any means double the achieved linear resolution but you will get a significant increase.

The better the lens resolution the greater the improvement from increasing the sensor resolution.

 

[Garbz]

The so called non-techie person here happens to be a qualified engineer with several years of software development for micro architecture under his belt, so feel free to stop being a righteous ass and drop off your high horse before your fall and hurt yourself.

What you're saying still makes no practical sense. How can printing not be device independent. I can still only see that the driver would make the final choice, or the print spooler itself (though it shouldn't). Photoshop should be printer independent. If it weren't and as you suggest it does know everything the driver has set, then why is it incapable of bringing up a warning message when there's a colour mismatch, instead of writing a little note under the colour area.

As for the optimal solution, there is one. Don't do any processing on the image. For a program used mainly in the professional area it should be assumed that the DPI of an image is sorted out before the print button is hit, so why re-sample, why no feedback that the image is being altered, and again why no choice? I mean when I manually set the image to 122 dpi it doesn't go out and then best guess a setting for me either.

But do feel free to come back with an actual example, test print, developer notes from programs, source code, external reference, or something else to back up your arguement. I mean something that actually proves something.

 

[Moglex]

The so called non-techie person here happens to be a qualified engineer with several years of software development for micro architecture under his belt, so feel free to stop being a righteous ass and drop off your high horse before your fall and hurt yourself.

Please don't get yourself wound up.

There really isn't any need for rudeness or name calling.

You said: "Since when does photoshop know about the resolution?"

and you also said: "Photoshop doesn't even know if I am printing in black and white or not."

The first is a question that indicates that you have no idea of how the GUI API works as far as printing is concerned. Absolutely none at all otherwise you would never have asked such a question.

The second statement is simply 100% wrong as I explained in my reply.

My comment about not being able to get information accross to you was nothing to do with being on a high horse.

For some reason you have convinced yourself that the black box works one way and even though I have explained in considerable detail why the architecture, particularly concerning the API, cannot allow what you assert is the case you just ignore that explanation and continue to assert that you're right.

I'm quite prepared to conceed that I'm wrong IF anyone comes up with a concrete fact or experiment that proves the case.

So far no one has.

Your attempt to do so by outputting to a device independant format and then saying "Look, it hasn't dithered" didn't even come close and also, I'm afraid to say, further indicated that you don't really understand the dataflow in the system or the concept of device independance.

What you're saying still makes no practical sense. How can printing not be device independent.

Again, I've explained this more than once in some detail.

It isn't device independant because that's how the architecture has been designed from day 1.

It would be absurd to make it completely device independant since this would absolutely prevent programs making any optimisations depending on the printer and how it was set up.

Just to try and get it through once again.

The way Windows/Linus/OSX work at the programming level for the printing of bitmaps is that the programmer must supply a bitmap at the resolution of the printer and with each pixel of the correct colour depth for the printer.

That is a simple fact.

If you don't believe me, find some other software engineer who is familiar with GUI's and ask them.

Once you have ascertained the veracity of that fact, try and explain how the printer or its driver can possibly do any intra-pixel dithering/interpolation when by the very nature of the architecture there is nothing for it to dither/interpolate.

I can still only see that the driver would make the final choice,

I've very clealy explained why it can't.

More than once.

or the print spooler itself (though it shouldn't).

The print spooler?

THE PRINT SPOOLER?

The print spooler is responsible for storing the print data on the disk until the printer is ready for it.

Why on EARTH would the print spooler have the vaguest interest in dithering?

Photoshop should be printer independent.

Well, in a sense it is printer independant in as much as it doesn't care or need to know the make or model of the printer nor anything about how it does it's job or the command sequences needed to operate it.

It is not printer independant (nor should it be) when it comes to knowing the resolution at which the printer is working or the colour depth or whether it has a duplexor or whether it has a collator attached.

If it weren't and as you suggest it does know everything the driver has set, then why is it incapable of bringing up a warning message when there's a colour mismatch, instead of writing a little note under the colour area.

I don't use PS so I have no idea what you mean.

As for the optimal solution, there is one. Don't do any processing on the image. For a program used mainly in the professional area it should be assumed that the DPI of an image is sorted out before the print button is hit

I'm sorry, I really don't want to be rude, but that paragraph just demonstrates that you don't have a clue.

This line "it should be assumed that the DPI of an image is sorted out before the print button is hit" is just complete and utter nonsense.

Whilst the image is in PSP/PS it is just an abstract entity with a size measured in pixels in two dimensions.

Until the program decides where it is rendering it the concept of DPI is completely meaningless.

Once you select a printer and the program has interrogated the GUI/driver, you gain the concept of PPI at the printer which then allows you to calculate a rather artificial number namely the number of pixels that are available from the source image to cover an inch of paper (which, BTW, on most current printers is not symmetric in the x and y axis).

 

[Bifurcator]

Please don't get yourself wound up.

There really isn't any need for rudeness or name calling.

I think this is the point where rudeness and name calling serve their purposes. I know I'm pretty frustrated reading what you write. Garbs says he's an engineer, I've had my CS degree for 25 years. Not much of what you're saying makes sense. And you seem to just be skewing other people's words in order to keep an argument going for no other reason than to entertain yourself. Garbz seems to think the same thing though I can't speak for him.

Yup, when you start trying to make an argument over the words "time consuming" by altering it's common usage and meaning it's definitely time for name calling and rudeness.

 

[Bifurcator]

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.

Yup, I tend to agree with that. And yeah, Garbz is pretty easy to learn from. Some people just have a natural way of expressing their intelligence that's easily digestible. I like smart educated people who share their time. It makes places like this actually worth participating in! Helen B is another. She nailed the explanation (as usual) in an easily understandable way - which in my experience is a sign of true intelligence and understanding.

 

[Mav]

I would like to hear reg's expert opinion on all of this. That will settle everything.

 

[BoblyBill]

I would like to hear reg's expert opinion on all of this. That will settle everything.

LOL... That is the funniest thing I have heard all day!

 

[Moglex]

I think this is the point where rudeness and name calling serve their purposes. I know I'm pretty frustrated reading what you write. Garbs says he's an engineer, I've had my CS degree for 25 years. Not much of what you're saying makes sense. And you seem to just be skewing other people's words in order to keep an argument going for no other reason than to entertain yourself. Garbz seems to think the same thing though I can't speak for him.

You see here's the problem right here.

You both think that because you have CS experience that means that you can have a hunch and that will override the facts of the nature of the GUI API and any logic applied to those facts.

You say you have a hunch. You then do some tests. You claim the tests support your hunch. When I explain exactly why they don't you competely ignore the explanation and pick up on other posts that don't support your hunch and make out that they do.

If you still believe that the printer/driver does the interpolation/dithering rather than PSP/PS either:

Explain how the PSP programmers get the unexpanded pixels accross the API to the driver.

or

Explain how the driver/printer can use the expanded pixels to perform intra-pixel interpolation without any way of knowing what the original resolution was.

Yup, when you start trying to make an argument over the words "time consuming" by altering it's common usage and meaning it's definitely time for name calling and rudeness.

Come, come, now.

You were the one who started messing around with the definition of 'time consuming'.

I made a completely uncontentious statement that you had carried out a series of time consuming tests and you tried to turn it into an argument.

I used 'time consuming' in the sense that you were prepared to post an image, manipulate the image, scan it, post the scan, photograph it and post that, overlay it with several different masks each time re-photographing it and posting it again.

To any normal person that's a perfectly reasonable use of 'time consuming'.

 

[Moglex]

I would like to hear reg's expert opinion on all of this. That will settle everything.

Surely there must be other software engineers here who understand the graphical user interfaces used by windows/linux/OSX and can help to explain to bufurcator and garbz why the architecture involved prevents things from working in the way their hunches suggest?

 

[Helen B]

Moglex,

This is getting rather multi-faceted, so I'll take it in small bits.

"Explain how the driver/printer can use the expanded pixels to perform intra-pixel interpolation without any way of knowing what the original resolution was."

Why do you say that there is no way for the application (eg Photoshop) to send image dimensions to the printer driver. The Windows bitmap format has a 'SIZE' property that can be read by the driver, in units of 0.01 mm doesn't it? (Source: MSDN Library, Windows GDI, Bitmap Reference - SIZE property, SetBitmapDimensionEx function, GetBitmapDimensionEx function)

Best,
Helen

 

[Moglex]

Moglex,

This is getting rather multi-faceted, so I'll take it in small bits.

"Explain how the driver/printer can use the expanded pixels to perform intra-pixel interpolation without any way of knowing what the original resolution was."

Why do you say that there is no way for the application (eg Photoshop) to send image dimensions to the printer driver. The Windows bitmap format has a 'SIZE' property that can be read by the driver, in units of 0.01 mm doesn't it? (Source: MSDN Library, Windows GDI, Bitmap Reference - SIZE property, SetBitmapDimensionEx function, GetBitmapDimensionEx function)

Best,
Helen

Yes, the printer could potentially read the size of the bitmap but what would you expect it to do with this? As I said earlier, the bitmap in the computer is dimensionless - it is just n x m pixels. If you send a 100 x 100 pixel image to the printer and tell it that the size is 10cm x 10cm it won't take any notice. In the section you quoted it very clearly states: "however, they are not used by the system". They are for internal use by the application only.

I'm afraid this will get quite boring but I'll explain exactly what happens when you print an image.

To make the arithmetic easy, let's assume that you have an image that is 3000 x 2000 pixels in size and you wish to print that on a sheet of paper 15" x 10" on a printer with a resolution of 1000 dpi.

This is what, as a programmer, you need to do:

1) Get the size of the paper in inches*
2) Get the printer resolution in inches
3) Determine the number of pixels required to fill the sheet of paper in each direction = 15,000 * 10,000
4) Determine the ratio between the number of pixels available and the number of pixels required = 5
5) Create a new area of memory 15000 x 10000 pixels in size and expand the source image into this area. You can do this simplistically by simply making each source pixel into a block of pixels 5x5 or by the use of more or less sophisticated interpolation algorithms.
6) Sent the expanded are of memory to the printer.

* Windows actually allows you to work in various units and for things such as line and shape drawing it will automatically scale the coordinates you give it into pixels before rendering. Indeed, when you perform the 'BitBlt' function (same document you referenced) to actually do the deed you can specify the position you wish the image placed in a variety of dimensions, but you will, if you look it up, note, that the size must be specified in pixels

However, a bitmap, which is what you must provide to send to the printer, is by its very nature, a set of pixels. If you check the document you just referenced you will see that whereas a function such as 'LineTo' which draws a line, allows you to specify the x and y coordinates (the interpretation of which is dependant upon which measuring system you have set the GUI to use), the definition of 'CreateBitmap' specifically states that the dimensions are in pixels.

This is why the program must expand the source image, either crudely, which will result in a pixilated image, or with varying degrees of sophistication which result in the smoothed images that bifucator demonstrated.

Now, since the only way to get an image to print at the size you want is to expand it (or contract it) until it has the correct number of bits to print at that bit size at the resolution of the printer (if you try and send a bitmap that is too small you simply get a smaller image at the location you specified), there is no reasonable way that it can be the printer driver or, indeed, the printer, that is doing the interpolation since it, by the very definition of the GUI architechture, cannot have anything to interpolate.

If you want to double check this, select an image in PSP or whatever package you have that has a 'pixelation' effect. Pixelate your image and print it.

Did the driver/printer confound you attempts to print a pixelated image?


One last point.

Printers that are capable of printing directly from a camera must, of course, contain their own version of interpolating software otherwise they would always print pixelated images. However, by the nature of the GUI architecture they are unable to use this on images sent from the computer.


I hope that sorts this out once and for all. I'm not stating dogmatically that I'm correct, merely that I have provided a more than adequate collection of facts and logic to support the contention that the architecture of graphical OS's cannot support the vague but tenaciously held hunches of bifucator and garbz that the printer or its driver interpolates source images.

 

[Helen B]

Moglex,

You are describing one way of doing things. It is not the only way that printing can be carried out via the GDI. The application does not just ask for a bitmap to be printed. It can, and does, pass other information.

Let's go back to the results of the experiment I quoted. I'll be more specific, and use the Epson 2200 because they are the printers that I have had the widest experience with (ie most printers, most drivers and RIPs).

Observation.
If I set the printer resolution to 1440 'dpi' or 2880 'dpi' (in the printer driver, not in Photoshop) and print a 288 ppi file it is printed with the most pixel-pixel accuracy of all resolutions. At no other file resolution does that happen. Not 360, 720, 1440 or 2880.

Deduction
Any resampling that has occurred to the 288 ppi file is 'nearest pixel'. No other method would produce the same file pixel - print pixel correspondence.

Neither the 1440 ppi file, printed at 1440 'dpi' nor the 2800 ppi file printed at 2880 'dpi' show pixel-pixel correspondence. Therefore they have been resampled somewhere, and apparently not by 'nearest pixel'. The application should not have resampled them because they are already at the nominal resolution of the printer.

The true resolution of the printer need not be 1440 ppi or 2880 ppi. It could be 288 ppi. That would mean that sending a 720 ppi file would not give a higher print resolution than a 288 ppi file. This is not the case. Though the pixel-pixel correspondence is not as exact, the resolution, in terms of discernible lines, is higher for a 720 ppi file than from a 288 ppi file.

Best,
Helen

PS The actual commands of what dots of ink to place where on the paper (not just the pixel values) can be controlled directly by the software in the computer, not the printer. The printer itself can be entirely under the control of the computer software. The conversion from pixel RGB values to CcMmYKk (for example) dots can be done by the software, such as a RIP, in the computer.

PPS You maintain that the application cannot send anything other than a bitmap of the pixel values to the printer driver. What colour model do you think is used for that bitmap?

 

[Moglex]

You are describing one way of doing things. It is not the only way that printing can be carried out via the GDI. The application does not just ask for a bitmap to be printed. It can, and does, pass other information.

Would you care to tell us what function calls it uses and what data structures?

What you say above rather contradicts what I know but there are so many alleyways and rivulets in the API that it's possible I've missed something (which is why I am not dogmatic about being correct).

However, as you showed in you last post, you have to be very careful how you read the documentation otherwise you may miss something (such as the information that the size of a bitmap is only a memo field and is not used by the system).

Let's go back to the results of the experiment I quoted. I'll be more specific, and use the Epson 2200 because they are the printers that I have had the widest experience with (ie most printers, most drivers and RIPs if you are going to use OS specific terms, could you define them, please).

Observation.
If I set the printer resolution to 1440 'dpi' or 2880 'dpi' (in the printer driver, not in Photoshop) and print a 288 ppi file it is printed with the most pixel-pixel accuracy of all resolutions. At no other file resolution does that happen. Not 360, 720, 1440 or 2880.

Deduction
Any resampling that has occurred to the 288 ppi file is 'nearest pixel'. No other method would produce the same file pixel - print pixel correspondence.

Neither the 1440 ppi file, printed at 1440 'dpi' nor the 2800 ppi file printed at 2880 'dpi' show pixel-pixel correspondence. Therefore they have been resampled somewhere, and apparently not by 'nearest pixel'. The application should not have resampled them because they are already at the nominal resolution of the printer.

The true resolution of the printer need not be 1440 ppi or 2880 ppi. It could be 288 ppi. That would mean that sending a 720 ppi file would not give a higher print resolution than a 288 ppi file. This is not the case. Though the pixel-pixel correspondence is not as exact, the resolution, in terms of discernible lines, is higher for a 720 ppi file than from a 288 ppi file.

Before I respond to that, can you tell me what you believe the purpose of setting a resolution in the driver is?

Also, just to be certain, by 'nearest pixel' I assume you mean 'the colour of the source pixel whose nominal centre is closest to the nominal centre of the destination pixel'.

And also what do you mean by 'pixel-pixel' accuracy. That could mean a lot of things and there's no point in getting wires crossed.

At the moment I haven't seen anything in your results that can be taken to show that the driver is doing the interpolation but I want to be sure I understand precisely what you are saying.

PS The actual commands of what dots of ink to place where on the paper (not just the pixel values) can be controlled directly by the software in the computer, not the printer. The printer itself can be entirely under the control of the computer software. The conversion from pixel RGB values to CcMmYKk (for example) dots can be done by the software, such as a RIP, in the computer.

Yes, this has never been in dispute.

 

[Helen B]

Some quick answers before the longer one (I have to go off to a shoot):

"if you are going to use OS specific terms, could you define them, please"

A RIP is a Raster Image Processor. It is not an OS specific term. They are widely used, and I'm a little surprised that you are unaware of their existence.

I have never made any assertion that Photoshop, for example, can do dithering.

The confusion about whether or not PC software did any dithering was because you kept referring to the 'printer' doing it, rather than the 'printer or printer driver'.

Before I go any further, could you reply to my comment "You maintain that the application cannot send anything other than a bitmap of the pixel values to the printer driver. What colour model do you think is used for that bitmap?" I may have added it while you were writing your reply to the rest of the thread.

Thanks,
Helen

 

[Moglex]

"if you are going to use OS specific terms, could you define them, please"

A RIP is a Raster Image Processor. It is not an OS specific term. They are widely used, and I'm a little surprised that you are unaware of their existence.

Obviously I'm aware of their existance they are a fundamental part of computer graphics. Just never seen the expression reduced to a TLA.

I have never made any assertion that Photoshop, for example, can do dithering.

We are really talking about interpolation here, not dithering.

And I never suggested you did.

I'm the one who asserts that PSP/PS perform interpolation because, until you provide the evidence to the contrary, I'm unaware of any way for the application to send data to the printer at anything other than its reported resolution.

The confusion about whether or not PC software did any dithering was because you kept referring to the 'printer' doing it, rather than the 'printer or printer driver'.

You are quite wrong.

If you look above post #73 where you joined this part of the argument you'll note that I talked about the printer/driver twice.

I continued to refer to it in that way until it got to the point where it seemed pointless to keep being so pedantic as it was abundantly clear that the discussion was about what happened on either side of the GUI and there was no more need to continually refer to the printer/driver as only a moron could have assumed that I was suddenly jumping from discussing a tighly knit pair of entities with an undefined functionality boundery to one part of that divide.

Before I go any further, could you reply to my comment "You maintain that the application cannot send anything other than a bitmap of the pixel values to the printer driver. What colour model do you think is used for that bitmap?" I may have added it while you were writing your reply to the rest of the thread. you did

LOL.

It may be a bit of a misnomer but a bitmap is not a map of single bits!

It started out that way when the term, generally used in computer science for a map of on/off indicators was the natural one to use for the black and white printing that was all that was being done by general purpose computers at the time.

Once the name had been coined it stuck and is now used for any colour map where the colour depth depends upon the device.

To answer your question, the bitmap contains the full colour image.