RE: Snapscan.... Help! (a few extra data)

From: Ian Cartwright (
Date: Thu Dec 21 2000 - 05:28:52 PST

  • Next message: Henning Meier-Geinitz: "Re: Building frozen pre-1.0.4"

    Hi John,

    I have recently had a similar problem with my Acer Prisa 320U. My scans
    would be OK for a few lines, then color banding would start, then, by the
    end of the scan the picture was barely recognizeable... Does this describe
    your scans? If so, my solution was to go into snapscan.h and edit the Device
    ID table (around line 100) to more closely match my scanner. In my case the
    USB Device ID "FlatbedScanner13" was mapped to the Snapscan620 scanner. I
    changed it to the Snapscan300 and it solved my problem.

    I also noticed the buffer calculation (the pss->buf_sz thing), but after
    looking at it more closely, I concluded that the numbers are calculated
    there just for informational purposes and are not miscalculated anywhere
    else in the program.

    Hope this helps!


    -----Original Message-----
    From: John Coppens []
    Sent: Wednesday, December 20, 2000 10:00 PM
    Subject: Re: Snapscan.... Help! (a few extra data)

    Hello Steve.

    Thanks for the info. If only I could find a source for this data, I wouldn't
    bother the list with such basic questions.

    Anyway, I experimented a bit more, but I cannot find a way to get the
    color organized. As I wrote a mail before, the image appears, in different
    colors, displaced horizontally. Something like
    should be Is

    aaabbbcccddd aaabbbcccddd
    aaabbbcccddd abbbcccdddaa
    aaabbbcccddd cccdddaaabbb
    aaabbbcccddd daaabbbcccdd

    note: these stripes are 5 to 50 scan lines wide...

    And colors are changing too. It seems to have something to do with the
    machine's activity at the moment: the horizontal stripes are wider with
    less activity. It's a bit difficult to describe in words.

    I have the impression there's some data loss at the beginning of the
    transferred block... Any way to test this?


    On Thu, 21 Dec 2000 02:25:06 +0800 Steve Underwood <>
    wrote/El dddd> John Coppens wrote:
    > > Hi Chris.
    > >
    > > A few (possibly) hints...
    > >
    > > I've been checking the debug log and found a few strange things.
    > >
    > > - Says buffer is size = 31725 bytes, 55 lines. At 1269 bytes/lines this
    > > can't be (should be 25). I checked the source code and found:
    > Have you allowed for the chroma offset ring-buffer?

    Mmmm... how much space does this occupy? And why is the effective
    space calculated without subtracting this space first?

    > > "%s: effective buffer size = %lu bytes, %lu lines\n",
    > > me,
    > > (u_long) pss->buf_sz,
    > > (u_long) (pss->buf_sz ? pss->buf_sz / pss->lines : 0));
    > >
    > > I suppose this should be / pss->bytes_per_line
    > Yes, this looks like a silly slip.
    > > - A bit before that, it says : set_window: bits-per-pixel set to 30
    > >
    > > How can this result in 3 bytes/pixel afterwards? I couldn't find
    > > how the extra 2 bits (*3) are sent... Are they packed in another block?
    > The scanner is using 30 bits, but after gamma correction it only outputs
    24 bits to the host. This is normal behaviour for a 30 bit
    > scanner.
    > Regards,
    > Steve
    > --
    > Source code, list archive, and docs:
    > To unsubscribe: echo unsubscribe sane-devel | mail


    -- Source code, list archive, and docs: To unsubscribe: echo unsubscribe sane-devel | mail

    -- Source code, list archive, and docs: To unsubscribe: echo unsubscribe sane-devel | mail

    This archive was generated by hypermail 2b29 : Thu Dec 21 2000 - 05:23:54 PST