Ad
Ad
Ad
Pages: « 1 ... 7 8 [9] 10 11 12 »   Bottom of Page
Print
Author Topic: Clarification on Print Resolution  (Read 62859 times)
BartvanderWolf
Sr. Member
****
Offline Offline

Posts: 3907


« Reply #160 on: June 22, 2011, 11:22:23 AM »
ReplyReply

I've used QImage for years on the Hp and it does indeed to an excellent job, especially when upsampling for very large prints from dslr files, as in sending them to the printer at 150 ppi.

I'm wondering if anyone knows exactly what is going on with the Canon IPF plug-in? It seems to be doing something similar for file optimization and also has a slider for output sharpening adjustments that can be changed for various media.

Hi John,

Are you using any other settings than the ones on the Main tab of the print output plugin (as shown here)?

Cheers,
Bart
Logged
John R Smith
Sr. Member
****
Offline Offline

Posts: 1357


Still crazy, after all these years


« Reply #161 on: June 22, 2011, 12:03:10 PM »
ReplyReply

That's why I have a bit of a problem with drawing conclusions based on Lightroom output. LR also does it's thing, and doesn't offer enough control to set an exact input PPI, or so it seems. That's fine for regular use (for which it is intended), but not optimal for testing. A test from e.g. Photoshop probably offers more control.

Bart, the procedure that Shane described should have given him exactly 720 ppi for the input. And I can get the file to exactly 720 ppi also, using the cell size I posted earlier. I think the results he has are genuine, and are not influenced adversely by using LR in this particular instance. If that "Finest Detail" box was a 720/360 switch, he would have seen a difference in the 720 line thickness in column D of the restest printout with the box checked/not checked, there is just no way of avoiding that even if the file size had been 2 or 3 ppi off. This surprises me as much as it does you, but I have to say it looks as if Jeff and Mark are correct on this one, and that "Finest Detail" does something to the dither but not the ppi. On the 4900, at any rate.

John
« Last Edit: June 22, 2011, 12:11:35 PM by John R Smith » Logged

Hasselblad 500 C/M, SWC and CFV-39 DB
and a case full of (very old) lenses and other bits
Schewe
Sr. Member
****
Online Online

Posts: 5542


WWW
« Reply #162 on: June 22, 2011, 12:47:38 PM »
ReplyReply

So, unless the printer manufacturers can point out any drawback for this safe practice of requested resampling and sharpening before sending to the printer(driver), it would seem a logical move for the software developers to optimize the workflow and quality at their end, based on what the printer driver reports to expect.

There are a few potential drawbacks. I just talked to a friend at Epson and he indicated that if you are going to go to the trouble of upsampling to 720 and using the Finest Detail that the spool file will grow large (particularly if you are printing a file that is large to start with) and depending on the way the printer is connected; if over a network there could be problems or slow downs. If the network is fast and doesn't have a lot of other traffic and you don't hear the printer pausing then no problems, it's just taking more time.

The other thing he mentioned is that when printing at 720 with Finest Detail you should make sure the print head has been aligned on the exact media you'll be printing to and that you'll need to use a uni-directional setting not bi-directional. The spray alignment for bi-directional can cause problems when the second path of the head is also printing. This can be an issue because the printer will be 1/2 the speed. So you'll be sending more data and half the speed and the whole process will be less efficient. That would be an issue in a production environment.

As far as the question of whether or not the print driver is doing resampling or if it's the OS print pipeline, he reiterated that the print driver itself doesn't do resampling and the sieve analogy is indeed accurate. He's pretty sure it's the OS print pipeline that is doing the resampling and the nature of the resampling algorithm is unknown. But the odds of it being a really optimized resampling isn't high. The guess is either a bi-linear or nearest neighbor just from the standpoint of speed. I know a few people at Apple and MSFT but I don't know specifically whom to ask and I'm not sure Apple would even answer the question...

But The Epson guy agreed that sending the image data at the resolution the printer is expecting should take the print pipeline out of the equation.
Logged
BartvanderWolf
Sr. Member
****
Offline Offline

Posts: 3907


« Reply #163 on: June 22, 2011, 01:42:37 PM »
ReplyReply

There are a few potential drawbacks. I just talked to a friend at Epson and he indicated that if you are going to go to the trouble of upsampling to 720 and using the Finest Detail that the spool file will grow large (particularly if you are printing a file that is large to start with) and depending on the way the printer is connected; if over a network there could be problems or slow downs. If the network is fast and doesn't have a lot of other traffic and you don't hear the printer pausing then no problems, it's just taking more time.

