# Resolution concern?



## bisp21 (Jun 5, 2008)

If resolution is my main concern when taking pics, should I be most focsused on getting a DSLR with a higher number of megapixels?


----------



## *Mike* (Jun 5, 2008)

Resolution shouldn't be your main concern.  So, umm, no it shouldn't be the biggest factor in deciding on a body.


----------



## Garbz (Jun 5, 2008)

An 8megapixel camera can comfortably print an A4 with exceptional detail. Now as the sizes increase (A3 A2, larger even). You will find yourself standing further and further back from your photo and you will not notice a difference.

Too many consumers especially get caught into the megapixel race thinking more means better. These same people also rarely print photos larger than 6x4, something very easily done at high qualities with a 1-2megapixel camera.


----------



## JimmyO (Jun 6, 2008)

Garbz said:


> AThese same people also rarely print photos larger than 6x4, something very easily done at high qualities with a 1-2megapixel camera.



Or worse, they just stay on a computer and take up ridiculous amounts of space on your HD.

 Ive printed 8x10's from my D1h (2.7 mp) and you could never tell, so no. That is unless you need to take pictures to put up on billboards...


----------



## Alfred D. (Jun 6, 2008)

OK. Let's whip out the megapixel printchart again. Here's your answer, bisp:







*Those figures pertain to 'true photo quality', which is 300dpi viewed at 15" distance (normal reading distance). If the viewing distance is greater you need less dpi.*


----------



## reg (Jun 6, 2008)

These charts that determine "true photo quality" are made by people with as inflated a head as you.

True photo quality is in the eye of the viewer.


----------



## JimmyO (Jun 6, 2008)

reg said:


> These charts that determine "true photo quality" are made by people with as inflated a head as you.
> 
> True photo quality is in the eye of the viewer.




:thumbup:, but to an extent

None if this matters if you cant take sharp pictures anyways:er:


----------



## Rogan (Jun 6, 2008)

if i wanted to print an A3 poster
wud a nikon d50 produce images that wud be acceptable to print this size?


----------



## bisp21 (Jun 6, 2008)

Alfred D. said:


> OK. Let's whip out the megapixel printchart again. Here's your answer, bisp:
> 
> 
> 
> ...


 

Thanks everyone and especially Alfred (for the chart)!!  This is exactly what I was looking for...


----------



## Garbz (Jun 6, 2008)

Just bear in mind it assumes all photos are true photo quality where it's defined as viewed from 15"

I guarantee if you print a photo the size of a billboard you won't view it from 15" so you most definitely won't need 300dpi for it to look good.

I love the **At 150dpi printed images will have visible pixels and details will look "fuzzy". Yeah but when I print at 150dpi I am making an A3 print and I'll be 30" away when I look at it hanging on my wall and woah I can't see the pixels anymore.

All print charts should be taken with a grain of salt based on their definition of what is "photo quality"


----------



## *Mike* (Jun 6, 2008)

Garbz said:


> I guarantee if you print a photo the size of a billboard you won't view it from 15" so you most definitely won't need 300dpi for it to look good.



Very true.  I've run billboards, and shot for them.  Lamar Outdoor - one of the US's biggest billboard companies - asks for an 8x10 or the "file equivalent"!

I was told that in a pinch, they'd make do with a 5x7.  I never pushed it that far... But, 8x10 at 300dpi looked awesome when we ran ours.


----------



## bisp21 (Jun 6, 2008)

*Mike* said:


> Very true. I've run billboards, and shot for them. Lamar Outdoor - one of the US's biggest billboard companies - asks for an 8x10 or the "file equivalent"!
> 
> I was told that in a pinch, they'd make do with a 5x7. I never pushed it that far... But, 8x10 at 300dpi looked awesome when we ran ours.


 

When you sayd billboards and 8X10 are you referring to the huge billboards and 8 feet by 10 feet?  

If so, what type of camera are you using.  My goal is to take great landscape pictures and blow them up in to huge printed canvas framed images and also takes some pictures of my daughter that I can blow up pretty big and gallery wrap.  I am thinking I want to blow them up to 60 inches and will be using a 300dpi printer for the canvas.  What do you think?  Will it look ok using a Nikon D80 10.2 megapixel?


----------



## reg (Jun 6, 2008)

bisp21 said:


> When you sayd billboards and 8X10 are you referring to the huge billboards and 8 feet by 10 feet?
> 
> If so, what type of camera are you using.  My goal is to take great landscape pictures and blow them up in to huge printed canvas framed images and also takes some pictures of my daughter that I can blow up pretty big and gallery wrap.  I am thinking I want to blow them up to 60 inches and will be using a 300dpi printer for the canvas.  What do you think?  Will it look ok using a Nikon D80 10.2 megapixel?



I'm not him - but Lamar is a billboard company as in the huge 8x10' ones. A _few_ of us in the thread pointed out why the resolution chart is pointless - you don't get 15" away from a billboard, unless you're putting the ad up. 

When viewed from the ground, usually while driving by, the photo quality doesn't have to be _that _fantastic.

The 8x10" that *Mike* says Lamar prefers, at "photo quality" 300dpi, is 8 megapixels. So the D80 should be fine for that size.

Edit: and one more thing to remember is that the photo itself generally isn't the whole billboard. It's usually like 40% pic, 60% text, or a logo, smaller picture, and text, etc. So you're not stretching it as far as it may sound.


----------



## *Mike* (Jun 6, 2008)

reg said:


> The 8x10" that *Mike* says Lamar prefers, at "photo quality" 300dpi, is 8 megapixels. So the D80 should be fine for that size.
> 
> Edit: and one more thing to remember is that the photo itself generally isn't the whole billboard. It's usually like 40% pic, 60% text, or a logo, smaller picture, and text, etc. So you're not stretching it as far as it may sound.



Yep, true and true.  Small file, huge print - although granted not full-bleed at that size.  It's viewing distance, as everyone has said.  

A less dramatic example, I used to shoot with an Oly E-1.  I routinely printed 20x30 prints for clients and sold them for top dollar.  The E-1 is a 5mp.

My position is that just about any DSLR on the market today will create gorgeous images for just about any purpose (provided the exposure and focus are good to begin with.)  For those rare cases where resolution is truly important, then that's what digital backs are for.   )


----------



## kundalini (Jun 6, 2008)

*Mike* said:


> ....then that's what digital backs are for. )


I have often wondered what the purpose of a digital back is for. Care for a short explaination?  Thanks.

Apologies if this constitues a hi-jack.


----------



## reg (Jun 6, 2008)

kundalini said:


> I have often wondered what the purpose of a digital back is for. Care for a short explaination?  Thanks.



They're built to be used mostly on the back of medium and large format cameras. Dynamic range is higher, and they don't suffer noise on long exposures nearly as bad. Digi backs can shoot exposures up to an *hour *at about 70-80 degrees before the pixels start getting funky. And, of course, if you find something cool in a detail of your 40MP picture, you can always crop *it *down to an 8x10.


----------



## RyanLilly (Jun 7, 2008)

I Know Alfred loves that chart recently, but Its all about viewing distance. You cannot even see an entire 20x30 print from 15 inches, you have to step back quite a bit to view the whole picture, therefore 300dpi is quite unnecessary, I have made great 8x10 and 11x14" prints with 4MP and they looked great even from arms length. So don't get caught up in the MP hype, really any current body can produce reasonably large prints at high quality.


----------



## Bifurcator (Jun 7, 2008)

There's another aspect that is important to me at least and that I think you've all overlooked here. Cropping, and BG scrolling. With todays HD cams recording 4k frames a 21mp digital back is still too small sometimes. Also just like rapid fire exposure is a useful technique so can be giga-pixel sensor or sensor arrays. Just point your camera in a general direction and go home. Once on your machine you have 100's or great "pictures" to choose from by selecting and cropping. 

For me I can never get enough pixels! The threshold between shooting 200 shots with an 8mp cam and being able to capture most or many of those in just a few 8gp shots just hasn't arrived yet is all.

On that topic I think it will go in a different direction myself. I think they'll figure out how to combine vector, fractal, and light-field technologies in such a way that HDR will seem poor and retarded and at truly scalable resolutions limited only by the glass you're shooting though - and at a wider spectrum than the 400 to 700 visible light we seem to be stuck in now. Some may be very surprised at how much detail is present in higher frequencies that image sensors have no trouble recording.

Kind of a long ramble just to say I want more than 21mp just because of the cropping thing... Sorry. :blulsh2:


----------



## Bifurcator (Jun 7, 2008)

JimmyO said:


> :thumbup:, but to an extent
> 
> None if this matters if you cant take sharp pictures anyways:er:



