How much RAM for medium format (6x6) scanning?

  • Thread starter Thread starter zxcvbob
  • Start date Start date
:
"...
the functionality of the peripheral device is determined by the driver, not the
application (program).
...."

You are using an interesting, and incorrect, definition of "driver" here.

According to "The Jargon Lexicon," (aka "The Jargon File") the definition of Driver is:
In `device driver', code designed to handle a particular peripheral device such as a
magnetic disk or tape unit. (Second of three contexts)

Additionally, The Computer User High Tech Dictionary says:

Definition for: driver
1.A device driver is a program that extends the operating system to support a device such
as a disk or tape drive; or a program that enables an application to use a device such as
a printer. Hardware devices such as sound cards, printers, scanners, and CD-ROM drives
must each have the proper driver installed in order to run. 2.A line driver is <snip>
http://www.computeruser.com/resources/dictionary/

Therefore it can be paraphrased to say that

1 - A "Driver" facilitates the **communication** between the computer (and any
applications program residing or running on the computer) and a peripheral device;

2 - A "Driver" has no internal intelligence. In an automobile it would be analogous to the
driveshaft that connects the wheels to the motor or transmission.

Therefore "jjs" is correct when he posted
"... Technically, a 'driver' is just an interface between the OS and a
peripheral. The intelligence that interprets the image is in the program.
A bad driver usually simply doesn't work. ..."

And

The functionality of the peripheral device is determined by the hardware capabilities of
the device, and how the applications program is configured to use those capabilities. The
"driver" has nothing to do with that inherent functionality.
 
RSD99 said:
"driver" has nothing to do with that inherent functionality.
Click to expand...

That doesn't mean the driver can't limit the functions. A driver doesn't
have to support 100% of the functions. It doesn't have to support them well.

Nick
 
When working with photo-scanner programs, the general rule is: the more
memory, the better. You need to handle the (huge) program and a couple of
large data buffers at the same time. The operating system compensates by
putting unneeded parts of the program and data into virtual memory (disc
treated like memory), so you can get away with limited RAM. But limited RAM
slows you down - often a lot. Your guess of 256K as a minimum is good. I
use 512K on my computer for moderate (1200 dpi) scans of medium format with
good response. I still have to wait a little for some things, but not much
and not usually. For more detailed scans, the wait can be significant. I
recently scanned some 8X10s at 1200 dpi, and I could probably have made
darkroom prints in the same time it took to process those 300 Mb images. In
addition to RAM, make sure you have enough disk. The program will use
virtual memory a lot. It's wise to keep 5 - 20 Gb free for temporary files,
virtual memory, buffers, and spool.
 
Hi,

Recently said:
:
"...
the functionality of the peripheral device is determined by the
driver, not the application (program).
..."

You are using an interesting, and incorrect, definition of "driver"
here.

According to "The Jargon Lexicon," (aka "The Jargon File") the
definition of Driver is: In `device driver', code designed to handle
a particular peripheral device such as a magnetic disk or tape unit.
(Second of three contexts)

Additionally, The Computer User High Tech Dictionary says:

Definition for: driver
1.A device driver is a program that extends the operating system to
support a device such as a disk or tape drive; or a program that
enables an application to use a device such as a printer. Hardware
devices such as sound cards, printers, scanners, and CD-ROM drives
must each have the proper driver installed in order to run. 2.A line
driver is <snip> http://www.computeruser.com/resources/dictionary/

Therefore it can be paraphrased to say that

1 - A "Driver" facilitates the **communication** between the computer
(and any applications program residing or running on the computer)
and a peripheral device;
Click to expand...
I disagree with your paraphrase. To directly quote the definition: "1.A
device driver is a program that extends the operating system to support a
device such as a disk or tape drive; or a program that enables an
application to use a device such as a printer."

Drivers more than merely "facilitate(s) the **communication** between the
computer...", in many cases, they provide functionality that the OS lacks
to enable the devices to work at all. This was typical of SCSI card
drivers under DOS and early versions of Windows, for example.

Drivers also provide control interfaces for their devices, and it is up to
the writer of the driver to either support all or a subset of the devices'
operational modes. When I wrote drivers for my Summagraphics tablets
(about 20 years ago), I had the option to support all of the tablet's
operational modes, or just particular modes (such as absolute coordinates
vs. relative coordinates). In this case, the driver facilitated the
communication with applications *and* extended the OS to allow the cursor
to be controlled by the tablet *and* provided a memory resident keyboard
command interface to set the tablet's operational modes. Since the tablet
had to be initialized at boot time, if I didn't include the command
interface for the selection and support of those modes, then no
application could get around that.
Therefore "jjs" is correct when he posted
"... Technically, a 'driver' is just an interface between the OS and a
peripheral. The intelligence that interprets the image is in the
program. A bad driver usually simply doesn't work. ..."
Click to expand...
Which is why I said it enhanced, rather than contradicted Stacey's
comment. However, a driver can also be an *extension* of the OS, as your
own example points out, so it is an incomplete statement about the role of
a driver.
And

The functionality of the peripheral device is determined by the
hardware capabilities of the device, and how the applications program
is configured to use those capabilities. The "driver" has nothing to
do with that inherent functionality.
Click to expand...
This interpetation is simply incorrect. There are many peripherals, such
as video cards, audio cards, etc. that have modes that are supported by
some drivers and not others. For example, a video card may be capable of
32-bit display under one OS, but not another, simply because that mode is
not enabled (e.g. "supported") by the driver for the other OS. In most
cases involving low-level hardware, applications can't change those
parameters. There are many such examples, and it is exactly this kind of
difference that Stacey was referring to.

Regards,

Neil
 
Recently said:
That doesn't mean the driver can't limit the functions. A driver
doesn't have to support 100% of the functions. It doesn't have to
support them well.
Click to expand...
I can only imagine that those who don't understand this basic truth are
lacking experience.

Neil
 
One need only compare the (in many/most cases) limited functionality of
OS Win drivers for printers, scanners, whatever, to the manufacturer's
driver to see that device drivers do more than merely "communicate".

Mac
 
Mac McDougald said:
One need only compare the (in many/most cases) limited functionality of
OS Win drivers for printers, scanners, whatever, to the manufacturer's
driver to see that device drivers do more than merely "communicate".
Click to expand...

The _driver_ is one part, the intelligence in the assend program is another.
Drivers are drivers, for better (and often) worse.
 
Nick Zentena said:
That doesn't mean the driver can't limit the functions. A driver doesn't
have to support 100% of the functions. It doesn't have to support them
Click to expand...
well.

But if there's going to be a driver that doesn't support the full
functionality of the device, it's going to be the Unix driver, not the 'Doze
driver.

David J. Littleboy
Tokyo, Japan
 
Nick Zentena said:
That doesn't mean the driver can't limit the functions. A driver doesn't
have to support 100% of the functions. It doesn't have to support them well.
Click to expand...

The original Nikon drivers for the LS-30 would be a fine example. ;-)

Ralf
 
David J. Littleboy said:
But if there's going to be a driver that doesn't support the full
functionality of the device, it's going to be the Unix driver, not the 'Doze
driver.
Click to expand...


Depends on who writes the driver. Lets say you make two scanners. Both
have fairly similar hardware. You'd like to sell one for more money then the
other. So you limit the features you turn on in the first one. The driver
written by the scanner maker has an incentive not to be feature rich in this
case. OTOH the one made by a third part has the opposite incentive. I think
that's a problem Intel has faced with motherboard chipsets. The people
building the motherboards would turn on features and be able to use cheaper
chipsets.

Nick
 
I disagree with your paraphrase.
Click to expand...

Me too, and I do agree with your comments, but let's face it, the term
driver has come to have many very different meanings, some not so
technically correct but still acceptably used.

Since the 386 days, the CPU protected modes are used (for example by
Windows) to prevent unathorized access to ports or memory. A driver
formally is NOT a program, but is instead very special software written to
conform to Windows specific definitions for driver architecture (as opposed
to the ordinary specifications for programs), to provide this privledged
access to ports or hardware devices, in highly privledged ring 0 level -
privledges not allowed to mere "programs". This is a Real Big Deal, driver
has this very precise special meaning to Windows. MS-Dos didnt care and a
program could access anything, but in protected Windows versions like W2K
or XP, no program can access a port directly - not allowed for the good of
the system. One gets in line and does it orderly via a driver, to prevent
getting a protected port fault.

So that's a driver, technically, specifically conforming to Windows driver
architecture standards, and thus given privledged ring 0 mode to be allowed
to access the ports without CPU fault. A driver is very privledged in
Windows.

But we call programs that simply operate hardware by the name drivers too,
even if not so privledged.

For example, scanner "drivers" dont operate at ring 0, and so instead must
access any ports or devices via a bonefide driver for the port, for example
the USB port driver or Firewire port driver. They send specific command
data to the device, but they must talk to the port driver to do it. To
Windows, these scanner programs are not drivers, nor driver architecture,
they are just GUI Windows programs, a regular exe program that normally
accesses its own twain module to do the work. However, sometimes it knows a
few special proprietary things that the twain specification doesnt know.

The Twain "driver" is not a driver either, it is just a common interface
providing simple standard commands for complex operations in specialized
hardware. Basically the twain .ds file is only a dll file in a known
location with known interface. Photoshop for example doesnt know how to
operate any scanner, but it does know how to talk to to the twain
interface, which is then passed to the scanner "driver", which then
understands the specific and complex hardware. The only real driver
(Windows architecture wise) is the Windows USB port driver (for example)
to actually access the hardware port without protection fault. However
scanner twain modules do know how to operate the specific hardware device
they support, and this knowledge is necessary for any other program to
operate the scanner.

I'd call these drivers too, we require them to operate the hardware, but
they are just programs, and not of Windows driver architecture like real
drivers. It would be good if we had a different term, Handler perhaps, to
differentiate it from a real driver (but the user couldnt care less what it
is called - they are all drivers).

And terminology has become even more lax, for example modems used in
Windows now must provide a Windows INF file that describes the modems
properties, init strings, etc. (this is real good too, users no longer need
to know about init strings). Some of us have even come to call these INF
files by the name "modem driver" too, but it is not even code, it is only a
list of structured data, and technically it is an INF file. The real
driver is the serial port driver, part of Windows.

So generally to the user, the term driver has just come to mean the file
you must load for Windows to use the device. Often it is not a real
driver, but this doesnt really matter to us, we still must have it to use
the device.
 
RSD99 said:
:
"...
the functionality of the peripheral device is determined by the driver,
not the application (program).
..."

You are using an interesting, and incorrect, definition of "driver" here.

According to "The Jargon Lexicon," (aka "The Jargon File") the definition
of Driver is: In `device driver', code designed to handle a particular
peripheral device such as a magnetic disk or tape unit. (Second of three
contexts)
Click to expand...


But in these examples the driver is a generic one that all such devices must
meet the same interface specs to work. You can swap out a HD for a HD and
no driver change is needed. With a scanner, try unplugging a umax scanner
and plug in a cannon and see if it still works with the same driver!
 
RSD99 said:
Agree with that ...

There are good drivers, and there are bad drivers ...
Click to expand...
IMHO the windows drivers that came with my scanner are 'bad' and the linux
drivers for the same scanner are good! ;-)

In my case the windows drivers have noticable banding while the linux
drivers don't. All I can say, since I don't write hardware drivers, is it
works better in linux than it does in windows and the only thing I can see
that's different is the 'drivers'.
 
Wayne said:
So generally to the user, the term driver has just come to mean the file
you must load for Windows to use the device. Often it is not a real
driver, but this doesnt really matter to us, we still must have it to use
the device.
Click to expand...

Maybe what I've run into is the part of the "driver" that adjusts the
information recieved from the scanner into the actual image. If the
"drivers" or whatever you call the software that controls the scanner made
no difference, software like -viewscan- wouldn't be popular. Whoever wrote
the software that controls my scanner in linux was more on the ball than
the people at umax were!
 
Stacey said:
IMHO the windows drivers that came with my scanner are 'bad' and the linux
drivers for the same scanner are good! ;-)
Click to expand...

A good general rule in computerland is that manufacturers of good
hardware usually write poor drivers, and manufacturers of good software
usually build poor hardware. It's very rare to get both from the same
vendor.

If the Linux drivers work better, it's probably because they were
written by software engineers who knew how the hardware interface
worked, not hardware engineers who learned a bit of programming.
 
Stacey said:
Maybe what I've run into is the part of the "driver" that adjusts the
information recieved from the scanner into the actual image. If the
"drivers" or whatever you call the software that controls the scanner made
no difference, software like -viewscan- wouldn't be popular. Whoever wrote
the software that controls my scanner in linux was more on the ball than
the people at umax were!
Click to expand...

Interpreting the semantics of the data isn't part of the driver. Or at
least it wasn't when the word driver was popularised in software
engineering. For example, interpreting colours using ICC profiles is
part of the image processing application.

Nowadays there is the new buzzword 'middleware' for ambiguous pieces of
code...

-- Lassi
 
Mxsmanic said:
A good general rule in computerland is that manufacturers of good
hardware usually write poor drivers, and manufacturers of good software
usually build poor hardware. It's very rare to get both from the same
vendor.

If the Linux drivers work better, it's probably because they were
written by software engineers who knew how the hardware interface
worked, not hardware engineers who learned a bit of programming.
Click to expand...

Irregardless of the semantics or reasoning, the scanner works better with
one -software set- than the other. Your statement about "It's the same
scanner, so the quality of the scans will be the same." isn't correct as
different software (like viewscan) can give different results from the OE
scanning app on the same scanner even in the same OS. Change the OS (and
all the code to interface with the device) and the performance can easily
be better or worse.

Another example of this is while the scanner works better in linux, my
canon printer works -much- better for photo printing in windows with the OE
canon drivers, my epson printer seems about the same either way.
 
Stacey said:
Another example of this is while the scanner works better in linux, my
canon printer works -much- better for photo printing in windows with the OE
canon drivers, my epson printer seems about the same either way.
Click to expand...

Why not just get a Mac, then everything would work great!!!! With one machine :-)
 
Back
Top