Indeed, there is no free lunch, one either goes for optimal quality or better speed. In a production environment that latter is probably the more economical chioce.

Quote
The other thing he mentioned is that when printing at 720 with Finest Detail you should make sure the print head has been aligned on the exact media you'll be printing to and that you'll need to use a uni-directional setting not bi-directional. The spray alignment for bi-directional can cause problems when the second path of the head is also printing. This can be an issue because the printer will be 1/2 the speed. So you'll be sending more data and half the speed and the whole process will be less efficient. That would be an issue in a production environment.

Yes, Uni-directional and well aligned for the medium will help. Speed will suffer, unless one was already printing uni-directional.

Quote
As far as the question of whether or not the print driver is doing resampling or if it's the OS print pipeline, he reiterated that the print driver itself doesn't do resampling and the sieve analogy is indeed accurate. He's pretty sure it's the OS print pipeline that is doing the resampling and the nature of the resampling algorithm is unknown. But the odds of it being a really optimized resampling isn't high. The guess is either a bi-linear or nearest neighbor just from the standpoint of speed. I know a few people at Apple and MSFT but I don't know specifically whom to ask and I'm not sure Apple would even answer the question...

I'm not sure if your liason is a software or hardware guy, but there is also the posibility that the printer firmware (instead of the driver) does some of the processing. Firmware, or ASICs, are faster than software but less flexible. Maybe they moved some of the logic to the printer hardware for speed gain purposes. It seems unlikely to me that the OS meddles with the print data, but stranger things have happened. I'm assuming from his reaction that he also recognizes that aliasing is involved somewhere (because of the aliasing artifacts), so that source would still need to be identified for an explanation of the observations.

Quote
But The Epson guy agreed that sending the image data at the resolution the printer is expecting should take the print pipeline out of the equation.

That's a good observation to take away from the discussion sofar, assuming that the OS doesn't interfere. We can control the preparation part of the workflow to our heart's content and deliver it resampled and sharpened, ready for print at the requested PPI, thus bypassing as many variables as possible. One can alway deliberately choose for 360 PPI as a trade-off if speed is a concern.

Cheers,
Bart
Logged
hjulenissen
Sr. Member
****
Offline Offline

Posts: 1713


« Reply #164 on: June 22, 2011, 01:55:16 PM »
ReplyReply

It seems unlikely to me that the OS meddles with the print data, but stranger things have happened.
This analogy might seem far-out, but if you want to play a CD on your Windows PC, without Windows altering any bits, this could be quite cumbersome. Thing is, Microsoft had a mixer subsystem that did (low-quality) sample rate conversion in software in order to make it easier for multiple applications to access the system, and to be able to interface to various soundcards.

This just goes to show that consumer OS-er are made for the normal people that just want sound or printing to work, at a low prize. For nerds that will go to any length for even the most minimal improvement, they will often have to.... go to great lengths :-)

-h
Logged
Schewe
Sr. Member
****
Online Online

Posts: 5542


WWW
« Reply #165 on: June 22, 2011, 02:18:57 PM »
ReplyReply

It seems unlikely to me that the OS meddles with the print data, but stranger things have happened.

Well, if the OS isn't doing the resampling, why would the OS need the device to report it's resolution? Both the Epson guy and one of the Photoshop engineers are thinking it's the OS print pipeline that is doing the resampling to send the image data at the resolution asked for by the printer.

As far as the OS "meddling"' with the print data, well, we've all seen that before. Colorsync is noted for it's meddling ways. And while in general Windows tends to be far more hands off, print drivers are still at the mercy of the printing APIs.

I don't doubt that the printer's firmware is doing the heavy lifting of doing the dither using special purpose processing chips. But as I understand it (and re-confirmed during a phone call this AM) the Epson guys still maintains that the print driver and printer aren't doing the resampling just doing the dithering.

Unless and until we can confirm with Apple or MSFT, I'm sticking with the OS being the resampler and avoiding the issue by doing the resampling in Lightroom.
Logged
John R Smith
Sr. Member
****
Offline Offline

Posts: 1357


Still crazy, after all these years


« Reply #166 on: June 22, 2011, 02:24:52 PM »
ReplyReply

Jeff

The people who must know, of course, and who are not involved here, are the engineers who write RIPs.

John
Logged

