Archived from groups: alt.comp.periphs.scanner (
More info?)
On Thu, 21 Oct 2004 20:03:02 +0200 in alt.comp.periphs.scanner,
"Christian Schmitz" <hierbinich@t-online.de> wrote:
>> NO, NO, The optical resolution of that scanner is 600 DPI. It says so in
>the
>> specification. 1200 DPI is for the stepping motor, that is the number of
>> steps the scanner can make down the sheet. The horizontal resolution is
>600
>> DPI max.
>
>Thats what i meant with Subscan, 600 dpi is the resolution of the ccd, 1200
>dpi is the resolution of the stepper motor.
>
>> Your slow transfer (scan) may have something to do with the fact that
>those
>> resolutions are not even divisors of 600.
>>
>
>I can not imagine, that this calculation will slow down the scanner, because
>it does a lot of calculations even if it scans with 600 dpi.
The driver normally just passes the brightness/colour levels from the
scanner to the program, which writes them out to disk.
At abnormal resolutions, the driver or program has to look at
brightness/colour levels from four real pixels to calculate what it
should make up for the brightness/colour levels of the virtual pixels.
These kinds of operations should be left to image manipulation
programs, as those applications tend to do a better job than most
vendors' scanner drivers or interface programs, and often run code
customized for processor features like MMX, 3Dnow, etc. to work faster
as well as better.
>> Do not go above 600, as 600 is the maximum resolution of the scanner
>without
>> interpolation. Then it really gets slow.
>>
>> If you must scan at higher then 600 DPI, you have to get a new scanner
>with
>> higher resolution. There are some really low price scanners that will scan
>> flat documents at up to 3200 DPI. Most are around 1200 DPI.
>
>Do you know a scanner with more the 600 dpi, that scans with 0.36ms/line?
>That is what the GT-30000 does with 600 dpi.
>
>A3:
>Gray:
>300 dpi: 2.2sec
>600 dpi: 4.3sec
>(1200 dpi: 34.4sec)
twice as slow as the hardware would be (17s) due to
interpolation
>Color:
>300 dpi: 4.4sec
>600 dpi: 8.57sec
>(1200 dpi: 101.7sec)
three times as slow as the hardware would be (34s) due to
three colour interpolation
>But i have made some further test and i am really sure, that the problem is
>the SCSI-Interface.
Not likely, unless it is a faulty card or cable, and SCSI interfaces
tend to complain a lot about such things.
More likely just a slow driver doing generic math, perhaps using
software to avoids problems using the floating point unit.
>Mainproblem is, that aquiring data from the scanner is done by a
>real-time-priority-thread, this takes so much computing-power that copying
>the data from the input buffer to the image buffer is not possible in the
>remaining time.
The scanner waits for the go-ahead from the driver to step and scan.
And a SCSI interface requires the least CPU power of all interfaces.
>Another problem is, even if you have 2GB, your OS (W2K in this case) would
>not give you an area, that is great enough, so copying is done through the
>swapfile with 12MB/s (PIV-Board Real-Mem-To-Mem-Copy is something around
>500MB/s).
The system will give out the memory if asked for: that's why graphics
programs like gimp and PhotoShop need large memories and fast
processors.
Scanner programs normally just write chunks to disk as TIFF files.
>So, what i need, is a faster scsi-driver and a faster disk for swapping.
>
>Ah, and... I do not want to print the images, it is for a
>industrial-testing-system.
Do all your scanning at the maximum supported optical resolution:
600dpi. Then mess around in an image editing program; hints: results
are better if you keep dpi and sizes to small integer multiples or
dividers of the hardware values, rather than arbitrary values; and
save the image under a different name before you start fiddling with
it, so you can compare before and after appearance and quality, or
start again with the original scan.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply