D
Don
OK, that explains it!
I wish!
Getting access to the scanner at each scan line (focus, exposure, etc)
is my Holy Grail and why I got the SDK in the first place, but that's
not what you get. So I'm now disassembling and tracing both the TWAIN
module and the DLLs it calls.
There is a single entry and you pass function numbers on stack as one
of the parameters. You can see this if you use:
"C:\Program Files\Microsoft Visual Studio\Common\Tools\DEPENDS.EXE"
and point it at the TWAIN module.
The SDK is divided into two parts: MAID and command (two CDs).
MAID refers to TWAIN and simply enumerates all functions. It's further
subdivided into "regular" (my wording) and vendor specific. The latter
is where ICE, GEM and friends are listed.
You also get an example program in C which is command based (runs in a
DOS box). The programming interface to MAID is a maze of C structures
in a linked list. They are all defined in the program using official
Nikon names (also used in the documentation).
The second CD of the SDK, command, is a single document, listing all
low level commands sent to the scanner.
However, there is no documentation on the actual interface other than
the theoretical high level explanation. This is a problem with USB
because there are no standard programming interfaces. Nikon's USB
implementation actually emulates SCSI phases. Alas, there is no
example program.
These "low level" commands are actually quite high level and still
don't give you access to individual scanner controls like the stepper
motor. You do get some insight, though, because the data is returned
as structures of bytes where each bit means something different. Of
course, there are also strings, etc.
Finally, most written documentation is in "Japanese English" ;o) but
it's understandable. The SDK comes "as is" with no after support.
Indeed! You do get a message when the scan is complete but it's
tricky. The actual call to start the scan includes an address of a
callback routine (and a structure). The callback routine will signal
when the scan is complete by modifying this structure. That's how you
know when the scan is finished.
I think that would be OK for your purpose because if you get the
callback routine to signal to you that the scan is done you could
advance the film and be ready for the next batch. Indeed, you could
even rewrite the callback routine to implement a different signaling
mechanism, if you so chose.
I actually rewrote the sample program in VB (which is really, really
hard because of C structures and linked lists) and in the process I
had to dissect the code - which was very good for learning purposes,
albeit time consuming. You don't get the scan data in a one big swoop
but it comes in "gulps" of 32K chunks. I suspect this is due to
internal scanner memory but it may not be (I'm too busy with other
things to look into it).
Don.