Hasselblad 500 C/M, SWC and CFV-39 DB
and a case full of (very old) lenses and other bits
Schewe
Sr. Member
****
Online Online

Posts: 5542


WWW
« Reply #167 on: June 22, 2011, 02:29:14 PM »
ReplyReply

The people who must know, of course, and who are not involved here, are the engineers who write RIPs.

Not necessarily...RIPS that work on Epson printers generally bypass the system APIs and have direct print head control. ImagePrint does that by completely bypassing the application, the OS print pipeline and sends it's own dither to the print head.

No, the ones that really know are the engineers at Apple and MSFT that are developing the print pipeline APIs. And I don't know any of them...
 
Logged
John R Smith
Sr. Member
****
Offline Offline

Posts: 1357


Still crazy, after all these years


« Reply #168 on: June 22, 2011, 02:31:27 PM »
ReplyReply

No, the ones that really know are the engineers at Apple and MSFT that are developing the print pipeline APIs. And I don't know any of them...

Dammit, Jeff, why not?  Wink

We need you to broaden your social horizons . . .

John
« Last Edit: June 22, 2011, 02:33:15 PM by John R Smith » Logged

Hasselblad 500 C/M, SWC and CFV-39 DB
and a case full of (very old) lenses and other bits
deanwork
Sr. Member
****
Offline Offline

Posts: 752


« Reply #169 on: June 22, 2011, 02:57:09 PM »
ReplyReply

Well one. On that Lexjet video they don't mention the Advanced printing menu where you can select Unidirectional. I always set it at Uni if I'm doing small prints or if time is not a factor for me for larger things.  As for the output sharpening I haven't done tests with it yet and I'm curious to see if it matches QImage. I haven't set up QImage on the Canon. There are too many damn tests to do in this world when things are looking so good out of the box as they are.

john






Hi John,

Are you using any other settings than the ones on the Main tab of the print output plugin (as shown here)?

Cheers,
Bart
Logged
BartvanderWolf
Sr. Member
****
Offline Offline

Posts: 3907


« Reply #170 on: June 22, 2011, 03:44:40 PM »
ReplyReply

Well one. On that Lexjet video they don't mention the Advanced printing menu where you can select Unidirectional. I always set it at Uni if I'm doing small prints or if time is not a factor for me for larger things.

Okay, setting it to uni-directional makes sense to avoid the mechanical tolerances. One of those variables one would like to avoid when the magnitude is unknown. According to Canon Techsupport (as mentioned in the Canon IPF Wikispace) "... , the main difference is that there will be a different "angle" or "lean" to the droplets depending which was the head was moving, and that in some cases the reflectivity may vary enough from this to be perceived as banding". Do note that that was in relation to the IPF5000 model, newer ones may have solved that with the newer ink formulations for the x300 series. Again, it's better to be safe than sorry, unless time is at a premium.

Quote
As for the output sharpening I haven't done tests with it yet and I'm curious to see if it matches QImage. I haven't set up QImage on the Canon. There are too many damn tests to do in this world when things are looking so good out of the box as they are.

I agree, but for the best quality one needs to suffer a bit, apparently. Anyway, Qimage remembers the printer driver settings per type of paper or job used, so the learning curve is short and the reward is sweet ...

Cheers,
Bart
Logged
Ernst Dinkla
Sr. Member
****
Offline Offline

Posts: 2910


« Reply #171 on: June 23, 2011, 10:04:59 AM »
ReplyReply

This day I had some time to test further. I could use a friend's R2880 and R3880 driven by a Mac and printing from Photoshop CS5 but due to some limitations, he uses the 2880 for gloss and the 3880 for matte, so I did not want to switch between extreme print qualities related to those choices and the results were not convincing. Add to that my clumsiness on the Mac. It could even be that PS CS5 or OS-X interferes more. I see some moiré when the target is twice the resolution of the requested input resolution 1440 to 720 PPI, 720 to 360 PPI, but not the shift to complete black or white or huge blocking to B&W.  I had Adobe Color Printer Utility for Mac there too but ran into a problem with its image sizing, a flaw already reported on its normal use for printing profiling targets. Too little time to cope with that on the Mac. All in all not a convincing test method and test result.

