I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a 8 by 10 sheet using PMview fit the page print option. Tame/2 successfully created the 5360 by 4880 pixel tiff file and Pmview imported it fine. But when it came time to print, PMview would not successfully create a print job. It would get about half way through the creation and then hang for a few minutes and then close the job, which the spooler immediately deleted as malformed. The only way I could get PMview to print the image was to first reduce the image down to a 1200 by 1600 image and then print that. To say that I am disappointed would be an understatement, to lose the detail that was captured in the scan.
Well, I went to the evil empire machine to see what it could do. Not to my surprise, it failed also. So are we to consider scanning photos in at high resolution a waste of time? Has anyone found a different solution? Faxview did not display the image after scanning, so I did not try printing from it. -- Bill Thanks a Million!
Allodoxaphobia 1 February 2005 21:07:43 [ permanent link ]
On Tue, 01 Feb 2005 10:14:29 -0600, William L. Hartzell wrote:> Sir:>
I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution > of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a > 8 by 10 sheet using PMview fit the page print option. Tame/2 > successfully created the 5360 by 4880 pixel tiff file and Pmview > imported it fine. But when it came time to print, PMview would not > successfully create a print job. It would get about half way through > the creation and then hang for a few minutes and then close the job, > which the spooler immediately deleted as malformed. The only way I > could get PMview to print the image was to first reduce the image down > to a 1200 by 1600 image and then print that. To say that I am > disappointed would be an understatement, to lose the detail that was > captured in the scan.>
Well, I went to the evil empire machine to see what it could do. Not to > my surprise, it failed also. So are we to consider scanning photos in > at high resolution a waste of time? Has anyone found a different > solution? Faxview did not display the image after scanning, so I did > not try printing from it.
At what DPI are you printing it at? On a 300 DPI HP LJ III, that sucker would be 17.9" wide. At 600 DPI, it would, I guess, be close to an 8.5" wide 'standard' sheet of paper.
But, does your (unidentified) printer have the memory to receive an image that huge?
Jonesy -- | Marvin L Jones | jonz | W3DHJ | linux | Gunnison, Colorado | @ | Jonesy | OS/2 __ | 7,703' -- 2,345m | config.com | DM68mn SK
Bart Bremmers 2 February 2005 00:19:21 [ permanent link ]
I think you've run into a memory problem. Printer resolutions (i.e. 600 dpi, 1200 dpi) should not be confused with scanning resolution.
A 5 x 7 can be scanned at 200 for normally acceptable results. 300 would be the highest I would go. I regularly use 200 or 300 for image creation and scanning.
HTH
--
========================= Bart Bremmers, Gen. Mgr. Craft-Bilt Materials Ltd. Markham, Ontario
On Tue, 1 Feb 2005 17:07:43 UTC, Allodoxaphobia <bit-bucket@config.com> wrote:
I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution > > of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a > > 8 by 10 sheet using PMview fit the page print option.
Note the end of that last sentence.
Tame/2 > > successfully created the 5360 by 4880 pixel tiff file and Pmview > > imported it fine. But when it came time to print, PMview would not > > successfully create a print job. It would get about half way through > > the creation and then hang for a few minutes and then close the job, > > which the spooler immediately deleted as malformed. The only way I > > could get PMview to print the image was to first reduce the image down > > to a 1200 by 1600 image and then print that.
At what DPI are you printing it at?> On a 300 DPI HP LJ III, that sucker would be 17.9" wide.
PMView is supposed to scale the output to the selected page, which it usually does quite well. It is dying instead; this should probably be handled more gracefully ("Out of memory", "Image too large to scale to printer", something like that). Ask Peter. Post the testcase scan somewhere, if possible. It's probably reproduceable on other systems, with the variable of the printer driver.
-- Regards, Al S.
This OS/2 system ("Tori", W4 FP17) uptime is 5 days 00:44 hours
On Tue, 1 Feb 2005 16:14:29 UTC, "William L. Hartzell" <wlhartzell@comcast.net> wrote:
Sir:>
I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution > of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a > 8 by 10 sheet using PMview fit the page print option. Tame/2 > successfully created the 5360 by 4880 pixel tiff file and Pmview > imported it fine. But when it came time to print, PMview would not > successfully create a print job. It would get about half way through > the creation and then hang for a few minutes and then close the job, > which the spooler immediately deleted as malformed. The only way I > could get PMview to print the image was to first reduce the image down > to a 1200 by 1600 image and then print that.
File size is too large . . . Try scanning at 600 dpi and using png format.
James J. Weinkam 2 February 2005 09:32:14 [ permanent link ]
Allodoxaphobia wrote:> On Tue, 01 Feb 2005 10:14:29 -0600, William L. Hartzell wrote:>
Sir:>>
I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution >>of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a >>8 by 10 sheet using PMview fit the page print option. Tame/2 >>successfully created the 5360 by 4880 pixel tiff file and Pmview >>imported it fine. But when it came time to print, PMview would not >>successfully create a print job. It would get about half way through >>the creation and then hang for a few minutes and then close the job, >>which the spooler immediately deleted as malformed. The only way I >>could get PMview to print the image was to first reduce the image down >>to a 1200 by 1600 image and then print that. To say that I am >>disappointed would be an understatement, to lose the detail that was >>captured in the scan.>>
Well, I went to the evil empire machine to see what it could do. Not to >>my surprise, it failed also. So are we to consider scanning photos in >>at high resolution a waste of time? Has anyone found a different >>solution? Faxview did not display the image after scanning, so I did >>not try printing from it.>
At what DPI are you printing it at?> On a 300 DPI HP LJ III, that sucker would be 17.9" wide.> At 600 DPI, it would, I guess, be close to an 8.5" wide 'standard'> sheet of paper.>
But, does your (unidentified) printer have the memory to receive> an image that huge?>
Is the OP perhaps running out of space on the SPOOL drive? After all the job never got as far as the printer.
Harald Pollack 2 February 2005 11:59:28 [ permanent link ]
Servus William!
From: "William L. Hartzell" <wlhartzell@comcast.net>
I scanned into my computer a 3 by 5 picture using Tame/2 WLH> at a resolution of 1200 dpi. My thinking was that I print this picture WLH> at 1200 dpi on a 8 by 10 sheet using PMview fit the page print option.
Without reading any more, I will assume, that action failed...
Tame/2 successfully created the 5360 by 4880 pixel tiff file and WLH> Pmview imported it fine. But when it came time to print, PMview WLH> would not successfully create a print job. It would get about half WLH> way through the creation and then hang for a few minutes and then WLH> close the job, which the spooler immediately deleted as malformed.
Yes. This is the result, we can see with every (?) application in conjunction with the image dimensions you have reported.
The only way I could get PMview to print the image was to first reduce WLH> the image down to a 1200 by 1600 image and then print that. To say that WLH> I am disappointed would be an understatement, to lose the detail that WLH> was captured in the scan.
Do not blame PMview, I think (and know) that FaxView also will give up
So are we to consider scanning photos in at high resolution a waste of WLH> time?
It is not a resolution problem! It is a problem of (shared) memory needed for such a large image!!!
Has anyone found a different solution?
Not yet (except to split the image in smaler, printable parts).
Faxview did not display the image after scanning,
Please start FaxView with '-errorlog 2>error.log' and send the resulting error log file to me.
so I did not try printing from it.
because it is a problem of PM, FaxView will also fail...
Normally, the failing Gpi.. function returns PMERR_INV_HPS (0x207F) in WinGetLastError(). This is in fact an overall nonsense and is obviously a (yet) unknown sideeffect when printing very large bitmaps. The exact limit is not (so easy) to calculate and is in the range of 95 - 120MB of the supplied image. The less physical RAM the larger the limit and vice versa (crazy).
If the large image is splitted (striped) into parts below the limit, than printing works well, so it is definitly a problem of the imagesize which is supplied to GpiDrawBits() or GpiWcBitBlt() etc.
Herzliche Gruesse, Harald
-+- Message created on Wednesday February, 02 2005 09:22:09 MEZ
William L. Hartzell 2 February 2005 12:12:39 [ permanent link ]
Sir:
Allodoxaphobia wrote:> On Tue, 01 Feb 2005 10:14:29 -0600, William L. Hartzell wrote:>
Sir:>>
I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution >>of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a >>8 by 10 sheet using PMview fit the page print option. Tame/2 >>successfully created the 5360 by 4880 pixel tiff file and Pmview >>imported it fine. But when it came time to print, PMview would not >>successfully create a print job. It would get about half way through >>the creation and then hang for a few minutes and then close the job, >>which the spooler immediately deleted as malformed. The only way I >>could get PMview to print the image was to first reduce the image down >>to a 1200 by 1600 image and then print that. To say that I am >>disappointed would be an understatement, to lose the detail that was >>captured in the scan.>>
Well, I went to the evil empire machine to see what it could do. Not to >>my surprise, it failed also. So are we to consider scanning photos in >>at high resolution a waste of time? Has anyone found a different >>solution? Faxview did not display the image after scanning, so I did >>not try printing from it.>
At what DPI are you printing it at?
1200 dpi> On a 300 DPI HP LJ III, that sucker would be 17.9" wide.> At 600 DPI, it would, I guess, be close to an 8.5" wide 'standard'> sheet of paper.>
But, does your (unidentified) printer have the memory to receive> an image that huge?
That is just it, the spooler only send parts of the image file to the printer as it is being printed. So the size of the print job is not important. This is not a postscript machine. The Lexmark Z51 printer prints at 1200 dpi. A print file at 1200 dpi is just as large without regard to the size of the input file.
The problem is not with the printer. It may be with the print driver, however.
William L. Hartzell 2 February 2005 12:22:15 [ permanent link ]
Sir:
James J. Weinkam wrote:> Allodoxaphobia wrote:>
On Tue, 01 Feb 2005 10:14:29 -0600, William L. Hartzell wrote:>>
Sir:>>>
I scanned into my computer a 3 by 5 picture using Tame/2 at a >>> resolution of 1200 dpi. My thinking was that I print this picture at >>> 1200 dpi on a 8 by 10 sheet using PMview fit the page print option. >>> Tame/2 successfully created the 5360 by 4880 pixel tiff file and >>> Pmview imported it fine. But when it came time to print, PMview >>> would not successfully create a print job. It would get about half >>> way through the creation and then hang for a few minutes and then >>> close the job, which the spooler immediately deleted as malformed. >>> The only way I could get PMview to print the image was to first >>> reduce the image down to a 1200 by 1600 image and then print that. >>> To say that I am disappointed would be an understatement, to lose the >>> detail that was captured in the scan.>>>
Well, I went to the evil empire machine to see what it could do. Not >>> to my surprise, it failed also. So are we to consider scanning >>> photos in at high resolution a waste of time? Has anyone found a >>> different solution? Faxview did not display the image after >>> scanning, so I did not try printing from it.>>
At what DPI are you printing it at?>> On a 300 DPI HP LJ III, that sucker would be 17.9" wide.>> At 600 DPI, it would, I guess, be close to an 8.5" wide 'standard'>> sheet of paper.>>
But, does your (unidentified) printer have the memory to receive>> an image that huge?>>
Is the OP perhaps running out of space on the SPOOL drive? After all > the job never got as far as the printer.
The spooler is on the data volume, which has several gigabytes of free space. The swapper is also on that volume. However, the print file is the same size, given that I've selected 1200 dpi output for both the high resolution input and the low resolution input. It is only failing on the high resolution input. It could be the print driver, seeing that the print driver is code that interprets the input to output matrix? This is a Lexmark Z51 printer. -- Bill Thanks a Million!
William L. Hartzell 2 February 2005 12:31:06 [ permanent link ]
Sir:
Bart Bremmers wrote:> I think you've run into a memory problem. Printer resolutions (i.e. 600 > dpi, 1200 dpi) should not be confused with scanning resolution.>
A 5 x 7 can be scanned at 200 for normally acceptable results. 300 would > be the highest I would go. I regularly use 200 or 300 for image creation > and scanning.>
Just because digital cameras are currently limited in the number of pixels that they can capture, does not mean that we should limit our scans to that resolution. Even at 1200 dpi scanned, one is not approaching the perceived resolution of a photograph. I pick 1200 dpi as that is the output resolution of my printer. If I had chosen to print the image at the same size as the input, it would have been a 3 by 5 image that would have been printed.
BTW, scanner resolution is the same as printer resolution. DPI is DPI. The device context does not change that. Or at least someone would have a very hard time convincing me otherwise. -- Bill Thanks a Million!
In <c1.2b5.2vQtzm$20n@12-237-213-129.client.comcast.net>, "William L. Hartzell" <wlhartzell@comcast.net> writes:>Sir:>
I scanned into my computer a 3 by 5 picture using Tame/2 at a resolution >of 1200 dpi. My thinking was that I print this picture at 1200 dpi on a >8 by 10 sheet using PMview fit the page print option. Tame/2 >successfully created the 5360 by 4880 pixel tiff file and Pmview >imported it fine. But when it came time to print, PMview would not >successfully create a print job. It would get about half way through >the creation and then hang for a few minutes and then close the job, >which the spooler immediately deleted as malformed. The only way I >could get PMview to print the image was to first reduce the image down >to a 1200 by 1600 image and then print that. To say that I am >disappointed would be an understatement, to lose the detail that was >captured in the scan.>
Well, I went to the evil empire machine to see what it could do. Not to >my surprise, it failed also. So are we to consider scanning photos in >at high resolution a waste of time? Has anyone found a different >solution? Faxview did not display the image after scanning, so I did >not try printing from it.
As a general rule you need RAM equal to 5 times the image size for editing and printing.
Specifically you need enough RAM for the image, the same for an undo copy, and the same for the print spool copy.
William L. Hartzell 2 February 2005 14:55:19 [ permanent link ]
Sir:
Harald Pollack wrote:> Servus William!>
From: "William L. Hartzell" <wlhartzell@comcast.net>>
I scanned into my computer a 3 by 5 picture using Tame/2 > WLH> at a resolution of 1200 dpi. My thinking was that I print this picture > WLH> at 1200 dpi on a 8 by 10 sheet using PMview fit the page print option. >
Without reading any more, I will assume, that action failed...>
Tame/2 successfully created the 5360 by 4880 pixel tiff file and > WLH> Pmview imported it fine. But when it came time to print, PMview > WLH> would not successfully create a print job. It would get about half > WLH> way through the creation and then hang for a few minutes and then > WLH> close the job, which the spooler immediately deleted as malformed.>
Yes. This is the result, we can see with every (?) application in conjunction> with the image dimensions you have reported.>
The only way I could get PMview to print the image was to first reduce > WLH> the image down to a 1200 by 1600 image and then print that. To say that> WLH> I am disappointed would be an understatement, to lose the detail that > WLH> was captured in the scan.>
Do not blame PMview, I think (and know) that FaxView also will give up >
So are we to consider scanning photos in at high resolution a waste of > WLH> time? >
It is not a resolution problem! It is a problem of (shared) memory needed for> such a large image!!!>
Has anyone found a different solution?>
Not yet (except to split the image in smaler, printable parts).>
Faxview did not display the image after scanning,>
Please start FaxView with '-errorlog 2>error.log' and send the resulting error> log file to me.
Will try this later today.> WLH> so I did not try printing from it.>
because it is a problem of PM, FaxView will also fail...>
Normally, the failing Gpi.. function returns PMERR_INV_HPS (0x207F) in> WinGetLastError(). This is in fact an overall nonsense and is obviously a (yet)> unknown sideeffect when printing very large bitmaps. The exact limit is not (so> easy) to calculate and is in the range of 95 - 120MB of the supplied image. The> less physical RAM the larger the limit and vice versa (crazy).>
If the large image is splitted (striped) into parts below the limit, than> printing works well, so it is definitly a problem of the imagesize which is> supplied to GpiDrawBits() or GpiWcBitBlt() etc.>
Since you are authoritative on this, are not these calls to Gpi done by the print driver and there is nothing you could do to fix this (using High shared memory)? I'll also try this from within my striped down copy of OS/2 to see if it has more shared memory available. -- Bill Thanks a Million!
William L. Hartzell wrote:> Since you are authoritative on this, are not these calls to Gpi done
the print driver and there is nothing you could do to fix this (using
High shared memory)? I'll also try this from within my striped down> copy of OS/2 to see if it has more shared memory available.
Bill,
PMView is using high memory all the way down to the GPI calls. The problem is within the print engine / printer driver that AFAIK does not use high memory. Because of this unfortunate fact, there is nothing the application can do. I'm also afraid that we can't even blame the writer of the printer driver as the problem problably really is with the memory handling of the print engine/spooler. It ought to use high memory, but doesn't. Maybe Harald has more to add to this?
Harald Pollack 3 February 2005 11:08:51 [ permanent link ]
Servus William!
From: "William L. Hartzell" <wlhartzell@comcast.net>
The less physical RAM the larger the limit and vice versa >> (crazy).>>
If the large image is splitted (striped) into parts below the >> limit, than printing works well, so it is definitly a problem >> of the imagesize which is supplied to GpiDrawBits() or >> GpiWcBitBlt() etc.>>
Since you are authoritative on this, are not these calls WLH> to Gpi done by the print driver
In fact, printing application have to create a HPS (handle to a presentation space associated to the printer) to which it 'prints' by appling GpiDrawBits(hps,..) or GpiWCBitBlt(hps,..) calls with the 'hps' and the bitmap (either the real bitmap in memory or a copy referenced by a HBITMAP handle to a bitmap in memory context).
The difference between GpiDrawBits() and GpiWCBitBlt() is, that GpiDrawBits() uses the original BITMAP (like loaded from a file) and needs therefore only the memory of the pixeldata ONCE. GpiWCBitBlt() use a HBITMAP (in the memory contex of the graphics card driver) and this HBITMAP have to be valid till the print job is closed (DEVESC_ENDDOC). In case of printing more pages, a large amount of memory is wasted!
My hypothesis is, that there is a limited amount of (virtual) memory (shared memory?) and the larger the amount of physical memory, the lesser is the useable part for printing (in shared memory), because the overall amount is limited and part of it is used for administration of the whole physical memory. The misbenefit of too less physical memory is - of course - endless swapping (with the benefit of a larger printing size).
and there is nothing you could do to fix this (using WLH> High shared memory)?
Printer device driver does not use high shared memory (?). The only workaround might be, to reduce the imagesize in the API call (GpiDrawBits() or GpiWCBitBlt()) and repeat the call, till the whole image is printed. This will work, but there is a big problem with scaling in this case (you will see horizontal stripes on the final image). I hope I can fix this problem too...
I'll also try this from within my striped down copy of OS/2 to see if it WLH> has more shared memory available.
The limit of overall printable image size is far above 100MB in case of 64MB physical RAM and goes down (im my case) to less than 90MB in case of 512MB RAM. Not very dramatical, but remarkable.
Herzliche Gruesse, Harald
-+- Message created on Thursday February, 03 2005 08:34:24 MEZ
Harald Pollack 3 February 2005 11:34:53 [ permanent link ]
Servus pnielsen@abo.fi!
From: pnielsen@abo.fi
PMView is using high memory all the way down to the GPI p> calls. The problem is within the print engine / printer driver that p> AFAIK does not use high memory. Because of this unfortunate fact, there is p> nothing the application can do. I'm also afraid that we can't even blame p> the writer of the printer driver as the problem problably really is p> with the memory handling of the print engine/spooler. It ought to use p> high memory, but doesn't. p> Maybe Harald has more to add to this?
I am working on this misbehaviour, but I have no idea, how to determine exactly the useable (free) space of shared memory at a certain time.
Herzliche Gruesse, Harald
-+- Message created on Thursday February, 03 2005 08:36:51 MEZ
Aaron Lawrence 3 February 2005 17:12:09 [ permanent link ]
Suddenly, Harald Pollack sprang forth and uttered these pithy words:> because it is a problem of PM, FaxView will also fail...
I didn't exactly follow (is it fixable?), but it sounds like we have reached a limitation of PM... time to retire -- aaronl at consultant dot com For every expert, there is an equal and opposite expert. - Arthur C. Clarke
Bart Bremmers 3 February 2005 18:47:37 [ permanent link ]
William L. Hartzell wrote:> Sir:>
Bart Bremmers wrote:>
I think you've run into a memory problem. Printer resolutions (i.e. >> 600 dpi, 1200 dpi) should not be confused with scanning resolution.>>
A 5 x 7 can be scanned at 200 for normally acceptable results. 300 >> would be the highest I would go. I regularly use 200 or 300 for image >> creation and scanning.>>
Just because digital cameras are currently limited in the number of > pixels that they can capture, does not mean that we should limit our > scans to that resolution. Even at 1200 dpi scanned, one is not > approaching the perceived resolution of a photograph. I pick 1200 dpi > as that is the output resolution of my printer. If I had chosen to > print the image at the same size as the input, it would have been a 3 by > 5 image that would have been printed.>
BTW, scanner resolution is the same as printer resolution. DPI is DPI. > The device context does not change that. Or at least someone would > have a very hard time convincing me otherwise.
Well, I have some old notes that go like this: <start of notes> lpi vs dpi lpi is the dots per inch used in print media. Newspapers use 85 to 100 lpi.Magazines use 133 or 150, National Geographic uses 200 lpi.
When scanned image will be printed original size: To calculate the dpi you should use for scanning, multiply the lpi output your publication uses by 2 or 2 1/2. (ie a magazine that uses 150 lpi would use scans of 300 dpi)
When scanned image will be printed smaller than original: Scan using formula above but use scaling option in your scanning software. <end of notes>
I also did a google on "scanner resolution vs printer resolution" where I found links that confirmed my notes.
So in your case, since you want to blow the image up by roughly double, assuming you want magazine quality, a 600 dpi scan should be sufficient. And hopefully the printing will work.
Of course, I do not wish to impose my methods upon you, your needs for quality of output may far exceed mine.
HTH
--
========================= Bart Bremmers, Gen. Mgr. Craft-Bilt Materials Ltd. Markham, Ontario
Harald Pollack 4 February 2005 00:43:01 [ permanent link ]
Servus pnielsen@abo.fi!
From: pnielsen@abo.fi
PMView is using high memory all the way down to the GPI p>> calls. The problem is within the print engine / printer driver that p>> AFAIK does not use high memory. Because of this unfortunate fact, there p>> is nothing the application can do. I'm also afraid that we can't even p>> blame the writer of the printer driver as the problem problably really isp>> with the memory handling of the print engine/spooler. It ought to use p>> high memory, but doesn't.p>> Maybe Harald has more to add to this?
I am working on this misbehaviour, but I have no idea, how to determine HP> exactly the useable (free) space of shared memory at a certain time.
... and I have worked ...
Till now, I have not used OBJ_ANY in FaxView, because I was to lazy, to make it versiondependent Now I have added:
if (VersionMinor > 40) flag |= OBJ_ANY;
and have done some investigations:
Just before loading an image
FAXIMG Maximal memory per process: 363331584, shared memory: 278200320
after loading a large image, just before calling GpiDrawBits() 3.02.05 21.06 119.348.814 3.446 a--- hugo.BMP
Harald Pollack wrote:> The difference between GpiDrawBits() and GpiWCBitBlt() is, that GpiDrawBits()> uses the original BITMAP (like loaded from a file) and needs therefore only the> memory of the pixeldata ONCE. GpiWCBitBlt() use a HBITMAP (in the memory contex> of the graphics card driver) and this HBITMAP have to be valid till the print> job is closed (DEVESC_ENDDOC). In case of printing more pages, a large amount of> memory is wasted!
PMView uses GpiWCBitBlt. It creates a bitmap before the GpiWCBitBlt that it destroys right after the call. I have not had any problems with this and printing multiple pages. On the other hand, I am not arguing if you're saying that PM is keeping the bitmap around in internal memory until DEVESC_ENDDOC. That may very well be true. Nevertheless, the following sequence works flawlessly when printing multiple pages:
Harald, if I understand your mail correctly, I got the impression that you succeeded in printing bigger images with GpiDrawBits and image data in high memory than what was possible with GpiWCBitBlt ? Is this correct?
I'm using GpiWCBitBlt in PMView mainly because with past versions of OS/2, printer drivers, and service packs, GpiDrawBits used to be buggy and cause problems for a few users. If GpiDrawBits indeed now works better with high memory, maybe it's time for me to update the PMView code again!
In <lRqMd.3066$lw4.722228@news20.bellglobal.com>, Bart Bremmers <gen_mgrBLAH@BLAHcbm.on.ca> writes:>William L. Hartzell wrote:>> Sir:>>
Bart Bremmers wrote:>>
I think you've run into a memory problem. Printer resolutions (i.e. >>> 600 dpi, 1200 dpi) should not be confused with scanning resolution.>>>
A 5 x 7 can be scanned at 200 for normally acceptable results. 300 >>> would be the highest I would go. I regularly use 200 or 300 for image >>> creation and scanning.>>>
Just because digital cameras are currently limited in the number of >> pixels that they can capture, does not mean that we should limit our >> scans to that resolution. Even at 1200 dpi scanned, one is not >> approaching the perceived resolution of a photograph. I pick 1200 dpi >> as that is the output resolution of my printer. If I had chosen to >> print the image at the same size as the input, it would have been a 3 by >> 5 image that would have been printed.>>
BTW, scanner resolution is the same as printer resolution. DPI is DPI. >> The device context does not change that. Or at least someone would >> have a very hard time convincing me otherwise.>Well, I have some old notes that go like this:><start of notes>>lpi vs dpi>lpi is the dots per inch used in print media. Newspapers use 85 to 100 >lpi.Magazines use 133 or 150, National Geographic uses 200 lpi.>
When scanned image will be printed original size:>To calculate the dpi you should use for scanning, multiply the lpi >output your publication uses by 2 or 2 1/2.>(ie a magazine that uses 150 lpi would use scans of 300 dpi)>
When scanned image will be printed smaller than original:>Scan using formula above but use scaling option in your scanning software.><end of notes>>
I also did a google on "scanner resolution vs printer resolution" where >I found links that confirmed my notes.>
So in your case, since you want to blow the image up by roughly double, >assuming you want magazine quality, a 600 dpi scan should be sufficient. >And hopefully the printing will work.
I am not up to date on printing, but I wonder whether your notes are for process color, halftones and screens, rather than inkjet printers with transparent ink, and particularly photo printers which appear to flood the page with ink.
Harald Pollack 4 February 2005 11:36:52 [ permanent link ]
Servus pnielsen@abo.fi!
Harald Pollack wrote:>> The difference between GpiDrawBits() and GpiWCBitBlt() is, >> that GpiDrawBits() uses the original BITMAP (like loaded from a file) and >> needs therefore only the memory of the pixeldata ONCE. GpiWCBitBlt() use a >> HBITMAP (in the memory contex of the graphics card driver) and this HBITMAP >> have to be valid till the print job is closed (DEVESC_ENDDOC). In case of >> printing more pages, a large amount of memory is wasted!
PMView uses GpiWCBitBlt. It creates a bitmap before the p> GpiWCBitBlt that it destroys right after the call. I have not had any p> problems with this and printing multiple pages. On the other hand, I am p> not arguing if you're saying that PM is keeping the bitmap around in p> internal memory until DEVESC_ENDDOC. That may very well be true. p> Nevertheless, the following sequence works flawlessly when printing p> multiple pages:
That's definitivly wrong. Well, it works under some circumstances, but according to PMREF.INF:
The following restrictions apply to the generation of all metafiles, and also to the generation of a PM_Q_STD print file to a device:
If GpiWCBitBlt or GpiBitBlt is used to copy a bit map to a device context in an application, the application should not delete that bit map handle with GpiDeleteBitmap before the device context is closed (metafile is closed).
Harald, if I understand your mail correctly, I got the p> impression that you succeeded in printing bigger images with GpiDrawBits p> and image data in high memory than what was possible with GpiWCBitBlt ? Is p> this correct?
The benefit of GpiDrawBits is, that the source bitmap could be hold in 'HighMemory' while the HBITMAP is elsewhere in the devicecontext of the graphics card driver (I think NOT in high memory region).
The benefit of GpiDrawBits is, that the source bitmap is EXACTLY that bitmap we have loaded while HBITMAP is (or might be) a bitmap, which is 'constructed' in accordance to graphic cards properties. Even if you specify a 24 bit HBITMAP, the bitmap generated might contain only those colors, the graphic card can display (15/16 bit Highcolor, some internal gamma correction and so on).
As a rule of thumb: NEVER use any HBITMAP (if you can use any other methode) because it is (graphic card) device dependent.
I'm using GpiWCBitBlt in PMView mainly because with past p> versions of OS/2, printer drivers, and service packs, GpiDrawBits used p> to be buggy and cause problems for a few users.
Yes, I know. But the problems came from inconsistence between the 'worldcoordinates' PU_TWIPS etc. versus PU_PELS form created PS (which would not matter in case of GpiW<orld>C<oordinates>BitBlt())
If GpiDrawBits indeed now works better with high memory,
GpiDrawBits uses a normal bitmap, which could be situated almost anywhere and therefore also in high memory.
maybe it's time for me to update the PMView code again!
maybe
Herzliche Gruesse, Harald
-+- Message created on Friday February, 04 2005 08:54:49 MEZ
johnsuth@nospam.com.au wrote:> I am not up to date on printing, but I wonder whether your notes are for > process color, halftones and screens, rather than inkjet printers with > transparent ink, and particularly photo printers which appear to flood > the page with ink.
You've got me there! I've haven't done much inkjet colour printing, and when I did, it was just fun stuff for my kids so I didn't pay too much attention to quality.
Klaus Staedtler 7 February 2005 16:53:28 [ permanent link ]
Pete wrote:>
File size is too large . . .
my two cents:
1. For printing an *unscaled* image scanning with 300 DPI is more than sufficient (search the web, make your own tests if you don't believe)
2. Higher resolutions are only necessary if you want to *scale* the image after the scan. E.g. I scanned over 1500 slides and over 500 negatives (both 24x36mm) with 2400DPI (which gives ~ 20MB Tif file) and sizing/printing them to A4 gives crisp/detailed prints (using MacOSX and the Canon i550, OS/2 drivers are ways worse for image printing, my scanner too doesn't work on OS/2 ....)
3. Scanning 10x15cm photos with 600dpi (which gives again a ~20 MB Tiff file) and sizing/printing them to A4 (again using MacosX and Canon i550) gives too excellent results
So first decide what you want to do with the image.
Unless you don't really need a very high scaling (of the whole image or a part of it, like e.g. slides or negatives require it - in this case 2400 DPI or even 3200 DPI is recommended) scanning with 1200 DPI is nothing else than a good test in vaporating pixels (and a good test for CPU cooling)
Naturally this doesn't affect the limitation of printing big files using OS/2, but a little calculation will tell you that in most cases such big files aren't necessary (except for testing the borders and limits
Aeh yes. DPI on printers and scanners are differnt. Right both use the same unit, but as every printer needs a lots of dots to print one scanned dot....
As newer printers have nowadays up to 8 different color-cartridges, have drop-modulation, have smaller drops, have .... situation is getting better, and maybe we gonna see the first printers with internal 48-bit color depth, so we could scan images in 48 bit and print them without the need to reduce the real big files (Oh I already tried to scan such with A4, fullcolor and 2400DPI and discovered during scanning very-very serious USB hickups on e.g. Win/Mac).
Just kidding ... but as you can see there are always lots of possibilities to discover borders and limitations on every OS.
Peter Weilbacher 7 February 2005 16:57:43 [ permanent link ]
Klaus Staedtler wrote:
3. Scanning 10x15cm photos with 600dpi (which gives again a ~20 MB Tiff > file) and sizing/printing them to A4 (again using MacosX and Canon i550) > gives too excellent results
Additionally, it seems that most photo papers in use (even from prints done in good professional labs) only have a resolution of around 300 dpi. So scanning with more than that only increases sampling of the noise. -- GrГјГџe von Peter.
