Russ Burdick wrote:
> ok, i've finally got a bit of time to play with my scanner again and i've
> been doing some work with my Acer Prisma 310S and the latest snapscan
> backend (snapscan-20000514.tar.gz) and sane-1.0.2.
>
> from what i've gone through in the source it seem that this scanner has
> the same id (and supposedly behavior) as the VUEGO310S. this brings me to
> my first question for the list: is there anyone out there using a Vuego
> 310S that has had success with any version of sane+snapscan? if the vuego
> works and the acer doesnt, perhaps they're not the same inside and it'd be
> worthwhile to start thinking about separating the two in the snapscan
> code.
>
> back when kevin was still taking care of snapscan and active on this list
> i had a few conversations with him about trying to get snapscan working
> correctly for the acer 310S. at present everything but the very begining
> of a scan is complete garbage, so he had me try doing small scans,
> specifically < 64K. you can see some example of the output here:
>
> http://www.cs.umn.edu/~wburdick/sane/
>
> the first two are color at different resolutions and the last three are
> greyscale. the final image is of a slightly different area on my test
> image since the top of the first one didnt seem all that interesting. this
> is the one i find most interesting. it looks like the first 'block' is
> clear, then the subsequent 'blocks' get more and more garbled. i should
> also note that the resulting pnms (produced by xscanimage) 'appeared to be
> truncated' according to xv, but the greyscale images were fine. i used xv
> to check the images out and to convert them to the above referenced
> pngs. i did all of the above after 'export SANE_DEUBUG_SNAPSCAN=128' and
> the resulting output is also at the above referenced url.
>
> i thought before jumping into the code too deep i'd see if anyone had any
> thoughts on what i'm seeing. is there something it's doing different on
> the scans after the first one that it shouldnt be? any comments welcome.
If you still have the box your scanner came in, look at it. It says "Acer
Vuego 310S", in big letters. There is only one model 310S, but somehow in the
history of the snapscan driver it has been confused as being 2 fairly similar
machines.
The oddness of your scan is, in itself, odd. At first I thought something odd
happens every 8192 bytes. That idea fits some of your pictures. It doesn't
seem to fit out2.png, though. The dirty blue changes to dirty green over a
substantial block of lines. That doesn't seem to fit the model of a simple
hiccup in the data stream, even allowing for the chroma offsets, which the
latest driver compensates for.
A couple of questions. What OS and version are you using? I tested the latest
driver with a RedHat 6.2 installation. That has the recently updated generic
SCSI driver, which may be a factor. At what resolution were these scans
performed? It makes a difference when trying to allow for the chroma offset
compensation analysing your weird results.
One thing worth trying - in snapscan.c you will find a bit that goes:
if (pss->pdev->model == PRISA620S /* GP added - blocking mode only */
||
pss->pdev->model == VUEGO610S) /* SJU added */
{
status = SANE_STATUS_UNSUPPORTED;
}
else if (pipe (pss->rpipe) != -1)
{
Change it to go:
if (pss->pdev->model == PRISA620S
||
pss->pdev->model == VUEGO310S
||
pss->pdev->model == VUEGO610S)
{
status = SANE_STATUS_UNSUPPORTED;
}
else if (pipe (pss->rpipe) != -1)
{
and see what happens.
Steve
-- 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 : Sun Jun 11 2000 - 04:35:26 PDT