[sane-devel] searching for business card scanner compatible with sane

[m. allan noah]

On Thu, Dec 24, 2009 at 5:02 PM, Jelle de Jong
<jelledejong at powercraft.nl> wrote:
>>
>> the 'datasheet' does not describe the hardware, but rather the
>> hardware+windows device driver. Some features, like auto cropping are
>> software only features. This is common. You need a very smart ($1000+)
>> machine to do this in hardware. That said- the git development branch
>> of sane-backends does have a first attempt at a software
>> implementation of these features.
>
> The device comes with a fujitsu scansnap carrier sheet to help guide
> documents through the scanning process. It seems the scanner is
> designed in a way to never have good scans but just scan the biggest
> area possible allowed by the size of the input and do all the
> processing later in the software. So the output of this device is
> especially messy because it seems intended for post-processing.

The output of ALL < $1000 scanners works this way. The fujitsu
machines are better than most because they do have a sensor to detect
the trailing edge of the paper. If you upgrade to a current
sane-backends git checkout, you can use the --ald option to use that
sensor. There is no mechanical way to do the same with the paper
width. It must be done in software, either on the PC or inside the
brain of an expensive scanner. The git checkout also has beta code to
do that.

{snip}

> I have the feeling the driver is doing it's job, but the scanner needs
> an complete additional layer to become productive usable.
>
> This layer should still be optional invisible for the end user. The
> few experiences I gathered the last days testing the scanner gives me
> the impression the following features should be added as some sort of
> filter that can be enable and lies between the driver and the scanadf
> (sane) output image.
>
> By default the scanner scans in duplex mode and scans all input
> available (no -x, -y or --page-width and --page-height) this should
> ensures no source data is missed. (this is currently not the case)
>
> This data is send to the filter and does the following:
>
> 1) recognizes document size
> 2) removes blank pages (backsides of input with nothing on it)
> 3) auto rotation and autodeskew
>
> extra "like to have" possibilities:
> 4) auto color detection
> 5) auto resolution selection depending on input sizes
>
> After this there will be a simple but good usable image that can be
> used for all other stuff. This output is what I expected when using
> scanadf without any options on an simple A4 of A8 or C5 input sized
> source.

Yes- it would be nice to have a seamless 'middleware' layer which
could clean the output of any sane driver. It need not be completely
separate from the actual scanner driver, as they could all use a
common external library to provide these features. That might simplify
the user interface. Another option is to write a sane 'middle-end',
but I'm not sure what form that code (and particularly its interface)
might take.

{snip}

> I also have some other issues when doing test with the correct
> possibilities, please see the attachment.

{snip}

> $ scanadf --device-name 'net:192.168.1.1:fujitsu:ScanSnap S1500:14033' --output-file /home/jelle/image-adf-front-0007.pbm --source 'ADF Front' --resolution 600 -x 210 -y 297 --page-width 210 --page-height 297 --bgcolor "White"
> scanadf: rounded value of page-width from 210 to 210.01
> scanadf: rounded value of page-height from 297 to 296.994
> scanadf: setting of option --bgcolor failed (Invalid argument)
>
> # bug06:
> the --help output indicating the scanners options is giving option that do not seem to work like --bgcolor, also the [Default] is not set to the option that is actually the default, this is confusing for me as end-user.

This is a tri-state option provided by the hardware, black, white, or
'Default' in this case means the scanner's internal default. Less
expensive machines tend to default to white, expensive machines to
black. There is no way for me to tell which one. It seems that the
S1500 does not have changeable background color. It is also not
possible to detect this, and it must be hard coded on a per-model
basis.

{snip}

> # issue03:
> I am trying to do some calculation with the geometry, resolution, and print size, but my results are making no sense.
>
> I want to scan an image of the size 210mm × 297mm and want to be able to actually calculate back from the scanned result to the original source size, and what the size will be when printed on 600 DPI. (Dots Per Inch)
>
> I understand that the resolution 72x72 is in PPI (Pixels Per Inch). Al calculation I did resulted in an original scanned size of 175mm x 246mm witch is no where close to the 210mm × 297mm I used as source file. What am I doing wrong?

the pnm formats do not store meta info of the source image (including
the resolution). this info program must output 72x72 by default, which
is dumb. It should be silent, or say 'unknown'. You might try
outputting the image as a tiff instead.

> # question04:
>
> Would it be possible to share the technical datasheet of the chipsets and it's options/registers used to develop the device driver? I am interested in how primitive these chipets are because I for something that can do so little, the price is very high for a mass produced consumer product.

The fujitsu chipsets are some of the most advanced available. They
have jpeg output, full-speed duplex, USB&SCSI, self-calibration,
dynamic thresholding, noise removal, intermediate resolution
interpolation, etc, etc. If you think this machine is bad, you should
try to write a driver for a low-level chipset sometime. One that makes
you calculate the motor slope tables and maintain all the per-cell
shading info in an external file. That will teach you the true meaning
of the word dumb.

There are no publicly available docs for the S1500. It's protocol is
very similar to that of old SCSI fujitsu machines, just wrapped in a
USB packet, and some additional capabilities added. You can see the
M3093 OEM Manual here:

http://193.128.183.41/HOME/v3__product.asp?pid=51&inf=doc&wg=0

The differences would have to come from reading the driver source code.

allan
-- 
"The truth is an offense, but not a sin"