Resolution concern?

[Bifurcator]

Well, I don't think track records matter. That you and I are new here shouldn't matter in this discussion is what I mean.

So you're saying photoshop did the grunt work here? Could be. My test was only data to paper without examining what was doing what. Can we look at the print preview and see everything the app and the driver did to the data? I haven't tried that.

This brings up another question though. You said "...as they never see the larger pixels." which I guess means it doesn't receive the source data but rather an expanded version - expanded out to "the resolution of the printer". If that's true (and I'm not doubting it just wondering) then how come if I send a large document already expanded out to the printer's resolution it takes almost a full minute for the printer to receive the data whereas if I send a tiny document (which you're saying gets expanded before it's sent so should be about the same amount of data) it sends entirely and the printer beings in like 2 to 5 seconds?

Again, I dunno, I'm just asking questions. That a driver or printer's firmware doesn't dither, interpolate, or whatever just doesn't make sense to me - which is what is causing me to ask these questions. That would mean that either all printers are the same or that an app like photoshop would have to natively be aware of every printer's construction and spec. right?

I'm kind of ignorant about printer communications - I hope it's not showing too much I understand laser and postscript type systems very well but I never really investigated dot matrix or ink jets so I'm shooting in the dark here. I could go look it up I guess but it's more fun to approach this deductively - especially when the documents I'm likely to find will be based on manufacturer spec and disclosure.

 

[Moglex]

Well, I don't think track records matter. That you and I are new here shouldn't matter in this discussion is what I mean.

It's just that you do get the occasional idiot who simply makes things up to support their view. As I've only just turned up I could be one of those. Or perhaps you don't get that type here.

So you're saying photoshop did the grunt work here? Could be. My test was only data to paper without examining what was doing what. Can we look at the print preview and see everything the app and the driver did to the data? I haven't tried that.

It's the only explanation I can think of since only photoshop knows that it's a picture you're sending. The driver and printer have no way of knowing that the data isn't exactly what you want printed. (When I did my test I wrote a program to do it.)

This brings up another question though. You said "...as they never see the larger pixels." which I guess means it doesn't receive the source data but rather an expanded version - expanded out to "the resolution of the printer". If that's true (and I'm not doubting it just wondering) then how come if I send a large document already expanded out to the printer's resolution it takes almost a full minute for the printer to receive the data whereas if I send a tiny document (which you're saying gets expanded before it's sent so should be about the same amount of data) it sends entirely and the printer beings in like 2 to 5 seconds?

I assume you're talking about mainly text, here?

Text is different. The printer normally gets that as a specification of how the the text is to appear (font, size, etc), a position, and the text. If the document has small pictures or graphics these are each sent as a position and data so the whole page does not need to be rendered graphically.

Again, I dunno, I'm just asking questions. That a driver or printer's firmware doesn't dither, interpolate, or whatever just doesn't make sense to me - which is what is causing me to ask these questions. That would mean that either all printers are the same or that an app like photoshop would have to natively be aware of every printer's construction and spec. right?

No. This is where Windows (+Linux + OS 7) are very clever and very complicated. The provide a common interface to all printers. As a programmer you can interrogate Windows to see if the printer you are using has certain features (so you don't try and print double sided on a printer that can't do it, for example), but after that you treat them all the same.

This is one of the reasons why Windows was so successful. Before that if you wanted to sell a program you would need to spend a fortune getting access to all the different types of printer so that you could write drivers for them. With Windows the manufacturer provides a driver once and programmers communicate with that.

I'm kind of ignorant about printer communications - I hope it's not showing too much I understand laser and postscript type systems very well but I never really investigated dot matrix or ink jets so I'm shooting in the dark here. I could go look it up I guess but it's more fun to approach this deductively - especially when the documents I'm likely to find will be based on manufacturer spec and disclosure.

It is more fun working it out by deduction, isn't it?

If you could borrow a book on basic Windows programming that includes printing you might get an idea of what goes on. Be warned, it's quite gruesome.

 

[Bifurcator]

It's just that you do get the occasional idiot who simply makes things up to support their view. As I've only just turned up I could be one of those. Or perhaps you don't get that type here.

Ah, the difference between those who need to be right, those who know, and those trying to learn. Hehehe.. yeah that happens. I haven't seen it here yet - but I'm new. And there are some people like Helen B., Garbz, Usayit, and others who really know what they're talking about and you can just tell from their tone and the way they offer the explanation that what you're reading is right on with only the expected exceptions - they'll keep us honest.

It's the only explanation I can think of since only photoshop knows that it's a picture you're sending. The driver and printer have no way of knowing that the data isn't exactly what you want printed. (When I did my test I wrote a program to do it.)

You mean printers no longer have a text mode, a drawing mode, and a bitmap mode?

I assume you're talking about mainly text, here?

Text is different. The printer normally gets that as a specification of how the the text is to appear (font, size, etc), a position, and the text. If the document has small pictures or graphics these are each sent as a position and data so the whole page does not need to be rendered graphically.

No, I'm still talking about images (bitmaps). So the questions still remans I guess. [This brings up another question though. You said "...as they never see the larger pixels." which I guess means it doesn't receive the source data but rather an expanded version - expanded out to "the resolution of the printer". If that's true (and I'm not doubting it just wondering) then how come if I send a large document already expanded out to the printer's resolution it takes almost a full minute for the printer to receive the data whereas if I send a tiny document (which you're saying gets expanded before it's sent so should be about the same amount of data) it sends entirely and the printer beings in like 2 to 5 seconds?]

No. This is where Windows (+Linux + OS 7) are very clever and very complicated. The provide a common interface to all printers. As a programmer you can interrogate Windows to see if the printer you are using has certain features (so you don't try and print double sided on a printer that can't do it, for example), but after that you treat them all the same.

This is one of the reasons why Windows was so successful. Before that if you wanted to sell a program you would need to spend a fortune getting access to all the different types of printer so that you could write drivers for them. With Windows the manufacturer provides a driver once and programmers communicate with that.

So if you treat them all the same application side, then the driver or printer itself must change the data by dithering, or whatever. I guess the app sends the dimensions and the bitmap data (and probably a few other things depending) and the driver or printer firmware formats and modifies the data to meet the app (user) requested specifications and conform to the printer's physical specs, like number of colors, number of jets, etc. This seems like common sense to me as when I send it a purple pixel it has to decide how much and where to spray the combination of magenta, yellow, cyan, and etc. that make up that pixel's tone of purple.

So it's doing something to the data already which I guess you already agreed earlier on but limited it to inner pixel operations. That my previous data (examples above) seems to show that it is also considering neighboring pixel data is our only topic of consideration at this point - at least for me.

I think one very clear and at least semi-conclusive test would be to remove every other pixel in a checkerboard pattern and see what happens to the white space.

It is more fun working it out by deduction, isn't it?

Absolutely! So let's try it.

Using the same process and steps as in my earlier post, loading the full image, placing the test pattern, printing the entire photograph at 122PPI, and then examining zoomed areas of the source data and printed output.


Here's the pattern I used (on a grey BG so you can see the white pixels):

Test Pattern - Zoomed Display.​

Here's what it looks like placed on the image:

Original Pixels - Zoomed Display.​

Here's a HiRez scan of that area of the photograph:

HiRez Scan Of Printed Image.​

Here we can clearly see that the color of neighboring pixels were indeed considered for dithering. This is probably a result of what happens to "a pixel" as it is reformatted into data the printhead can deal with - which are (probably) not pixels at all as we knew them in the file and in the application. This doesn't matter though as the user cannot be concerned with how print-heads work. All he or she needs to know is the result. Whether the pixels are dithered and if the apparent resolution is acceptably sharp and resolvable to the human eye or not.

The entire point of this sidetrack discussion point was over whether it was "OK" or not to print below 150DPI and if in so doing, the results would appear "pixelated". People were saying that it looks fine below 150 - which is true. But I maintain that the reasons for this are the dithering that occurs (somewhere for some reason) during the printing process.

Of course you won't see the Jaggies (especially if very small) when they being rounded, mushed together, or "dithered" by the printer. How much are they dithered and how low can you go before the jaggies look jagged? It depends on the printer of course and the image being printed (high contrast regions will show it sooner, etc.) but with modern ink-jets of the past 2 or 3 years I guess around 100 dpi is not a problem at all for most purposes.

Here are two ultra HiRez scans of the printed image so that you can see very clearly that colors from outside a file-based-pixel-block are considered and used at least for internal dithering if not an algorithm that more closely resembling anti-aliasing <shrug>. It may be the case however that this AA-like algo is only a result of the print head mechanism. Anyway, here the images:

Ultra HiRez Scan of Printed Image - Taken from the lower right corner of the test pattern area.

Ultra HiRez Scan of Printed Image - Taken from the center at the right edge of the test pattern area.
​

So, can a bumble bee fly or nor?


--
PS: I'll never purposely contribute to anything Bill and Malisa Gates are associated with - that includes developing for or purchasing Windows. Occasionally it can't be avoided but try as I may...

 

[Bifurcator]

Oh, almost forgot the source file I used. This is the PSD version actually used:

http://tesselator.gpmod.com/Private_/PrintTest/AA_HangerCLR.psd

 

[Moglex]

Ah, the difference between those who need to be right, those who know, and those trying to learn. Hehehe.. yeah that happens. I haven't seen it here yet - but I'm new. And there are some people like Helen B., Grabz, Usayit, and others who really know what they're talking about and you can just tell from their tone and the way they offer the explanation that what you're reading is right on with only the expected exceptions - they'll keep us honest.

I'm glad it doesn't happen here. The object of a good argument/discussion is education. Usually to both sides as they are forced to think more deeply about whatever it is they are arguing about. From a selfish perspective it's better to lose an argument because that way you've learned more.

You mean printers no longer have a text mode, a drawing mode, and a bitmap mode?

Yes, they still have those modes.

No, I'm still talking about images (bitmaps). So the questions still remans I guess. [This brings up another question though. You said "...as they never see the larger pixels." which I guess means it doesn't receive the source data but rather an expanded version - expanded out to "the resolution of the printer". If that's true (and I'm not doubting it just wondering) then how come if I send a large document already expanded out to the printer's resolution it takes almost a full minute for the printer to receive the data whereas if I send a tiny document (which you're saying gets expanded before it's sent so should be about the same amount of data) it sends entirely and the printer beings in like 2 to 5 seconds?]

If you send something that prints a 2cm x 2cm image to the printer it will send a 2 x 2 fragment. If you ask it to print a similar image in each corner of the page it will send four such fragments.

If, in PSP on PS, you set up a white canvas and place an image in each corner so that you have a large white screen with a small picture in each corner it will send the thing as one very large bitmap.

Of course it's always possible that something will try a bit of lossless compression along the way so it could get sent much more quickly than you expect.

So if you treat them all the same application side, then the driver or printer itself must change the data by dithering, or whatever. I guess the app sends the dimensions and the bitmap data (and probably a few other things depending) and the driver or printer firmware formats and modifies the data to meet the app (user) requested specifications and conform to the printer's physical specs, like number of colors, number of jets, etc. This seems like common sense to me as when I send it a purple pixel it has to decide how much and where to spray the combination of magenta, yellow, cyan, and etc. that make up that pixel's tone of purple.

No.

You (as the programmer) have to (apart from special cases like text, block fills and vector graphics) have to tell the printer the specification of every logical pixel. The printer will split each logical pixel into a number of physical pixels and use that matrix to dither the 3-9 inks it has to get an approximation to the colour you require.

So if I have a 100x100 pixel image that looks quite nice on a 1,200 x 1,024 screen and want to send it to the printer with a resolution of 12,000 x 10,240 so that it looks the same relative size on a piece of paper, I, as the programmer, have to rescale the image before sending it to the printer.

I can either use a built in OS function to do this (in which case it will often look ghastly), or I can do a fairly simple interpolated expansion in which case it usually looks OK.

It seems that PSP et al are capable of a much more sophisticated expansion (See, this is where I've learned something ) as your experiments have so conclusively demonstrated.

So it's doing something to the data already which I guess you already agreed earlier on but limited it to inner pixel operations. That my previous data (examples above) seems to show that it is also considering neighboring pixel data is our only topic of consideration at this point - at least for me.

(See above post for test)

But that still does not - cannot - tell us where the data is being modified.

If you print something from PSP, etc, what happens after you finally press the final 'print' button is just a black box. There is very little you can ascertain from looking at the output of that black box about how it accomplished its task.

The only reasons I'm pretty confident that the application is where the work is being done are:

1) On my printer, if I send it a bit map of a chequerboard pattern that prints at 120 squares per inch that is what gets printed - and I'd be extremely annoyed if it kindly decided I meant 'can I have grey' (or, can I have a series of diagonal lines).

2) In general, I'm sure people would be rather annoyed if they were doing non photographic printing and the printer/driver started modifying their carefully set up patterns because it thought they'd look better that way.

3) The dithering is, as you have demonstrated, very sophisticated. As such it's an area where different software suppliers will want to develop the most sophisticated algorithms they can. If the printer started trying to second guess them and make its own intra-pixel dithering decisions it would lead to the most appalling artifacts being introduced.

So, can a bumble bee fly or nor?

I've always thought that was a very odd aphorism. If someone says a bumblebee can't fly according to the laws of aerodynamics then either the laws of aerodynamics are wrong (unlikely) of they are being misapplied.

I suspect they mean 'can't fly' in the same way that a helicopter 'can't fly'.

Neither a helicopter nor a bumblebee can fly if their wings are not in motion. (Whereas an aeroplane most certainly can :mrgreen

PS: I'll never purposely contribute to anything Bill and Malisa Gates are associated with - that includes developing for or purchasing Windows. Occasionally it can't be avoided but try as I may...

What have you got against Mellisa?

 

[Bifurcator]

Moglex wrote:
1) On my printer, if I send it a bit map of a chequerboard pattern that prints at 120 squares per inch that is what gets printed - and I'd be extremely annoyed if it kindly decided I meant 'can I have grey' (or, can I have a series of diagonal lines).

You don't have an ink-jet then?


2) In general, I'm sure people would be rather annoyed if they were doing non photographic printing and the printer/driver started modifying their carefully set up patterns because it thought they'd look better that way.

They need to buy a printer that does that then. An ink jet is a no go for fine patterns - especially 120 per inch. I believe this part of the discussion was about printing photos on ink-jets though.


3) The dithering is, as you have demonstrated, very sophisticated. As such it's an area where different software suppliers will want to develop the most sophisticated algorithms they can. If the printer started trying to second guess them and make its own intra-pixel dithering decisions it would lead to the most appalling artifacts being introduced.

So you're saying that photoshop did that dithering in my examples? I guess it could be. It's not logical and doesn't jive with my intuition but I guess anything is possible. Anyway it doesn't matter who dithers it. The user has no control over it so dithered is dithered and tough if they don't like it.


I've always thought that was a very odd aphorism. If someone says a bumblebee can't fly according to the laws of aerodynamics then either the laws of aerodynamics are wrong (unlikely) of they are being misapplied.

At the time the laws were actually wrong, yes. Just like quantum physics disproves many of the laws we think are currently correct now.


What have you got against Mellisa?

They are both eugenicists - on a HUGE scale. Taking after their little hero Adolf no doubt. But I've already said too much on that topic. This isn't a political site AFAIK.

 

[Garbz]

I'd like to point out a possibility that it was NOT photoshop which did the dithering.

Use the above and print directly to Distiller the following is the PDF of the cropped area printed at 122 ppi as above and zoomed to 1600%:

The difference is a result of either the printer driver of the inkjet hardware itself.

 

[Bifurcator]

Excellent point, method, and assist! Thanks Garbz!

 

[Moglex]

I'd like to point out a possibility that it was NOT photoshop which did the dithering.

Use the above and print directly to Distiller the following is the PDF of the cropped area printed at 122 ppi as above and zoomed to 1600%:

The difference is a result of either the printer driver of the inkjet hardware itself.

Sadly, that proves nothing.

If PSP etc are not printing to a printer they will handle the output in completely different ways.

I must say I'm getting a little bit puzzled as to exactly why it seems so important to people to believe that it is the printer/driver.

 

[Moglex]

Moglex wrote:
1) On my printer, if I send it a bit map of a chequerboard pattern that prints at 120 squares per inch that is what gets printed - and I'd be extremely annoyed if it kindly decided I meant 'can I have grey' (or, can I have a series of diagonal lines).

You don't have an ink-jet then?

Yes, I was working on an inkjet.

They need to buy a printer that does that then. An ink jet is a no go for fine patterns - especially 120 per inch. I believe this part of the discussion was about printing photos on ink-jets though.

Yes, I never moved away from ink jets. There are, however, many things that people might wish to do with an inkjet that are not printing photgraphs.

For example they can be used to produce facsimile forms where the result would be ruined by ad-hoc unauthorised dithering.

So you're saying that photoshop did that dithering in my examples? I guess it could be. It's not logical and doesn't jive with my intuition but I guess anything is possible.

Why do you find it illogical that specialist photographic processing software would perform a task that was directly related to photograpic processing rather than a printer which usually has general purpose application?

Anyway it doesn't matter who dithers it. The user has no control over it so dithered is dithered and tough if they don't like it.

True, it doesn't matter - this discussion came about as a result of a comment that you made about my printer dithering what I printed (although, unbeknownst to you I hadn't sent it a bitmap) and has just wondered into 'who does what territory'.

What have you got against Mellisa?

They are both eugenicists - on a HUGE scale. Taking after their little hero Adolf no doubt. But I've already said too much on that topic. This isn't a political site AFAIK.

Good Grief!

I wasn't aware of that.

I can see why you would hold that attitude.

 

[Bifurcator]

Moglex Worte:
Yes, I was working on an inkjet.

Yes, I never moved away from ink jets. There are, however, many things that people might wish to do with an inkjet that are not printing photgraphs.

Probably. But that's another discussion all together.


Why do you find it illogical that specialist photographic processing software would perform a task that was directly related to photograpic processing rather than a printer which usually has general purpose application?

Because when I do print from file it does the same thing. No PS loaded. Likewise if I print from the browser or ANY other utility.


True, it doesn't matter - this discussion came about as a result of a comment that you made about my printer dithering what I printed (although, unbeknownst to you I hadn't sent it a bitmap) and has just wondered into 'who does what territory'.


Ah, why didn't you say so? So this is a result of miscommunication. Sorry about that. Here's the exchange I believe you're referring to:

Originally Posted by Moglex
I actually did a couple of prints at 75 DPI and there was no visible pixilation even when examined under a magnifying glass.

As to 'acceptable' sharpness, this always seems like a moveable feast.

A 10 x 8 from a half frame camera could look perfectly sharp and detailed.

Compare it to the same scene from a full frame and it looks much less impressive.

Compare the full frame to a Hasslebal shot ...

Until you end up as Ansel Adams there's always somewhere to go.

It really does depend entirely on the purpose of the finished print - so much so that stating an arbitrary figure of 300 DPI is a nonsense.

Bifurcator Replied:
"I actually did a couple of prints at 75 DPI and there was no visible pixilation even when examined under a magnifying glass."