At home I tried the things I have done with the HP Z3100 and Qimage some years ago but this time with an office printer HP K5400 as it works faster with individual sheets. Printing from ACPU and Photoshop CS4 on a Windows Vista 64 system. The printer knows roughly 3 print quality grades: 300 PPI input, 600 PPI input, 1200 PPI input (one photo paper only). With Photoshop feeding line targets of 600 PPI, 1200 PPI, 2400 PPI respectively (last two sized to 50%, 25%) I loose the complete top field of column A, the rectangle becomes white. Feeding a line target 1200 PPI to the printer asking 1200 PPI input gives a dark grey rectangle, lines bleed completely to one another but no resampling happening if I check the top field in column D, so a genuine 1200 PPI input request.
With ACPU I get blocks in B&W in the A column top field and more. Problem with ACPU is that it resizes the original size so I have to measure the print and resize (without resampling) in Photoshop to get the exact print size of the original target tiff. Could be that a more precise printed target will also have a white or black rectangle there instead of B&W blocks. Sizing factor to be used in PS is somewhere between 1.037 to 1.042. But aliasing happens heavily with any print close enough. I would not expect any sophisticated downsampling/anti-aliasing in ACPU as it is intended for simple profile target printing at 1:1 or let us say sort of 1:1 :-)

In short resampling to 300, 600 and 1200 PPI happens somewhere en route and no anti-aliasing is done to overcome heavy aliasing/moiré in both PS CS4 and ACPU on Windows Vista 64.

Will test the Z3200 and Z3100 (again) to see whether something has changed between the two models/firmware/drivers but the Z3100 behaved very similar to the K5400 when Qimage was used with all its resampling off, running on Windows XP 32.
Edit: tested them too from Qimage running on Vista 64 and all extrapolation + sharpening OFF on Qimage, the Z3100 behaved like the K5400:  300, 600, 1200 PPI rendering resolutions. The Z3200 has 300 and 600 PPI as rendering resolutions. The Z3200 printed a better 600 PPI target at 600 PPI than the Z3100 at both 600 and 1200 PPI rendering resolutions. The resolution on both printers is better at the head travel direction than at the media trans[port direction, more or less predictable. Second Edit: The most recent Z3100 firmware and/or driver has just 300 and 600 PPI rendering resolution. 1200 PPI is no longer there.

The targets are from ddisoftware and placed there and/or created by Mike Chaney. Do not give them my name, I only gave the link to them.

met vriendelijke groeten, Ernst

New: Spectral plots of +250 inkjet papers:

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
« Last Edit: June 30, 2011, 07:39:20 AM by Ernst Dinkla » Logged
Ernst Dinkla
Sr. Member
****
Offline Offline

Posts: 2910


« Reply #172 on: June 23, 2011, 10:17:27 AM »
ReplyReply

Not necessarily...RIPS that work on Epson printers generally bypass the system APIs and have direct print head control. ImagePrint does that by completely bypassing the application, the OS print pipeline and sends it's own dither to the print head.

No, the ones that really know are the engineers at Apple and MSFT that are developing the print pipeline APIs. And I don't know any of them...
 

And do not underestimate the knowledge of the developers that made GimpPrint > GutenPrint for more OS systems. When in doubt Robert Krawitz often had an answer.


met vriendelijke groeten, Ernst
New: Spectral plots of +250 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm



Logged
John R Smith
Sr. Member
****
Offline Offline

Posts: 1357


Still crazy, after all these years


« Reply #173 on: June 23, 2011, 10:24:23 AM »
ReplyReply

Thanks for that update, Ernst. I have some more results coming shortly using LR with real photographs rather than a test target, this time.

John
Logged

Hasselblad 500 C/M, SWC and CFV-39 DB
and a case full of (very old) lenses and other bits
Ernst Dinkla
Sr. Member
****
Offline Offline

Posts: 2910


« Reply #174 on: June 23, 2011, 10:38:49 AM »
ReplyReply


What is clear is that with regards to Lightroom and Epson pro printers, doing the upsampling to 360/720 (depending on the native resolution of the file) and then choosing the correct driver settings (Finest Detail off if upsampling to 360 from below 360 native rez and Finest Detail on if upsampling to 720) will produce the finest image detail in the print.


Jeff,

I think there are cases where data with less that 360 PPI at print size and resampled to 360 PPI will deliver a lower "general" image quality if the same paper/printer can deliver better image quality with enough data available. Detail is one thing, smoothness of gradients is another thing. If the paper/printer combination can not deliver a better quality with data above 360 PPI at print size then two conditions are met to set the limit at 360 PPI input.

met vriendelijke groeten, Ernst
New: Spectral plots of +250 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm



Logged
Ernst Dinkla
Sr. Member
****
Offline Offline

Posts: 2910


« Reply #175 on: June 23, 2011, 10:54:57 AM »
ReplyReply


It's not the only thing it does? Sofar, nobody has come forward with any kind of proof for such a hypothesis.
Of course straight lines are not the only or best test. That's why I suggested the use of a zoneplate target earlier in the thread (I also mentioned to convert the GIF from indexed to RGB mode to avoid artifacts from Photoshop's faulty resampling). Such a target has no bi-tonal black and white pattern, but rather an approximation of a sinusoidal pattern of gray tints with all possible spatial frequencies, and at all possible angles. It is also very sensitive to aliasing artifacts, so it becomes easy to differentiate between good and bad driver implementations. It's also likely to show if there is more going on than just enabling 720 PPI input (or resampling input to 720 PPI where needed).d.

Cheers,
Bart

Bart,

For testing image quality to the eye and a loupe with different workflow/paper/printer/print quality settings your zoneplate target is way better. To get a clear answer on the resampling question I preferred the simple line targets.

met vriendelijke groeten, Ernst
New: Spectral plots of +250 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm

Logged
Ernst Dinkla
Sr. Member
****
Offline Offline

Posts: 2910


« Reply #176 on: June 23, 2011, 12:22:19 PM »
ReplyReply


I'm not sure if your liason is a software or hardware guy, but there is also the posibility that the printer firmware (instead of the driver) does some of the processing. Firmware, or ASICs, are faster than software but less flexible. Maybe they moved some of the logic to the printer hardware for speed gain purposes. It seems unlikely to me that the OS meddles with the print data, but stranger things have happened. I'm assuming from his reaction that he also recognizes that aliasing is involved somewhere (because of the aliasing artifacts), so that source would still need to be identified for an explanation of the observations.

Cheers,
Bart

Printers taking part in the preparation of print data is more likely to happen on wide to medium format pro models than on (consumer) A3+ desktop models. The last seem to depend on 720 PPI input as a normal condition while the pro models most of the time use 360 PPI input if this thread delivered the right information. Computing a 1/16 or 1/8 square meter of printer data is of course demanding less of system power than one square meter of data. Laying down 720 PPI information on a 112 cm wide paper roll asks more of the hardware components addressing and of climate control. Translating 720 PPI information to 2 picoliter droplets (that are harder to place than 5 picoliter droplets) is not a optimal choice for production wide formats and would increase processing and printing time while hardware and climate control set a limit anyway on real optical resolution. So the pro models may do more in the printer itself, the desktop models may need the same work done but delegate it to the computer system. It would be interesting to see the information density that goes to a desktop inkjet head and a pro inkjet head.


met vriendelijke groeten, Ernst
New: Spectral plots of +250 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm

« Last Edit: June 23, 2011, 12:25:42 PM by Ernst Dinkla » Logged
John R Smith
Sr. Member
****
Offline Offline

Posts: 1357


Still crazy, after all these years


« Reply #177 on: June 23, 2011, 02:38:18 PM »
ReplyReply

I expect that most of the Forum readership is now beyond bored with this epic thread, but for the sake of completeness here are the latest results from Smith Labs. If you print from Lightroom to an Epson printer, they could be of interest. I have not solved the mystery of whether the OS or the Epson print driver resamples incoming data or not, but I have found out a bit more about what LR is doing. As before, my output was from Lightroom 3.4.1, running on Win 7 64-bit, and printing to my Epson R2400. The 2400 was set to its best output resolution, Photo RPM (5760 x 1440), High Speed off, and the paper was Epson Premium Glossy. LR Output Sharpening was off. My test files were 39MP Hasselblad 3FR raw files, and the specific file I used for this test is attached at the bottom of the post just for reference – this VW Campers pic is an old warhorse, but I use it because it is of good quality, well-focused and has no camera shake. I used just a section of the picture from the left of the frame, the cups on the table.

