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!
Ian
-----Original Message-----
From: John Coppens [mailto:jcoppens@linux2.uccor.edu.ar]
Sent: Wednesday, December 20, 2000 10:00 PM
To: sane-devel@mostang.com
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?
John
On Thu, 21 Dec 2000 02:25:06 +0800 Steve Underwood <steveu@coppice.org>
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?
>
> > DBG (DL_DATA_TRACE,
> > "%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: http://www.mostang.com/sane/
> To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
---- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
-- 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 : Thu Dec 21 2000 - 05:23:54 PST