Don't most printer drivers apply diffusion dithering? Mine even let's me choose diffusion or ordered. This is going to smooth out what would otherwise be noticeable pixelation.​

Anyway it's been fun for me. Thanks man!

 

[Moglex]

Why do you find it illogical that specialist photographic processing software would perform a task that was directly related to photograpic processing rather than a printer which usually has general purpose application?

Because when I do print from file it does the same thing. No PS loaded. Likewise if I print from the browser or ANY other utility.

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

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.

If, on the other hand you are printing it for handling by a device independant program such as to a .PDF file then it cannot make dithering decisions since it does not know how it will ultimately be rendered.

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

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

True, it doesn't matter - this discussion came about as a result of a comment that you made about my printer dithering what I printed (although, unbeknownst to you I hadn't sent it a bitmap) and has just wondered into 'who does what territory'.


Ah, why didn't you say so? So this is a result of miscommunication.

I don't see what diffrence that makes. Because of that misunderstanding (which was my fault rather than yours) we started talking about the dithering of bitmaps. How we started talking about that seems immaterial.

Anyway it's been fun for me. Thanks man!

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.

Only your experiment with printing from a browser and getting the same result casts even the slightest glimmer of doubt in my mind.

I'd need to examine the methodology you used to do that test to make any sense of it.

It does imply that the printer/driver is doing the most incredible pre-processing since it would need to examine the expanded pixelated input to try and work out what the resolution of the bitmap was before the calling program expanded it and sent it to it, then re-pixelating it before applying its own dithering algorithms.

Being able to do that and never getting it wrong and producing obvious artifacts would be a stunning achievement and the fact that no printer manufacturers have ever been reported as letting a faulty version of such incredibly complex software out into the wild would be even more impressive!

 

[Helen B]

One little exercise that I found interesting is to print a chequerboard of black and white pixels and one-pixel-wide black and white horizontal and vertical lines, at different ppi and dpi settings using different drivers and RIPs.

On most of my Epsons, which have a native dpi of 2880, 288 ppi (follow the abbreviations carefully) produces the most accurate print (ie the closest match between what goes in and what comes out). That's fairly logical for a 2880 dpi printer. The printer driver has to break the incoming pixels per inch into print cells per inch and then dots of ink per print cell. It has a native resolution for that. Using a RIP (OPM to be exact) there is never the same accurate correspondence between input and output at any ppi, but 300 ppi and 360 ppi are both close.

RIPs do do dithering, there's little doubt about that. You get to choose how it is done with some RIPs. It's often difficult to beat the printer manufacturer's dithering, but it can be done.

Of course dpi here is referring to 'print cells' per inch, not actually dots per inch, because there is more than one dot of ink in a print cell.

Best,
Helen

 

[Garbz]

Sadly, that proves nothing.

If PSP etc are not printing to a printer they will handle the output in completely different ways.

I must say I'm getting a little bit puzzled as to exactly why it seems so important to people to believe that it is the printer/driver.

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.

But I agree this entire discussion doesn't have any real implications as far as I can gather.

 

[Bifurcator]

I think it has real and interesting implications. Between us I think the following is now fairly clear:

On a typical $250 to $500 home ink-jet:

• 100 PPI ~ 125 PPI is good enough for casual printing. There can be some jaggies but because of the printer and/or driver dithering they won't slap you in the face unless you look for them.
  
• 150 PPI is good enough for wall hangings where the occasional guest will stick their nose right up against the glass. You won't be embarrassed when they do and they probably won't think to ask if you printed that out yourself.
  
• 300 PPI ~ 360 PPI is what you want if you're entering the print in a photo contest - (and added here now - you'll probably want a 7-ink printer). Especially if there are high contrast fine lines or patterns like screens, wrapped-wire guitar strings, etc.
  
• And Epson might be a little sharper than Canon (or HP?) if you need ultra crisp.

I would say that's useful information. But I'm a total gerd* too.


--
* Nerd + Geek = Gerd.