I decided to print my test only at exact divisions of the maximum 720 ppi input for the Epson, so I used 180, 360 and 720 ppi, in order to eliminate any re-sampling artefacts which might be introduced by the OS or the Epson Driver (if they do in fact resample). I started out by cropping a section of the image and sized it in the LR print module to exactly 360 ppi, fitting nicely on one third of an A5 sheet (so that I could print three tests side-by-side for comparison). This represents a section from a 20x15 print of the full-frame image. I printed it first to the 2400 directly at 360, and then tried resampling it to 720 ppi. The second  result was obviously better even to the naked eye, with crisper definition and more detail on the pattern on the cups, crisper text on the tablecloth and an overall better internal contrast, particularly in the half-shadow areas. But why? No extra detail has actually been added, of course – the detail in the file is exactly the same, but you would swear it had been enhanced. At first I thought that perhaps the uprezzing routine was invoking an enhanced dither pattern in the print driver, but the dot density seemed the same under the 8x loupe. So I decided to go BIG, in order to get a closer look at what was going on.

This time I cropped a section of just the cups to 180 ppi and ran the test again – firstly a straight output at 180, then upsampled to 360 and also 720 ppi. This time I could see that LR is in fact not just resampling but running a very sophisticated anti-aliasing and smoothing routine on the image data into the bargain. It’s good at 360, and actually slightly better again at 720. And that’s why the “Schewe Rule” works. Have a look at the two files attached below – these are scans from the test prints, a section of the saucer rim on the right-hand cup. The first is the straight print at 180 ppi, the second has been resampled by LR to 720 ppi. Both are the same size in print, of course. You should be able to see how LR has smoothed the saucer rim.

Conclusions? Or perhaps a summary for Mike . . .

• We are talking about striving for the very finest prints here, squeezing the last little drop of quality out. Many people would never notice the difference – the current printers are so good, that almost any settings produce very acceptable output.

• For the best quality, set your print driver to either 5760x1440 (for the desktops) or 2880x1440 (for the Stylus Pro range). On the SP printers checking the Finest Detail box to on may give you a touch more definition in grass, hair, and fine lines. Make sure High-Speed or Bi-Directional printing is off.

• If your image sizes to less than 180 ppi in the LR Print Module for your selected paper size, you are trying to print it too large – but you may still get a reasonable result. A purpose-built uprezzing package might do better.

• From 180 ppi upwards to (presumably) 719 ppi, you will get the very best results by resampling the file in LR to 720 ppi. Between 180 and 359, you can resample to 360 to save time and spool file size, and get almost as good a result, but 720 is the business. What happens is that of course no extra detail can be added, but LR not only resamples but uses a very clever anti-aliasing and smoothing routine on the image, which enhances the apparent detail and resolution.

• This does not happen when LR is downsampling (as from 741 to 720 ppi). The image is not smoothed and no anti-aliasing is applied, so you should avoid this situation. The print quality suffers as a result (although it takes a loupe to see it). Unfortunately, with 60MP and now 80MP backs (and probably 100MP+ before too long) this is going to be of increasing concern for small prints.

• Strangely, the absolute worst thing you can do is to resample the image in LR to the same value as reported for the cell size – for example, take a 360 ppi image resolution and then set the LR output resolution to 360 as well. Theoretically, it should make no difference – but the quality of the print is degraded compared with simply sending it to the printer with no LR resampling. I can’t explain why this happens, but it is observable and repeatable. I can also see the same result with the Restest file – comparing output direct at 720 with the same file output with the LR Resolution box also set to 720 ppi (the sample text is degraded).

• Setting the LR output sharpening to “Standard” with the correct paper type will give the print a little bit of “snap” without introducing any artefacts or halos. It’s not a huge difference with my 3FR files, just nice and subtle.

That’s my conclusions for tonight, at any rate. You are now invited to weigh in and prove me wrong  Wink

John
Logged

Hasselblad 500 C/M, SWC and CFV-39 DB
and a case full of (very old) lenses and other bits
digitaldog
Sr. Member
****
Offline Offline

Posts: 9315



WWW
« Reply #178 on: June 23, 2011, 02:47:06 PM »
ReplyReply

That’s my conclusions for tonight, at any rate. You are now invited to weigh in and prove me wrong  Wink

Thanks for the work and reporting. I think unless told otherwise, your conclusions are nicely laid out and easy to comprehend.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mike Guilbault
Sr. Member
****
Offline Offline

Posts: 840



WWW
« Reply #179 on: June 23, 2011, 03:31:36 PM »
ReplyReply

Yes, thanks John for the 'summary'.  I like those! 

I just printed an image that natively came down to about 121 ppi after some cropping and wanting to print at about 36" wide.  I set the Printer Resolution to 360 and it came out beautifully at a 'normal' viewing distance - at least to my eyes.  I'm happy.
Logged

Pages: « 1 ... 7 8 [9] 10 11 12 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad