Re: [snapscan] Core testing group

From: Sebastien Sable (sebastien.sable@gmx.net)
Date: Fri Nov 03 2000 - 10:39:30 PST

  • Next message: Timothy Little: "Re: [snapscan] Core testing group"

    Steve Underwood <steveu@coppice.org> writes:

    > It might be better to do this now. It might encourage people to provide the
    > information to fill in the holes.

    All right, I will post it here regularly. I put the current version at
    the end of this mail.

    > Most of the 300dpi scanner have an actual optiocal resoltionof 300dpi in
    > width and 600dpi in length. The 600dpi scanners are actually 600dpi in
    > width x 1200 dpi in length. That asymmetric resolution is common to every
    > model I know of. Running a 600x1200 scanner as 1200x1200 is quite
    > meaningful. Beyong that its mostly blur!

    I saw this when I tried 600dpi with my model, the picture is deformed
    (2x high - 1x width). My scanner must be a 300 x 600.
    I already find 300dpi pictures take a lot of memory (well some may
    need more than that).

    > Although the bits per colour varies, the current snapscan software always
    > reads 8 bits per pixel for full colour scans. The rest are absolbed in
    > gamma correction. The actual scanning process is almost oblivious to the
    > number of bits.

    I have this in snapscan.c.

        case SNAPSCAN300:
            pd->depths = depths8;
            break;

        case PRISA620S:
            pd->depths = depths12;
            break;

        case VUEGO610S: /* SJU added */
        default:
            pd->depths = depths10;
            break;

    Is it just not used (I would like it, that would make things easier)?

    By the way, there are many changes that have been made for PRISA620S
    and VUEGO610S (they return SANE_UNSUPPORTED for example in inquiry and
    a few others things). Can we delete that (I think so, but I don't want
    to break everything)?

    What do you think of only keeping 3 kinds of models (SNAPSCAN300 -
    SNAPSCAN600 - SNAPSCAN600P)? If the depth stuff is not used, I can
    make the change in 5 minutes and I'm rather sure everything will work
    the same than before. But before doing that I'd like to be sure that
    it is usefull and won't make things harder in the future. I will
    probably change the backend to automatically detect USB models too and
    so suppress the #define USB_STUFF.

    The current feedback for snapscan scanners with snapscan-01112000:

    Acer 300f
    ACERSCAN_A4____1
    Works
    300dpi
    SNAPSCAN300

    AGFA Snapscan 310S
    ??
    Works
    300dpi
    SNAPSCAN300

    AcerScan (Prisa) 610ST
    FlatbedScanner_4
    Works
    600dpi
    SNAPSCAN600

    Acer 610+
    ??
    ??
    ??
    SNAPSCAN600P

    Acer PrisaScan 640S
    FlatbedScanner18
    ??
    ??
    SNAPSCAN600

    Acer 640BU
    FlatbedScanner20
    stops halfway (correction proposed waiting for feedback)
    19200 dpi I think.
    14bits

    Agfa 1212U
    SNAPSCAN 1212U
    Works (to be confirmed)
    600dpi
    SNAPSCAN600P

    Agfa Snapscan 1236s
    SNAPSCAN 1236
    Works (up to 300, problem at 600)
    600dpi
    SNAPSCAN600

    -- 
    Sébastien Sablé
    sebastien.sable@gmx.net
    

    -- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com



    This archive was generated by hypermail 2b29 : Fri Nov 03 2000 - 10:47:15 PST