You've hit either on purpose or by accident, on a very interesting relationship between pixel resolution, apparent resolution, and scale. Meaning that actually if someone can't (or didn't by mistake or whatever) take a sharply focused image then it is exactly pixel resolution that will save his or her day.

Try it. Take a slightly out of focus picture and then either scale it in PS or print it at passport image size. Super sharp right? The same would apply for an A4 print. At 8MP there's not much room for error if you want to print to an A4. If it was 24mp you could get away with being slightly out of focus. If it were 8GP likely focus would not matter much at all - as long as you were in the general ballpark. Do I hear 8 terapixels? Anyone?


----------



## Garbz (Jun 7, 2008)

The problem of course is that that beyond 10 megapixels you'd be hard pressed finding a 35mm lens that can resolve the sensor resolution.


----------



## Bifurcator (Jun 7, 2008)

YAY for medium and large formats!  Hehehe

But all seriousness aside what do you mean exactly? I thought we were still along ways away from that even at 24MP?  I don't really know as I haven't looked at that - but only cuz I thought I didn't need to for awhile yet.

Are the 12MP cameras out in abundance interpolating or something? Or the 21mp Canon for that mater?


----------



## Ben-71 (Jun 7, 2008)

There was a mistake in my previous post. I was both tired 
and pre-occupied by something else, sorry about that.

Here it is, corrected*:*
bisp21 ​ 
My goal is to take great landscape pictures and blow them up in to 
huge printed canvas framed images and also takes some pictures 
of my daughter that I can blow up pretty big and gallery wrap. 
I am thinking I want to blow them up to *60 inches* and will be using 
a *300dpi printer* for the canvas. What do you think? Will it look ok 
using a Nikon *D80 10.2 megapixel?*​​That's easy to test and see for yourself*:*

You may take a pic with fine detail, a portrait for instance. 
Enlarge a section of the eye (eyelashes included, for fine detail) to, 
say 8x10", keeping the enlargement proportion similar to that of your 
end goal.
Print it on the same material of your end goal. That's how your large 
print would look like. See how it looks from a distance.​ 
Approximately ​ 
According to Alred .D's chart, there should be 300ppi for a 7" print.
(1") 25.4mm *:* 300ppi = *0.085*mm dot size.​ 
Going from 7" to 60" print is a linear magnification of ~X*8.6*
*0.085*mm x *8.6* = *0.73*mm dot size ​ 
Assuming an enlargement of (40" x 60") 100cm x 150cm,
the area is: 100 x 150 = 15,000 sq.cm​ 

*D300:*
15,000 (sq.cm) *:* 12,300,000 (effective pixels) = 0.00122 sq. cm per pixel
Dot size is a 0.035 x 0.035 cm square = *0.35* x *0.35* mm​ 
*D80:*
15,000sq.cm *:* 10,000,000 (effective pixels) = 0.0015 sq. cm per pixel
Dot size is a 0.039 x 0.039 cm square = *0.39* x *0.39* mm square​ 
Both are quite smaller than *0.73*mm.​ 
*300dpi printer:*
25.4mm *:* 300dpi = *0.08*mm
In this case, the 300dpi printer dots are smaller than the camera resolution.​ 
From 2.25 meters, I could notice *1*mm gradation on a ruler (black on white).
I couldn't count them, they looked somewhat blurred, but I could perceive that
there're details, and my eyesight isn't 6x6.​Therefore, the *0.73*mm dot size seems to me to be a bit too large, but the 
*0.39*mm dots may be acceptable for what you want.

I suggest trying a test enlargement, using RAW and the sharpest 
lens you can lay your hands on, and see if it suits you.​ 
(And, draw a "do not cross this line" on the floor, 2.25 meters from 
the prints  )


----------



## Garbz (Jun 7, 2008)

Bifurcator said:


> But all seriousness aside what do you mean exactly?



Well high-res sensors are still good since slightly unsharp photos look much better than upscaled low-res photos. But the problem is a sharpness of 35mm lenses. There's a finite amount of resolution you can get out of a lens due to diffraction, and 2 or 3 stops from wide open many quality lenses have already managed to hit that point.

Photozone actually use 10mpx cameras to measure the LW/PH resolution figures of lenses by shooting a resolution target and measuring the result. Now in reality it's not a top idea, but it does work well enough to give you a general idea how cheap / prosumer lenses perform.

For instance their graph clearly shows that the Nikon 50mm f/1.8 is shocking under f/4, and by shocking I mean you could probably see the sharpness wane even on an old 4-5mpx body. Some lenses however like the Carl Zeiss Planar 50mm f/1.4 T show an almost flat response up to the point where diffraction causes it to lose sharpness. I'm inclined to believe this lens outperforms the 10mpx sensor of the D200 they used but then for $1000 for a 50mm f/1.4 with no autofocus you want to hope so. There's other lenses that do this too but you can guarantee they all have a signature Red ring or Gold ring on the front depending on the company.

As the sensor gets larger though the effects of diffraction diminish, and if you look at something like the 40mpx medium format sensors their photodetectors are much larger than those on our APS sensors so you end up with 40megapixels a much nicer image, a lens that utilises it, despite the actual "resolution" of the lens not being much greater, just light is spread across a larger area.

I really don't see much point in the new flagship Canons and their ludicrously high-res sensors for this reason. I'm not sure the glass is available (currently) to utilise them.


----------



## sonny. (Jun 7, 2008)

Alfred D. said:


> OK. Let's whip out the megapixel printchart again. Here's your answer, bisp:
> 
> 
> 
> ...





reg said:


> These charts that determine "true photo quality" are made by people with as inflated a head as you.
> 
> True photo quality is in the eye of the viewer.



dead poets society anyone?


----------



## reg (Jun 8, 2008)

sonny. said:


> dead poets society anyone?



you don't view a billboard from 15" away. Therefore, you can't use 300dpi at 15" for a billboard-size photo. It says that on the chart, but some in the thread aren't compensating for that.

Thanks for playing, next time comment on something you know.


----------



## Bifurcator (Jun 8, 2008)

Garbz said:


> Well high-res sensors are still good since slightly unsharp photos look much better than upscaled low-res photos. But the problem is a sharpness of 35mm lenses. There's a finite amount of resolution you can get out of a lens due to diffraction, and 2 or 3 stops from wide open many quality lenses have already managed to hit that point.
> 
> Photozone actually use 10mpx cameras to measure the LW/PH resolution figures of lenses by shooting a resolution target and measuring the result. Now in reality it's not a top idea, but it does work well enough to give you a general idea how cheap / prosumer lenses perform.
> 
> ...




Wow!  And we're already there at just 10mp? That sucks! I thought for sure we had till at least 80 or 100mp. The RAW crop comparisons I looked at between the D3 and the 21mp Canon didn't seem to suggest that although I wasn't really looking for it either.  I don't doubt you. I'm just disappointed that the optical resolving powers of the typical $200 f2 20 through 80 FFL lenses are all eaten up at 10 or so megapixels. Really, that sucks man! 

So, the fast ride is over then. Now it's all about features and better sensitivity, higher bit depths, maybe we'll start seeing light-field technology showing up. Hmm, now I'm eager to see what the D4 or D5 have to offer.   I have some engineer friends at Nikon (though on the microscope side) I wonder if they'll let me pick their brains over a beer or two? Muahahahaaaa :evil:.


----------



## Garbz (Jun 8, 2008)

Well for many practical purposes we are, but just like the topic of resolution itself it depends on the printing, viewing distance, and some key ones are aperture and sensor size.

My example above with the D200 suggests that APS sensors are limited but by all means because diffraction is dependant on sensor size it is actually possible a lens performs a bit differently on 35mm. So while the cheapy 50mm f/1.8 may be sharpest at f/4 on the D200, on the D3 it may actually be sharper at f/5.6. 

Plus I mentioned that there are still outperforming lenses out there. The only time I've ever seen a D3 it had that lust worthy 14-24 f/2.8 N lens on it. The photozone review gave identical resolution figures at all apertures which is a warning light for me that the sensor is maxed out using this lens. I doubt the review of the D3 had the ever wonderful 18-200mm on it 

We still have a bit to go but I doubt we'd ever realistically need to battle medium format type megapixels on a 35mm frame. I was pleased to see Nikon announce the 12mpx D300 and 12mpx D3 on the same day and that they didn't crank 18mpx on their full frame camera. So maybe the race is over. If you do get a chance to talk to them I'd be very interested in their opinions.

The race won't be over for the consumers though, megapixels is the only number they understand and unfortunately it sells cameras regardless of how crap a 10mm wide lens is. My dad's Olympus P&S's lens isn't even capable of outperforming the 4mpx sensor it has


----------



## AndrewG (Jun 9, 2008)

Good quality lenses are far more important than getting fixated on pixel counts.


----------



## JimmyO (Jun 9, 2008)

And having extra pixels wont make up for a misfocused shot.


----------



## Bifurcator (Jun 9, 2008)

Depending of course on how out of focus and how many mega pixels we're talking about.


----------



## mr_baseball_08 (Jun 9, 2008)

Bifurcator said:


> Depending of course on how out of focus and how many mega pixels we're talking about.



And how far away you view it from.  LOL


----------



## Bifurcator (Jun 10, 2008)

Very true!


----------



## PortraitMan (Jun 10, 2008)

Wow.  All this brainy stuff is giving me a headache!  Along simpler lines, I'd say the megapixel size you need depends upon what you're doing.  

As a portrait photographer, I used to use medium format film.  Yet I always had to slide a little mesh diffuser down into my bell-o-shade to soften up facial features; unflattering details that stood out loudly on medium format film.  But when I went to digital (6 megs originally), I didn't need to diffuse anymore!  

Nevertheless, since eyes and teeth in larger family groupings would interpolate nearby colors making them flesh toned and wrong, I knew I eventually needed higher megs.  Finally I got 10 megs and while there's less interpolation in smaller areas, now I'm noticing unflattering facial details are standing out again... Therefore the higher quality image can be a double-edged sword depending upon one's use.  I spend more time retouching...

I think I may be set to stay with 10 megs as it suits my need for most portrait applications.  Contrary to the statistical figures, I've found that I can easily print up to 20x24 wall portraits that look just as good as film did, even better, because I always shoot with a tripod.  And with a little lab art for eyes I can go 24x30 with great results.  

Sure, if my clientele consisted of customers wanting bigger images, I suppose I'd dare move up to 12 megs or higher, but since that's not the case, I'm set.


----------



## bisp21 (Jun 10, 2008)

PortraitMan said:


> Wow.  All this brainy stuff is giving me a headache!  Along simpler lines, I'd say the megapixel size you need depends upon what you're doing.
> 
> As a portrait photographer, I used to use medium format film.  Yet I always had to slide a little mesh diffuser down into my bell-o-shade to soften up facial features; unflattering details that stood out loudly on medium format film.  But when I went to digital (6 megs originally), I didn't need to diffuse anymore!
> 
> ...



Good info everyone!!  Thanks for your input PortraitMan that is what I was looking for.  I am looking to blow up some images to about 45 inches and maybe even a little bigger.  I am mainly going to be taking landscape and architectural pictures.  I am probably going to stay with the Nikon D80, but considering the D300 and the Sony Alpha A350.

What DSLR do you use?


----------



## skieur (Jun 11, 2008)

To complicate the issue of megapixels and image quality even further, when you get beyond 12 megapixels or so, you may also see slight artifacts and fine noise on the screen after post, that won't show up in a print.

When considering cameras of course, a top lens is necessary to make the most of the large megapixel count.  Most of the reviews are done with the kit lens which make a difference.  An expensive gold Zeiss lens on a Sony A350 will naturally produce better image quality than a $200 kit lens.

As to size and viewing distance, billboards is rather an unrealistic analogy since most here will not be taking photos for this use.  Photos in coffee table books and even posters however are often looked at the reading distance of 15" used in the chart.  A lot of people still go up close to a photo enlargement on a wall to see if it is really sharp.

So despite all the rhetoric, all things being reasonably equal and average, resolution and megapixels can make a difference.

skieur


----------



## reg (Jun 11, 2008)

skieur said:


> So despite all the rhetoric, all things being reasonably equal and average, resolution and megapixels can make a difference.



I don't recall seeing anyone say that they didn't...
Just that they aren't as important as all the pixel-peeping, chart-making Alfreds would like for you to believe.

And.... barring that.... there's always Genuine Fractals.


----------



## Garbz (Jun 11, 2008)

bisp21 For landscapes megapixels is the least of your worries. I find trees do not tend to run off in a hurry so it's quite easy to take 10 shots and make a large 80megapixel panorama, once you get the hang of panorama software.

And with a photo like that you could print multi metre long images that satisfy even the pixel peepers.

This may be less ideal for architectural stuff unless you have a panoramic tripod head.


----------



## notelliot (Jun 11, 2008)

first time i've seen that print chart deal - pretty useless, IMO. 
i'm sitting 18 inches from a 20x36 print from a d70s (6.1mp) and see no pixels.
i also have a 24x36 from a D2h that looks stellar. 


btw, Garbz, the other day i saw a woman with a D3 and 18-135 on it. i tried not to give her a dirty look, but it happened. :blushing:


----------



## JimmyO (Jun 11, 2008)

notelliot said:


> btw, Garbz, the other day i saw a woman with a D3 and 18-135 on it. i tried not to give her a dirty look, but it happened. :blushing:



:banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead::banghead:


----------



## Garbz (Jun 11, 2008)

LOL. Last time I gave a woman with a camera a dirty look she dirty looked back. What was the point, she only had a D200. Oh well at least she has a lens with VR that I now get to play with .


----------



## PortraitMan (Jun 12, 2008)

A "kit" lens is not necessarily a bad thing... My first Nikon kit lens still gets rave reviews: the  AF-S DX Nikkor 18-70 mm f/3.5-4.5G IF-ED.  I've made a lot of money with this puppy.  

And when you're talking about megapixels, another thing to remember is that 6 or 8 or 10 megs on one camera sensor is not equal to 6 or 8 or 10 megs on another camera's sensor.

You probably know this.


----------



## icassell (Jun 12, 2008)

Don't forget that not all megapixels are equal.  The quality of the sensor is very important.  Some are far better (or worse) than others.  

My 30D is 'only' 8.2MP, but is is plenty for me!


----------



## Bifurcator (Jun 12, 2008)

Hehehe you guys both posted the same thing (kinda) at the same time. (great minds...) 

I think it's not obvious to most people tho and it's good to say it. It certainly is true.


----------



## Moglex (Jun 15, 2008)

At the bottom of that chart it says:

"At 150 BPI printed images will have visible pixels and details will look "fuzzy"".

So why is it that an image displayed on my monitor at 80 BPI can look pixel free and perfectly sharp?

From memory a 'standard' VGA 640 * 480 could look stunning on a 14" monitor and this would be less than 55 BPI.

How a print will look depends upon a complicated mix of subject type, lens quality, sensor quality, sensor size, magnification and printer/paper/ink quality. It cannot be encapsulated in something as simple as a fixed BPI figure.


----------



## Sw1tchFX (Jun 16, 2008)

I've printed 20x30 from 6MP and would never hesitate to do so again...and again..


----------



## Bifurcator (Jun 16, 2008)

Moglex said:


> At the bottom of that chart it says:
> 
> "At 150 BPI printed images will have visible pixels and details will look "fuzzy"".
> 
> So why is it that an image displayed on my monitor at 80 BPI can look pixel free and perfectly sharp?



Different media. One is a lit (luminous) pixel the other is a reflected light off of paper. It's different and the eye's blur it differently. But you're both right here 150 is more of a pro grade standard if I can call it that. 122 and maybe lower looks awesome to me!


----------



## Moglex (Jun 17, 2008)

I actually did a couple of prints at 75 DPI and there was no visible pixilation except 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.


----------



## TamiyaGuy (Jun 17, 2008)

I agree with the likes of Reg, Moglex, Sw1tch, etc. The number of pixels in a camera nowadays has very little meaning, yet camera maufacturers constantly bring out cameras with more and more pixels. Why, you might ask? Because it's almost the only thing the makes up camera's quality that can be expressed in cold, hard numbers. Back in the days when the absolute top-of-the-range models had 2.7mp, this had SOME meaning (although as Sw1tch explained, not all that much), but now it's just hype.

Many, many other things in a camera make much more of a difference than megapixels ever can, like image noise, sensor quality, lens quality, image processing, and many many more things. The problem is, they can't be expressed in numbers, so manufacturers keep with the "more pixels = better photos" motto (I guess you could express those things in numbers, but you'd need a PHD in computing to understand what they meant )

And just remember that at the end of the day, you're the one taking the photo, not the camera. If you're a terrible shot, a 200MP camera can't make up for it. Likewise, if you're a really good photographer, you can take photos with a 2mp camera and sell them for hundreds.


----------



## Bifurcator (Jun 17, 2008)

Moglex said:


> 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. 

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


----------



## Moglex (Jun 17, 2008)

Bifurcator said:


> 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.



The printer dithers *within* a source pixel.

If it started dithering between them it would end up damaging the resolution of the material it was supposed to be printing.

If you send it something at a resolution of 100 DPI and it is capable of printing 1000 DPI that gives it a 10x10 area with which to play in as it combines the ink colours it has available to make up the desired colour for the source pixel.

I did wonder if the people who made the chart were getting confused between something that *printed* at 150 DPI, which would certainly show pixilation (due to not having enough pixels to adequately dither the colour palatte) and somthing with a source resolution of 150 DPI which should not show pixelation provided the printer has the printing resolution to cope.


----------



## Bifurcator (Jun 17, 2008)

Moglex said:


> The printer dithers *within* a source pixel.



OK, that'll still smooth out the apparent resolution tho right? And what would look blocky on a non-dithering device will appear smooth... or at least smoother! True?


----------



## Moglex (Jun 17, 2008)

Bifurcator said:


> OK, that'll still smooth out the apparent resolution tho right? And what would look blocky on a non-dithering device will appear smooth... or at least smoother! True?



Technically, if it did not dither within a pixel it would look *posterised*, which would certainly make the pixels stand out so you could legitimately say it would look pixilated, yes.

However, this (dithering) will have no benefit in making the source look smoother because all it will do is make the pixels in the source the correct colour.

The printer *cannot* take it upon itself to smooth the data it is given otherwise it might smooth out information that was actually wanted!

So the bottom line is: if the data is at such a low resolution that it should appear pixilated then the printer cannot assist in making it look non-pixilated.


----------



## Bifurcator (Jun 17, 2008)

Well, I dunno. I kinda think that's one-a-dem laws which don't translate into reality like the physics equations that say it's impossible for bumblebees to fly. 

Let's look and use our own powers of observation:

So I printed a photograph to an "L" sized print on my brand new MX850 inkjet uber-hires printer at it's finest setting with it's highest grade "special" photopaper. I sent the data over at 122 PPI - which is supposedly what some higher resolution magazines generally use as source image data.

Here's a crop of the image with the area we're looking at marked:







I also cut off the bottom and side a little bit in a crop to make it generally smaller.

OK, let's see what it looks like in photoshop zoomed up on that area with all the display diffusion dither settings turned off of course. 






This is grabbed in PNG format so that there'll be no j-peg noise. These are _the actua_l pixels that were sent to the printer. 

Now let's look at what the printer and driver did to the data. 






Wow that looks dithered inside and out and interpolated to me at first glance.  But that's what my camera saw... Maybe it added something? OK, here then is a scan of the same area with all the color profiling, dithering, and other options turned off:






Hmm, yeah, I suppose it _could_ be only internal dithering as you say. Whatever it is it sure made a smooth mess of the original pixels.

The data is here. What conclusions do you draw?


----------



## Bifurcator (Jun 17, 2008)

BTW, the printed photograph looks just about perfect. I can notice jaggies if I look hard enough around any areas of contrast but only if I hold it about 10 inches from my eyes and look for them. Set on the desk 21 to 24 inches away it looks 100% perfect.


----------



## Alex_B (Jun 17, 2008)

bisp21 said:


> If resolution is my main concern when taking pics, should I be most focsused on getting a DSLR with a higher number of megapixels?



I could not be bothered to read rthe over 50 replies to this.

But anyway, resolution and megapixels are two different things!!

resolution depends on the whole optical system, including the lens. hence lots of MP require good lenses. 

how big do you want to print? for the standard print on the wall, IMHO 8-10 MP will be enough, given there is not too much noise and the lens is ok.


----------



## Garbz (Jun 17, 2008)

Bifurcator this is entirely dependant on software and printer drivers. There are many packages out there which will interpolate data if you zoom in to print independent of the driver. Some drivers may or may not do it too. My Canon IP4200 definitely produces blocky results if I print at 100ppi and then scrutinise the result.


----------



## Bifurcator (Jun 18, 2008)

I didn't zoom in to print though. I printed the whole image and then pointed my camera at a tiny little section of it. The image was printed in Photoshop by loading the file, setting it to 122 DPI and pressing print. Also the driver is set to not "do anything" to the file and allow the printer to decide everything.  If I set it to allow Photoshop to decide (as I did in the past once) it looks like total cr*p.  Not sure why.

Or did you mean something else and it went over my head? (wouldn't be unusual for me  )


----------



## Garbz (Jun 18, 2008)

Not quite sure any more I am totally confused. So you set photoshop to print at 122dpi and nothing else changed? I'll have a play in a sec.

By the way the reason is looked like crap is if you do anything in photoshop that changes the default normal output you need to disable all colour management in the printer driver. This is a case of photoshop adjusting the colours to your printing space, the printer assuming that the incoming data is sRGB and converting it again. But it only really makes a difference if you have a decent wide gamut printer and a wide gamut source image too.


----------



## Bifurcator (Jun 18, 2008)

OK, that's good to know.  I don't remember if it was wide or not tho - that was 3 or 4 months ago.


Anyway, yes, all I did to the image was load and set it to 122 PPI and printed it.  
Then I zoomed up in PS and did a screengrab of the massive square blocks you saw. 
And then I found the same area on the printed output (deluxe "fine" Canon photo paper),
and both took a picture of it with a #14 close-up lens on a 200mm Macro,
and also put the printed photo on the flatbed and selected and scanned the same area (with all the scanner enhancement features turned off) at 2400 DPI. 
I scaled everything in PS (making sure that no significant data was altered) so that everyone could see and compare the three samples: 
1 scan of the print, 
1 photo of the print, 
and the screengrab of the actual pixels for that area.
at a similar size and magnification.

You should be able to almost overlay them perfectly as is in layers for a good comparison.

Also with the scan and the photo of the print isolating the 3 (or 4 if you do CYMK) color channels of each and turning it into gray data is a little bit interesting. BTW this printer is a 5 cartridge printer but only 4 are used in printing photographs (C, Y, M, and K) the second (blacker) black I think is only used for text and vector graphics.


----------



## Moglex (Jun 21, 2008)

Bifurcator said:


> Well, I dunno. I kinda think that's one-a-dem laws which don't translate into reality like the physics equations that say it's impossible for bumblebees to fly.
> 
> Let's look and use our own powers of observation:
> The data is here. What conclusions do you draw?



I was hoping that someone with a longer track record here would answer this as they would presumably have more credibility but as no one has:

Firstly, I suppose it's always possible that Microsoft have introduced some entirely new way of talking to printer drivers that they have only made the people at Adobe and the like aware of. But that's *extremely* unlikely.

The reason that I state with almost 100% confidence that the dithering has been done in the photo program (whatever you may have told it to the contrary) is this:

When you send data to a printer (via its driver) from a Windows program you send it *at the resolution of the printer*.

Thus the printer driver and the printer are never aware of the resolution at which the source would be printed if you could magically cover the requisite amount of paper with the available pixels.

So the printer and its driver simply cannot perform interpixel interpolation/dithering as *they never see the large pixels*.

I hope that all makes sense.


----------



## Bifurcator (Jun 21, 2008)

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 (Jun 22, 2008)

Bifurcator said:


> 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 (Jun 24, 2008)

Moglex said:


> 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 (Jun 24, 2008)

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 (Jun 24, 2008)

Bifurcator said:


> 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 (Jun 24, 2008)

*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 (Jun 24, 2008)

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 (Jun 24, 2008)

Excellent point, method, and assist!  Thanks Garbz!


----------



## Moglex (Jun 24, 2008)

Garbz said:


> 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%:
> 
> ...



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 (Jun 24, 2008)

Bifurcator said:


> *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 (Jun 24, 2008)

*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 (Jun 24, 2008)

Bifurcator said:


> 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 (Jun 24, 2008)

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 (Jun 24, 2008)

Moglex said:


> 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 (Jun 25, 2008)

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.


----------



## Bifurcator (Jun 25, 2008)

*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 (Jun 25, 2008)

Garbz said:


> 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 (Jun 25, 2008)

Bifurcator said:


> 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 (Jun 25, 2008)

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 (Jun 25, 2008)

Moglex said:


> 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 (Jun 25, 2008)

Bifurcator said:


> 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 (Jun 25, 2008)

Helen B said:


> 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 (Jun 25, 2008)

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 (Jun 26, 2008)

Garbz said:


> 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 (Jun 26, 2008)

Moglex said:


> 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 (Jun 26, 2008)

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 (Jun 26, 2008)

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 (Jun 26, 2008)

Helen B said:


> 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 (Jun 26, 2008)

Helen B said:


> 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 (Jun 26, 2008)

Bifurcator said:


> @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.


----------



## Moglex (Jun 26, 2008)

TamiyaGuy said:


> 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 (Jun 26, 2008)

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 (Jun 26, 2008)

Garbz said:


> 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 (Jun 26, 2008)

Moglex said:


> 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 (Jun 26, 2008)

TamiyaGuy said:


> 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 (Jun 26, 2008)

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


----------



## BoblyBill (Jun 26, 2008)

Mav said:


> 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 (Jun 26, 2008)

Bifurcator said:


> 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 (Jun 26, 2008)

Mav said:


> 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 (Jun 26, 2008)

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 (Jun 27, 2008)

Helen B said:


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



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 (Jun 27, 2008)

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 (Jun 27, 2008)

Helen B said:


> 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.
> ...



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 (Jun 27, 2008)

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 (Jun 27, 2008)

Helen B said:


> _"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.


----------



## Helen B (Jun 27, 2008)

Moglex said:


> ...
> 
> LOL.
> 
> ...



I'm beginning to find your condescension egregious, and it does not encourage intelligent discussion. In this case you have completely misunderstood the question. I asked what colour model you think is used. '_The full colour image_' is not a description of a colour model. I was expecting a description such as Lab, CMYK, RGB etc. I merely wanted to more fully understand your overall concept of the extent of the information passed from the application to the printer/printer driver - including the way in which colour is defined. I now have the impression that you do not know what a colour model is. I'm sure that you will want to correct my impression.

Best,
Helen


----------



## Moglex (Jun 27, 2008)

Helen B said:


> I'm beginning to find your condescension egregious, and it does not encourage intelligent discussion.


I wan't being condescending and I wasn't laughing at *you*.

What amused me was that in nearly two decades of using the term 'bitmap' I'd never noticed it was actually (at least in terms of how it was originally coined), a misnomer.



> In this case you have completely misunderstood the question. I asked what colour model you think is used.



Ooops!

I'm sorry, I misread colour model as colour (new specs arivving next week, really!).

I actually know (rather than think) that the colour model is RGB.

And no, I'm not disputing that the printer/driver will need to map the RGB values into something suitable for controling the proportions of the inks it happens to be using.


Now, is there any chance that you can tell me about this alternate method of getting bitmaps (or bitmapped images generally) from an application to the PAD (Printer And Driver).

You stated the fact with absolute certainty and I'm all agog.


----------



## Joves (Jun 27, 2008)

I love reading these little debates. :lmao:


----------



## danjchau (Jun 28, 2008)

_------------- 			_


----------



## TamiyaGuy (Jun 28, 2008)

Moglex said:


> 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*).


Ah, that's where I got my rant from. You're absolutely right, all other things being equal, more megapixels means better quality prints, crisper images, more cropping allowed, etc. Whether or not you'll be able to see those improvements in your average 6x4 remains to be seen, but whatever. I do agree with that.

The thing is, it is never equal. When you cram more things into a smaller space, quality is bound to deteriorate. It's just a general law (with exceptions, of course ). So in some cases, 6mp can actually out-perform 10mp. Yet camera salesmen constantly bang on about how having more megapixels can, nay, WILL get you better prints and somehow make you a better photographer, which is probably why I get so mad at them .


----------



## Moglex (Jun 28, 2008)

TamiyaGuy said:


> The thing is, it is never equal. When you cram more things into a smaller space, quality is bound to deteriorate. It's just a general law (with exceptions, of course ). So in some cases, 6mp can actually out-perform 10mp. Yet camera salesmen constantly bang on about how having more megapixels can, nay, WILL get you better prints and somehow make you a better photographer, which is probably why I get so mad at them .



Indeed.

It may well be that you'll get a better resolution (let alone other considerations) by spending money on a better lens rather than more megapixels.

Unfortunately it seems that megapixels is the 'headline figure' for digital cameras.

Rather in the way that first frequency response, then distortion, then power output were the headline figures for hi fi amps at various times.

It's a pity people don't generally take a more 'holistic' appraoch.


----------



## danjchau (Jun 28, 2008)

_------------- 			_


----------

