Discussion:
genesys backend
(too old to reply)
Pierre Willenbrock
2005-08-14 22:30:31 UTC
Permalink
Hi

The canon lide 35 is now scanning in color at any resolution. No
calibration yet. I'd like the calibration code to use a more generic
interface to the scanning logic before. But that will have to wait.

This time i want to propose a new mechanism for generating slope tables
in the genesys backend, which i implemented for my work.
In my opinion it is sufficient to describe one slope for each step type.
This slope is truncated as soon as the exposure time is reached. This
leads to a variable step count, which can be used to shorten the
acceleration/deceleration considerably.

I used slopes derived from a start step time(vstart), a final step
time(vend), a power(g) and a step count(steps):
p[i] = (i/(steps-1))^g
t[i] = vstart*(1-p[i])+vend*p[i]
For i in 0..(steps-1).

Pros:
+ less Constants
+ a means for calculating exposure time(which is limited by maximum
motor speed and number of pixels processed per line)
Cons:
- variable step count
- may be not applicable to all supported scanners
- breaks the current code

I attached the code i am using.

Related to this and just out of interest: Does the gl646 expect its
slope tables to contain STEPNO*2 resp. FASTNO*2 steps, too?

Regards,
Pierre
Jens Luedicke
2005-08-18 04:57:33 UTC
Permalink
Post by Pierre Willenbrock
Hi
The canon lide 35 is now scanning in color at any resolution. No
calibration yet. I'd like the calibration code to use a more generic
interface to the scanning logic before. But that will have to wait.
This time i want to propose a new mechanism for generating slope tables
in the genesys backend, which i implemented for my work.
In my opinion it is sufficient to describe one slope for each step type.
This slope is truncated as soon as the exposure time is reached. This
leads to a variable step count, which can be used to shorten the
acceleration/deceleration considerably.
I used slopes derived from a start step time(vstart), a final step
p[i] = (i/(steps-1))^g
t[i] = vstart*(1-p[i])+vend*p[i]
For i in 0..(steps-1).
+ less Constants
+ a means for calculating exposure time(which is limited by maximum
motor speed and number of pixels processed per line)
- variable step count
- may be not applicable to all supported scanners
- breaks the current code
I attached the code i am using.
Could you create a patch for use with current CVS?

I tried to apply your code, but some things don't work out for me and
I'm not a developer and not familiar with the API + changes.

TIA,
jens
--
Jens Luedicke
web: http://perldude.de/
Pierre Willenbrock
2005-08-18 23:38:38 UTC
Permalink
Post by Jens Luedicke
Hi
[proposed changes to slope generation]
I attached the code i am using.
Could you create a patch for use with current CVS?
I tried to apply your code, but some things don't work out for me and
I'm not a developer and not familiar with the API + changes.
With anonymous cvs working again i can now provide a patch against
current cvs.

genesys_slope.diff.gz (gzipped) contains the changes to slope
generation(against current cvs).

If you want to test on a gl646 based scanner, you will probably need to
(largely) tweak the values in the motor structs in genesys_devices.c to
get it to work(if you get it to work at all, the exposure time and
assumed step count in gl646 code may be completely wrong).
I was unable to derive good numbers from the code alone. All step times
are for full steps, even when used for half or quarter step mode. The
code currently does the needed shifting for times and step count.
I did not change anything inside genesys_gl646.c, mainly because i do
not own a scanner with this chip.

The attached code in my last mail was not meant to be complete, i
attached it for clarification.

For a partly working Canon LiDE 35 you will need to apply
genesys_gl841.diff.gz (gzipped) to experimental cvs. The patch already
contains the slope generation code. Only color mode is working
currently. And not even bugfree.

Regards,
Pierre
Jens Luedicke
2005-08-19 17:10:05 UTC
Permalink
Post by Pierre Willenbrock
For a partly working Canon LiDE 35 you will need to apply
genesys_gl841.diff.gz (gzipped) to experimental cvs. The patch already
contains the slope generation code. Only color mode is working
currently. And not even bugfree.
my LiDE 50 is (partially) working. I could scan an image in 8 bit Color
(gimp refused to open the 16 bit color image). the resulting file had a
reddish stain.

Thanks for your work!

btw, I needed to strip the C++ style comments. My gcc didn't like them.
Jens



- --
Jens Luedicke
web: http://perldude.de
Nikolas Arend
2005-08-21 15:31:41 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Pierre Willenbrock
For a partly working Canon LiDE 35 you will need to apply
genesys_gl841.diff.gz (gzipped) to experimental cvs. The patch already
contains the slope generation code. Only color mode is working
currently. And not even bugfree.
my LiDE 50 is (partially) working. I could scan an image in 8 bit Color
(gimp refused to open the 16 bit color image). the resulting file had a
reddish stain.
Thanks for your work!
btw, I needed to strip the C++ style comments. My gcc didn't like them.
Jens
Hi all,

I own a Canon Lide 80, which also uses the gl841 chipset. I'd like to
test it with Pierre's latest patch, but I guess since it's not listed in
genesys_devices.c, scanimage -L won't find it.
Could somebody please give me some hints what I must do to make it being
recognized?

Thank you so much for your work on the backend!

Regards, Nick
Zhixing Xue
2005-08-21 18:29:12 UTC
Permalink
At Sun, 21 Aug 2005 17:31:41 +0200,
Post by Nikolas Arend
Hi all,
I own a Canon Lide 80, which also uses the gl841 chipset. I'd like to
test it with Pierre's latest patch, but I guess since it's not listed in
genesys_devices.c, scanimage -L won't find it.
Could somebody please give me some hints what I must do to make it being
recognized?
Did you looked at the tools/hotplug/README? For me with kernel 2.6.11
there's config at /etc/hotplug/usb/libsane.usermap as below:

grep -i LIDE /etc/hotplug/usb/libsane.usermap
# Canon Inc.|CanoScan N670U/N676U/LIDE 20
# Canon Inc.|CanoScan N1240U/LIDE 30
# Canon Inc.|LIDE 50
# Genesys Logic, Inc.|Pacific Image Electronics PrimeFilm 1800u slide/negative scanner

so that sane-find-scanner gave me:

found USB scanner (vendor=0x04a9 [Canon], product=0x2213 [CanoScan], chip=GL841) at libusb:001:002

enjoy it ;-)

xue
Post by Nikolas Arend
Thank you so much for your work on the backend!
Regards, Nick
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
Nikolas Arend
2005-08-21 19:09:54 UTC
Permalink
--- Ursprüngliche Nachricht ---
Betreff: Re: [sane-devel] genesys backend
Datum: Sun, 21 Aug 2005 20:29:12 +0200
At Sun, 21 Aug 2005 17:31:41 +0200,
Post by Nikolas Arend
Hi all,
I own a Canon Lide 80, which also uses the gl841 chipset. I'd like to
test it with Pierre's latest patch, but I guess since it's not listed in
genesys_devices.c, scanimage -L won't find it.
Could somebody please give me some hints what I must do to make it being
recognized?
Did you looked at the tools/hotplug/README? For me with kernel 2.6.11
grep -i LIDE /etc/hotplug/usb/libsane.usermap
# Canon Inc.|CanoScan N670U/N676U/LIDE 20
# Canon Inc.|CanoScan N1240U/LIDE 30
# Canon Inc.|LIDE 50
# Genesys Logic, Inc.|Pacific Image Electronics PrimeFilm 1800u slide/negative scanner
found USB scanner (vendor=0x04a9 [Canon], product=0x2213 [CanoScan],
chip=GL841) at libusb:001:002
enjoy it ;-)
xue
Hi,

of course the USB device is physically there and sane-find-scanner detects
the scanner, scanimage -L however does not recognize it. As I said, I guess
it must be listed in genesys_devices.c in order to be checked for by sane,
but I may be wrong.

Best, Nick.
--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++
Pierre Willenbrock
2005-08-19 19:44:24 UTC
Permalink
Hi Pierre,
thanks a lot for your work.
I'm a owner of canon lide 35 scanner. I had got the experimental cvs and used your patch.
device `genesys:libusb:001:002' is a Canon LiDE 35/50 flatbed scanner
But after first 'scanimage >image.pnm' both image.pnm and raw.pnm are black
pics by me. And if I run 'scanimage >image.pnm' again, it stops there. I
must unplug it and then plug it again, to get the black pic.
I didn't enabled debug mode jet, if you want more details, I'm glad to help.
xue
Hi Zhixing, hi list,

as explained in my last mail, only color mode works currently. No
calibration yet. And quite some bugs are still left. scanning with
'scanimage --mode Color > image.pnm' should work, and result in a
colored image.pnm and a (more or less) grey raw.pnm, divided in three
columns(one per color).

I am glad to see it working that well, i feared more stuck scanning
heads, as happens here sometimes.

Currently i am splitting the register initialization in movement and
optical parts. This will hopefully lead to a unified way to initialize
the scanner for normal scanning as well as for calibration and ease
integration of other scanners. I will send another patch when i am
finished with that.

Regards,
Pierre
Zhixing Xue
2005-08-19 19:56:01 UTC
Permalink
At Fri, 19 Aug 2005 21:44:24 +0200,
Post by Pierre Willenbrock
Hi Zhixing, hi list,
as explained in my last mail, only color mode works currently. No
calibration yet. And quite some bugs are still left. scanning with
'scanimage --mode Color > image.pnm' should work, and result in a
colored image.pnm and a (more or less) grey raw.pnm, divided in three
columns(one per color).
Great, that works!
Post by Pierre Willenbrock
I am glad to see it working that well, i feared more stuck scanning
heads, as happens here sometimes.
Currently i am splitting the register initialization in movement and
optical parts. This will hopefully lead to a unified way to initialize
the scanner for normal scanning as well as for calibration and ease
integration of other scanners. I will send another patch when i am
finished with that.
Can't wait until that ;-)
I'm ready for the test work

xue
Pierre Willenbrock
2005-08-26 22:43:38 UTC
Permalink
Hi

The attached patch against experimental cvs leads to a mostly working
Canon LiDE 35. There is support for color and grey scans at arbitrary
resolutions. There are some shortcomings in the code, but those are
mostly structural.

Currently known bugs:
1 You need to replug the scanner every other retry
2 Sometimes the calibration process hangs
3 Some scanning rects lead to stange behaviour
4 Lineart not supported
5 No powersaving(after first use draws about 100mA)

5 should be easy, as i already figured out the needed gpios and
registers. But powersaving is rather optional, and other problems are
more pressing.

4 is some work, as a lot of functions need to be made aware of single
bit data.

2 and 3 fall in the category (sometimes) reproducible, but no clue why
these happen. Does anyone have a patch for valgrind to work with libusb?

For 1 i guess i need more documentation on the usb interface of the
scanner. The windows driver does some things(other than register and
bulk transfers) i don't understand, so i didn't implement them in the
backend. If there is any documentation on the usb interface, please
point me to it. The documentation on the chips does not include this.

Next i will implement the slope table generation in the way Stéphane
suggested.

The attached patch needs to be uncompressed with bunzip2. gzip did
compress only to about 50kb.

Regards,
Pierre
Pierre Willenbrock
2005-08-27 19:53:02 UTC
Permalink
Hi
...
Post by Stéphane VOLTZ
Post by Pierre Willenbrock
1 You need to replug the scanner every other retry
2 Sometimes the calibration process hangs
...
Post by Stéphane VOLTZ
Hello,
I got the same "1 an 2" issue. I don't know if you have the same problem,
but it appeared that the backend has to read 1 more data line than indicated in
the LINCNT register. Before I figured this out, the first scan for calibration
succeeded, but not the in following runs, and it hanged in shading calibration
while reading data.
Regards,
Stef
That is not quite the problem i am having. The scanner does not send any
extra lines.

For #1 i am plugging in the scanner, use scanimage. The next try of
scanimage succeeds in 50% of all cases. If it does not succeed,
scanimage simply hangs on first read.
Nikolas Arend
2005-08-29 15:31:56 UTC
Permalink
Post by Pierre Willenbrock
Hi
The attached patch against experimental cvs leads to a mostly working
Canon LiDE 35. There is support for color and grey scans at arbitrary
resolutions. There are some shortcomings in the code, but those are
mostly structural.
Hi,

sorry if this is a dumb question, but since there's much work going on
for the Canon Lide 35 I wondered how the chances are for getting the
Lide 80 running as well?
Could someone who's working on the backend please venture a guess what
has to be done to get it supported (maybe Pierre's Lide 35 code would
already work with minor tweaking)?
At the moment I can't do much coding myself but would help testing the
backend of course.

Thanks,

Nick.
Pierre Willenbrock
2005-08-29 18:01:44 UTC
Permalink
Hi

As promised
Post by Pierre Willenbrock
Next i will implement the slope table generation in the way Stéphane
suggested.
i am sending the result of this work. I introduced a new flag
GENESYS_FLAG_ALT_SLOPE_CREATE to indicate that the alternate slope
creation functions should be used.

Apart from that the patch contains my version of
sanei_genesys_exposure_time(called sanei_genesys_exposure_time2 to not
collide with uses of the other function) and a few bug fixes:
* size argument of sanei_genesys_create_gamma_table changed from float
to int
* sanei_genesys_read_reg_from_set and sanei_genesys_set_reg_from_set
check for address of current register. If this is 0 they should stop.
* fixed raw data dumping: should write first set of data and close file
* moved call to sanei_genesys_init_structs to before init_options as
init_options depends on an initialized device struct.

Next i'd like to rewrite genesys_read_ordered_data to be more
maintainable and able to convert the cis style planar data to "chunky" data.

For that i need to know what the "stagger" effect exactly is. I am not
sure i got that one right.

The conversion stack i have in mind looks like this:

1. (opt)uncis (assumes color components to be laid out planar)
2. (opt)unstagger (assumes pixels to be depth*channels/8 bytes,
unshrinked)
3. (opt)shrink_lines (assumes pixels to be depth*channels/8 bytes)
4. (opt)reverse_RGB (assumes pixels to be BGR or BBGGRR))
here we should save the finished lines for use with line distance correction
5. (opt)line_distance_correction (assumes RGB or RRGGBB)

My implementation currently used for Canon LiDE 35 does quite a lot byte
moving which considerably slows down the conversion, and is probably not
correct regarding the stagger effect.

Regards,
Pierre
Stéphane VOLTZ
2005-08-29 20:22:07 UTC
Permalink
Post by Pierre Willenbrock
Hi
As promised
Post by Pierre Willenbrock
Next i will implement the slope table generation in the way Stéphane
suggested.
i am sending the result of this work. I introduced a new flag
GENESYS_FLAG_ALT_SLOPE_CREATE to indicate that the alternate slope
creation functions should be used.
Apart from that the patch contains my version of
sanei_genesys_exposure_time(called sanei_genesys_exposure_time2 to not
* size argument of sanei_genesys_create_gamma_table changed from float
to int
* sanei_genesys_read_reg_from_set and sanei_genesys_set_reg_from_set
check for address of current register. If this is 0 they should stop.
* fixed raw data dumping: should write first set of data and close file
* moved call to sanei_genesys_init_structs to before init_options as
init_options depends on an initialized device struct.
Next i'd like to rewrite genesys_read_ordered_data to be more
maintainable and able to convert the cis style planar data to "chunky" data.
It is indeed a rather complicated function. Data doesn't come in an
easy form. But I don't exactly see why you want to convert to planar data
first.
Post by Pierre Willenbrock
For that i need to know what the "stagger" effect exactly is. I am not
sure i got that one right.
At high motor resolution, lines are staggered, ie they aren't
horizontal lines. On pixel is on a line, the folowing colunm is on another ...
A drawing may be more evident:

'O' are pixel of on horizontal line, '.' other lines data

...O.....O.....O.....O.....O.....O.....O
..O.O...O.O...O.O...O.O...O.O...O.O...O.
.O...O.O...O.O...O.O...O.O...O.O...O.O..
O.....O.....O.....O.....O.....O.....O...
Post by Pierre Willenbrock
1. (opt)uncis (assumes color components to be laid out planar)
2. (opt)unstagger (assumes pixels to be depth*channels/8 bytes,
unshrinked)
3. (opt)shrink_lines (assumes pixels to be depth*channels/8 bytes)
4. (opt)reverse_RGB (assumes pixels to be BGR or BBGGRR))
here we should save the finished lines for use with line distance
correction 5. (opt)line_distance_correction (assumes RGB or RRGGBB)
My implementation currently used for Canon LiDE 35 does quite a lot byte
moving which considerably slows down the conversion, and is probably not
correct regarding the stagger effect.
Regards,
Pierre
I'll test and check in your patch Wednesday morning.

Regards,
Stef
Pierre Willenbrock
2005-08-30 14:51:46 UTC
Permalink
Hi
...
Post by Stéphane VOLTZ
Post by Pierre Willenbrock
Next i'd like to rewrite genesys_read_ordered_data to be more
maintainable and able to convert the cis style planar data to "chunky" data.
It is indeed a rather complicated function. Data doesn't come in an
easy form. But I don't exactly see why you want to convert to planar data
first.
What i meant was that the function needs to be able to convert from
planar data to chunky data. CIS color scans work mostly like grey scans,
but the led color is changed every line, and scancnt is incremented
every third line. This leads to whole lines of a single component in the
output data of cis scanners:

cis:
RRRR...
GGGG...
BBBB...

ccd:
RGBRGB...
Post by Stéphane VOLTZ
Post by Pierre Willenbrock
For that i need to know what the "stagger" effect exactly is. I am not
sure i got that one right.
At high motor resolution, lines are staggered, ie they aren't
horizontal lines. On pixel is on a line, the folowing colunm is on another ...
'O' are pixel of on horizontal line, '.' other lines data
...O.....O.....O.....O.....O.....O.....O
..O.O...O.O...O.O...O.O...O.O...O.O...O.
.O...O.O...O.O...O.O...O.O...O.O...O.O..
O.....O.....O.....O.....O.....O.....O...
Is that a property of the ccd-array? The high motor resolution can't
possibly be the reason for that pattern. The most error i would expect
from motor activity is a difference of a single line between the first
and the last pixel in the scanned data.
Is that pattern correct? I would expect something more like this:

...0...0
..0...0.
.0...0..
0...0...

But i would guess it heavily depends on the physical layout of the
optical cells on the ccd chip.

In the end this is a multiline operation like line distance correction,
so i will do line distance correction directly after un-staggering.
...
Post by Stéphane VOLTZ
Regards,
Stef
Regards,
Pierre
Stéphane VOLTZ
2005-08-31 06:12:50 UTC
Permalink
Hello,

I have applied your slope table patch in the experimental/genesys. I tested
it wtih my MD6571 and everything I tried worked fine.
The 'stagger' pattern is indeed :
...0...0
..0...0.
.0...0..
0...0...

I've reread the 'genesys_read_ordered_data'. It has 2 phases. First it fills
buffer with enough raw data for the second stage, which then copies data to
the backend. The complexity comes from all the possible cases when copying
raw data in the form required by the backend and frontend combination. One
thing that come to my mind is that splitting that copy in a dozen of simple
functions (one for each case) would be enough. But, since you're going after
something better, I'll wait for it.

I think it is high time you get CVS access to SANE. The one thing we will
have to mind is to discuss or warn for changes in the common code. Simple
fixes and chipset specific changes should be OK.

I am going to tune the gl646 part for the HP2400. I believe that the changes
I have in mind (mostly constants tweaking) shouldn't disturb your current
work.

Regards,
Stef
Pierre Willenbrock
2005-09-04 19:53:46 UTC
Permalink
Hi

As you might guess, i'm having another patch ready for review.
Post by Stéphane VOLTZ
Hello,
I have applied your slope table patch in the experimental/genesys. I tested
it wtih my MD6571 and everything I tried worked fine.
...0...0
..0...0.
.0...0..
0...0...
Currently the pattern is restricted to this one:
.0.0
0.0.
because the old code seemed to do it that way, and there is no variable
storing the actual width.
Post by Stéphane VOLTZ
I've reread the 'genesys_read_ordered_data'. It has 2 phases. First it fills
buffer with enough raw data for the second stage, which then copies data to
the backend. The complexity comes from all the possible cases when copying
raw data in the form required by the backend and frontend combination. One
thing that come to my mind is that splitting that copy in a dozen of simple
functions (one for each case) would be enough. But, since you're going after
something better, I'll wait for it.
I doubt it is that much better. I produced about 6 new functions, all in
two variants for single and double byte data.

There are 5 steps now:

step 0: Reading data from scanner. Delegated into its own function, but
may be moved back.

step 1:
genesys_reorder_components_(cis|cis_bgr|bgr)_(8|16) convert byte order,
planar and bgr data.

genesys_reorder_components_endian_16 converts byte order, and is only
available on big endian systems.

step 2:
genesys_reverse_ccd_(8|16) reverses the effects of ccd layout. It takes
line offsets per component for multiple pixels, thus doing line distance
correction and unstaggering in one pass. We could convert any stagger
pattern (up to 4 pixels width currently) that way.

step 3:
genesys_shrink_lines_(8|16) shrinks/enlarges lines.

step 4: copy result to frontend buffer. This is needed because the
conversion functions work on line aligned data, and we may have lines
longer than 32768 bytes, thus needing a output buffer.

I used the preprocessor to generate the 8/16 bit versions, and i think
it is a good idea to put that into an extra file, leading to two extra
files. I could expand genesys_conv.c to contain all the mentioned
functions, but then there would be two very similar implementations to
be kept in sync.
The functions may be useful for other backends, too.

I changed the way the information about the format of the scanner output
is stored. I think it is more understandable this way.

I needed 4 buffers. To handle that efficiently i added a set of buffer
management functions.

Then i completely removed dev->exposure_time. It was still used at quite
some places. If that is not okay, i can revert that.

Finally i moved the byte order detection from run time detection to
compile time detection, using the WORDS_BIGENDIAN macro defined(or
undefined) in include/config.h.
Post by Stéphane VOLTZ
I think it is high time you get CVS access to SANE. The one thing we will
have to mind is to discuss or warn for changes in the common code. Simple
fixes and chipset specific changes should be OK.
How do i get cvs access? I am already having a user on alioth.
Post by Stéphane VOLTZ
I am going to tune the gl646 part for the HP2400. I believe that the changes
I have in mind (mostly constants tweaking) shouldn't disturb your current
work.
Regards,
Stef
If this patch is okay, we need to discuss calibration. My scanner has as
black and a white strip at the beginning of the scanning area, while
other scanners seem to be different. I also need additional calibration
steps to calibrate the led exposure times to get nearly equal
scanning results for all three colors before doing shading. That
improves the quality of 16bit scans.


The attached patch still is not moving the gl841 part to any working
state. As soon as there are checkins into experimental cvs i will update
the patch on my website. It still is too large for this mailing list.

Regards,
Pierre
Stéphane VOLTZ
2005-09-06 19:56:49 UTC
Permalink
Hello,

it looks genesys_reorder_components_cis_8 and
genesys_reorder_components_cis_16 are missing from your patch.
The quick test I did hang at the end of scan (which happens when we try to
read more data than the scanning area holds). Is there a test case where a
scan succeeds ? I'd like to time how it takes for a scan. Because my main
concern is that (as you wrote in a previous mail) data may be copied too
much. For the rest, I gone through your code, and it looks sensible to me.

What I need is a test case that allow me to compare speed to make up
my mind.

Regards,
Stef
Pierre Willenbrock
2005-09-09 17:08:53 UTC
Permalink
This one should have been sent to the list. I double-checked the From:
field, but didn't realize i just removed the wrong To: field.

(sent on 2005-09-07 to Stéphane VOLTZ <***@modulonet.fr>)

Hi
Post by Stéphane VOLTZ
Hello,
it looks genesys_reorder_components_cis_8 and
genesys_reorder_components_cis_16 are missing from your patch.
They do exist. Both are generated from
FUNCNAME(genesys_reorder_components_cis) in genesys_conv_hlp.c.
FUNCNAME(fn) is #defined in genesys_conv.c to be either fn_8 or fn_16.
This is very useful for shrink_lines and reverse_ccd, as those only need
to know the type of the components(u_int8_t or u_int16t), and apart from
that are exactly the same, so the code exists only once, but is included
twice, first with u_int8_t as internally used data type and second with
u_int16_t. The #defines around the #include define which functions will
be generated.
Post by Stéphane VOLTZ
The quick test I did hang at the end of scan (which happens when we try to
read more data than the scanning area holds). Is there a test case where a
scan succeeds ? I'd like to time how it takes for a scan. Because my main
concern is that (as you wrote in a previous mail) data may be copied too
much. For the rest, I gone through your code, and it looks sensible to me.
There is still the possibility that i misunderstood the code in
genesys_gl641.c. Could you try to reduce dev->current_setup.lines to
lincnt - 1? dev->current_setup should store the format of the data
coming from the scanner. If the reading process is missing data, one of
the settings is wrong, and reducing the line number should at least
enable you to do one scan, and check that the pixel count is right.

You may have a raw.pnm generated while reading the data. It should be
helpful for determining which settings are bad.
It uses the line count and pixel count from dev->current_setup. To view
the image you probably need to reduce the line count in the file.

Concerning the copying: The data is copied at most 4 times:
(reading)-> data reordering -> line distance/stagger -> line shrink ->
memcpy to destination
That is worse than the current solution, where we have
(reading)-> line shrink -> final reordering etc. into destination

The best case stayed mostly the same:
(reading)-> memcpy to destination
versus
(reading)->final reordering etc. into destination

Adding cis support to the current solution would add a reordering before
line shrink, because of the planar nature of cis data.
Post by Stéphane VOLTZ
What I need is a test case that allow me to compare speed to make up
my mind.
Regards,
Stef
Regards,
Pierre
Stéphane VOLTZ
2005-09-11 18:51:37 UTC
Permalink
Hello

I got time to test, and have it work at 75 and 150 dpi. This let me time scan
with both methods: got exactly the same time on my 850MHz Duron. Better, the
old function produced a slight bakctracking at the beginning of the scan,
with the new function, it's now gone. So I checked it in.
600 dpi scan failed, so the new data reading function needs some fixes, but
can be done later.

Regards,
Stef
Pierre Willenbrock
2005-09-12 15:59:18 UTC
Permalink
Hi

While updating the gl841 patch for my website i noticed a small error
introduced while preparing the conversion patch.
Post by Stéphane VOLTZ
Hello
I got time to test, and have it work at 75 and 150 dpi. This let me time scan
with both methods: got exactly the same time on my 850MHz Duron. Better, the
old function produced a slight bakctracking at the beginning of the scan,
with the new function, it's now gone. So I checked it in.
That was a small fix elsewhere. After detecting the slider is at begin
of scanning area there was a wait of 500ms(iirc), before checking if
there is data available. In 500ms the scanner fills its internal buffer,
and backtracks.
I can't imagine that the scanner would report more data to be available
than there actually is, so the slider position check may go away too.
Post by Stéphane VOLTZ
600 dpi scan failed, so the new data reading function needs some fixes, but
can be done later.
The function should consume the exact amount of data given in
dev->read_bytes_left. I'm sorry to be not very helpful with that problem.

Regards,
Pierre
Pierre Willenbrock
2005-09-23 21:33:44 UTC
Permalink
Hi

I spent some time on fixing the last few bugs in the gl841 part known to
me and preparing the backend for the final inclusion of gl841 support
needed for my scanner.


The attached patch primarily adds yet another shading calibration
method, using the black and white strips at the top of the scanning
area. It also adds support for led exposure calibration needed for cis
scanners and instant power saving features.

The latter is needed because my scanner uses some gpio to completely
shut down some circuits like motor drivers and led drivers. The function
slot is called from sane_start and sane_cancel, as these seem to be the
functions at the begin and end of each scan. The version in the patch
mainly shuts down the afe.

The patch is not a full patch to get a Canon LiDE 35/50 scanner to work.
There is a patch on my private webspace which does that(see below).


Regarding the problem of the scanner not delivering any data i found
that it's only a problem of the first read after opening the scanner. So
my solution is to prepare a simple one line read, setting the usb
timeout to 1 second and then read, without checking the result(timeout
is reset to 30s afterwards). If the transmission fails, the scanner will
still think it succeeded, and later reads will work.

It is not clear to me why the scanner sometimes missends the first bulk
transfer originated from the scanner, but i suspect a bad usb
transmission, although the transfer does not generate any log messages.


I tried to implement real lineart, and got it to work most of the time.
It was a matter of setting the scanner to do lineart and then simply
pass the data on to the frontend, inverting all bits. There are still
some combinations of settings which may lead to a failed scan, as there
are some more complicated things still missing(stagger correction, line
shrinking).

Powersaving for the Canon LiDE 35(and hopefuly LiDE 50) works now, too.
I don't know if it is complete, but i could not measure a difference
between the scanner just plugged in and after a scan. My measuring
method was rather inaccurate, so i may be missing something.


As always a full patch to get Canon LiDE 35/50 to work can be found
here(will be updated to match experimental cvs):
http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2

It is now ready to be extensively tested. I guess using lineart will
reveal some problems, as mentioned above. But i stress tested the color
and gray modes to some extend using xsane and zooming the preview.


Regards,
Pierre
Luke Campagnola
2005-09-24 06:42:31 UTC
Permalink
Post by Pierre Willenbrock
As always a full patch to get Canon LiDE 35/50 to work can be found
http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2
I tried out this patch and when I run scanimage, the scanner (LiDE 35) just
makes a grinding noise. I'd like to give you more information, but I'm afraid
running the program any more will damage the scanner. This is the first
experimental genesys backend I've tried in a long time, so I'm *not*
suggesting that this was caused by the latest patch you posted.

Luke
Luke Campagnola
2005-09-24 07:11:59 UTC
Permalink
Post by Pierre Willenbrock
As always a full patch to get Canon LiDE 35/50 to work can be found
http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2
Update:

I ran the test program from http://www.pirsoft-dsl-dropzone.de/, and stopped
it after the scan head had moved a few cm, then ran scanimage again and it
worked without any grinding. I am assuming, then, that the scan head was
originally parked all the way against the front end (closest to the buttons),
and the backend expected it to start farther away from the front end.

Also, scanimage segfaulted when the head reached the opposite end of the
scanner. I ran xscanimage and tried to get a preview image, with the same
result. Here's a backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xb786c5fd in fclose () from /lib/tls/libc.so.6
(gdb) backtrace
#0 0xb786c5fd in fclose () from /lib/tls/libc.so.6
#1 0xb75a6853 in genesys_read_ordered_data (dev=0x8097070,
destination=0xbfffc620 'ÿ' <repeats 200 times>..., len=0xbfffc588) at
genesys.c:3806
#2 0xb75a866f in sane_genesys_read (handle=0x80ca330, buf=0xbfffc620 'ÿ'
<repeats 200 times>..., max_len=0, len=0xbfffc614) at genesys.c:5178
#3 0xb79efc69 in sane_dll_read (handle=0x80ca180, data=0xbfffc620 'ÿ'
<repeats 200 times>..., max_length=8192, length=0xbfffc614) at dll.c:1164
#4 0xb79eff34 in sane_read (h=0x0, buf=0x0, maxlen=0, lenp=0x0) at dll-s.c:52
#5 0x08051d0f in input_available (data=0x81535d8, source=-1,
cond=GDK_INPUT_READ) at preview.c:577
#6 0x08052767 in scan_start (p=0x81535d8) at preview.c:958
#7 0x08053cc4 in preview_scan (p=0x81535d8) at preview.c:1500


Luke
Luke Campagnola
2005-09-24 07:47:14 UTC
Permalink
Post by Pierre Willenbrock
As always a full patch to get Canon LiDE 35/50 to work can be found
http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2
Of course, the segfault was because I didn't set this business:

#ifdef SANE_DEBUG_LOG_RAW_DATA
static FILE *rawfile = NULL;
#endif

After setting that, everything works fine. Good work!


Luke
Jens Luedicke
2005-09-25 05:13:08 UTC
Permalink
Post by Pierre Willenbrock
Hi
I spent some time on fixing the last few bugs in the gl841 part known to
me and preparing the backend for the final inclusion of gl841 support
needed for my scanner.
nice work :)

random question: how can I use xsane without running it as root?
xsane doesn't find the scanner if I run it as a user.

jens


--
Jens Luedicke
web: http://perldude.de/
Henning Meier-Geinitz
2005-09-25 10:00:34 UTC
Permalink
Hi,
Post by Jens Luedicke
random question: how can I use xsane without running it as root?
xsane doesn't find the scanner if I run it as a user.
Read README.linux. E.g. here:
http://www.sane-project.org/README.linux

Bye,
Henning
Till Kamppeter
2005-09-25 16:00:27 UTC
Permalink
Post by Jens Luedicke
Post by Pierre Willenbrock
Hi
I spent some time on fixing the last few bugs in the gl841 part known to
me and preparing the backend for the final inclusion of gl841 support
needed for my scanner.
nice work :)
random question: how can I use xsane without running it as root?
xsane doesn't find the scanner if I run it as a user.
Try this:

http://www.linuxprinting.org/download/digitalimage/Scanning-as-Normal-User-on-Wierd-Scanner-Mini-HOWTO.txt

Till
Pierre Willenbrock
2005-10-13 12:33:39 UTC
Permalink
Post by Pierre Willenbrock
The attached patch primarily adds yet another shading calibration
method, using the black and white strips at the top of the scanning
area. It also adds support for led exposure calibration needed for cis
scanners and instant power saving features.
I just checked that one in into experimental cvs.

Full support for Canon LiDE 35/40/50 will follow shortly.

Regards,
Pierre
Brian J Densmore
2005-10-13 14:20:13 UTC
Permalink
Post by Pierre Willenbrock
Post by Pierre Willenbrock
The attached patch primarily adds yet another shading calibration
method, using the black and white strips at the top of the scanning
area. It also adds support for led exposure calibration needed for cis
scanners and instant power saving features.
I just checked that one in into experimental cvs.
Full support for Canon LiDE 35/40/50 will follow shortly.
Regards,
Pierre
Do you have any code that I could look at and use to add support for the
8400F and 9950F?

Thanks,

Brian JD
Pierre Willenbrock
2005-10-14 14:07:43 UTC
Permalink
Post by Brian J Densmore
Post by Pierre Willenbrock
Full support for Canon LiDE 35/40/50 will follow shortly.
Stretched that "shortly" a bit. Canon LiDE 35/40/50 support is now in
experimental cvs.
Post by Brian J Densmore
Do you have any code that I could look at and use to add support for the
8400F and 9950F?
I did a major restructuring on the gl841 part. You may want to take a
look at that.

Essentially to add support for a gl841/gl842 based scanner you need to
find out the motor acceleration curve and type(half-step, quarter step
capable), ccd settings and analog frontend settings.

All of these can be obtained from an usb sniffer log, captured while the
windows driver calibrates the scanner. I can help analyzing a sniffusb log.

You will find the ccd settings struct to be missing the gl841 ccd clock
settings. My scanner didn't need them, so i didn't add them. Just add
more fields there, as needed.

Transparent adapter support is completely missing.

We will need to add support for horizontal resolutions which do not
directly map to one of the gl841 settings(600, 1200, 2400dpi). Using
these settings the chip decides which memory layout to use, and how to
treat the dpiset setting. Technically, in 2400dpi mode you can equip the
scanner with a 43690 pixel ccd with arbitrary resolution, in 1200dpi
mode half of that.

Regards,
Pierre
Brian J Densmore
2005-10-14 18:25:26 UTC
Permalink
Post by Pierre Willenbrock
I did a major restructuring on the gl841 part. You may want to take a
look at that.
Are you referring to the patch you created? I've already applied that.
Post by Pierre Willenbrock
Essentially to add support for a gl841/gl842 based scanner you need to
find out the motor acceleration curve and type(half-step, quarter step
capable), ccd settings and analog frontend settings.
Well as for the motor acceleration, I'm not sure I need to do anything
there except
use the code that the Medion 6228 uses. At least for resolution up to
2400 xdpi.
I'm currently building a Windows machine with USB support so I can do some
USB sniffing. I am still trying to get the datasheet for the GL843, I am
hopeful
of getting that from a tech at genesys soon. I'm sure the registers are
different
from the 842. Also the 8400 is eighth step capable.
Post by Pierre Willenbrock
All of these can be obtained from an usb sniffer log, captured while the
windows driver calibrates the scanner. I can help analyzing a sniffusb log.
You will find the ccd settings struct to be missing the gl841 ccd clock
settings. My scanner didn't need them, so i didn't add them. Just add
more fields there, as needed.
Transparent adapter support is completely missing.
Any ideas on where I could steal some code from to try to make work.
I've seen the
registers in the 842 specs that need to be populated. If you'd like I
could work
on adding that to the existing scanners. Not sure if any of them are
capable.
Post by Pierre Willenbrock
We will need to add support for horizontal resolutions which do not
directly map to one of the gl841 settings(600, 1200, 2400dpi). Using
these settings the chip decides which memory layout to use, and how to
treat the dpiset setting. Technically, in 2400dpi mode you can equip the
scanner with a 43690 pixel ccd with arbitrary resolution, in 1200dpi
mode half of that.
I noticed you were using a 'non-supported' resolution on the LiDE. Why
not not just use the
resolutions that the GL84x are designed for? There is also the
possibility of using the deletion
type bit in the AVEENB register (bit 6 of reg 3)? That is the one you
were talking about
right? The 842 chip should have 1200,600,400,300,200,150,120,80 for a
1200 xdpi scanner,
by setting registers 44 and 45 (0x2C, 0x2D) and clearing the AVEENB bit.
I don't know
what the bit settings are for those resolutions though. They aren't
defined in the spec, that I can see.

Thanks,

Brian JD
Pierre Willenbrock
2005-10-15 14:14:02 UTC
Permalink
Post by Brian J Densmore
Post by Pierre Willenbrock
I did a major restructuring on the gl841 part. You may want to take a
look at that.
Are you referring to the patch you created? I've already applied that.
Just wanted to make sure you are not working with old code ;-).
Post by Brian J Densmore
Post by Pierre Willenbrock
Essentially to add support for a gl841/gl842 based scanner you need to
find out the motor acceleration curve and type(half-step, quarter step
capable), ccd settings and analog frontend settings.
Well as for the motor acceleration, I'm not sure I need to do anything
there except
use the code that the Medion 6228 uses. At least for resolution up to
2400 xdpi.
If these settings work, use them. But for optimal performance you need
to tweak the settings. AFAIR the settings for all scanners except Canon
LiDE 35/40/50 are guessed, and rather pessimistic. Provided you use the
new slope generation code(The old code doesn't fit with the gl841 part
very well).

The acceleration curve is completely independent of the horizonzal
resolution. It is even independent of the vertical resolution. The new
code uses the time per (full-, half-, quarter-, eighth-)step, derived
from the exposure time at a given resolution. Further it uses a
predefined acceleration slope, defined by its start and end speed(in
time per full step) and an exponent to make the slope slightly
non-linear. The acceleration curve for a given minimum time per step is
the predefined curve capped at that minimum time per step.
Post by Brian J Densmore
I'm currently building a Windows machine with USB support so I can do some
USB sniffing. I am still trying to get the datasheet for the GL843, I am
hopeful
of getting that from a tech at genesys soon. I'm sure the registers are
different
from the 842. Also the 8400 is eighth step capable.
My guess is that the allowed values of STEPSEL/FSTPSEL (in register
0x67/0x68) are expanded to include the value of 3 for eighth step. At
least that's what i hope, as that fits with the current code.
Post by Brian J Densmore
Post by Pierre Willenbrock
Transparent adapter support is completely missing.
Any ideas on where I could steal some code from to try to make work.
I've seen the
registers in the 842 specs that need to be populated. If you'd like I
could work
on adding that to the existing scanners. Not sure if any of them are
capable.
On the gl841 side there are no scanners currently supported which have a
transparent adapter. Perhaps there is a scanner with transparent adapter
in the gl646 part.
Post by Brian J Densmore
Post by Pierre Willenbrock
We will need to add support for horizontal resolutions which do not
directly map to one of the gl841 settings(600, 1200, 2400dpi). Using
these settings the chip decides which memory layout to use, and how to
treat the dpiset setting. Technically, in 2400dpi mode you can equip the
scanner with a 43690 pixel ccd with arbitrary resolution, in 1200dpi
mode half of that.
I noticed you were using a 'non-supported' resolution on the LiDE. Why
not not just use the
resolutions that the GL84x are designed for? There is also the
possibility of using the deletion
type bit in the AVEENB register (bit 6 of reg 3)? That is the one you
were talking about
right? The 842 chip should have 1200,600,400,300,200,150,120,80 for a
1200 xdpi scanner,
by setting registers 44 and 45 (0x2C, 0x2D) and clearing the AVEENB bit.
I don't know
what the bit settings are for those resolutions though. They aren't
defined in the spec, that I can see.
Cleared AVEENB bit means use of deletion. With deletion the range for
DPISET(reg 0x2c/0x2d) is not limited. Using averaging(AVEENB is set) you
are only allowed to set DPISET to 1/1, 1/2, 1/3, 1/4, 1/5, 1/6, 1/8,
1/10, 1/12, 1/15 of the hardware dpi setting DPIHW. You simply set these
values in DPISET(eg. DPISET=600 for DPIHW 1200 and 1/2 averaging).

What i tried to explain was, that you cannot set DPIHW for 3200dpi in
hardware. We will need to add code, which adjusts DPISET to gain the
correct averaging values(eg for DPIHW 2400, real hardware 3200xdpi,
requested 1600xdpi you would need to set DPISET to 1200).

There is already a similar problem: for speed reasons most ccd/cis chips
can be switched to a half resolution mode, making scanning a single line
twice as fast as in full resolution mode. When we switch to half
resolution, we don't change the DPIHW setting, so we need to adjust
DPISET accordingly. That code can be expanded to account for hardware
resolutions the scanner doesn't support in DPIHW.

Using half resolution mode i get averaged resolutions of 1200xdpi,
600xdpi, 300xdpi, 200xdpi, 150xdpi, 120xdpi, 100xdpi, 75xdpi, 60xdpi,
50xdpi and 40xdpi for my DPIHW 1200 scanner.

I hope i explained that more understandable now.

Regards,
Pierre
John William Dalton
2005-10-17 05:11:40 UTC
Permalink
I've managed to get sane/xsane working with my Canon LiDE 60.

I did this by compiling the experimental CVS genesys
backend (including Pierre's recent support for the LiDE35/40/50).
Before compilation I replaced every instance of the LiDE 35
USB ID (0x2213) with the USB ID for the LiDE 60 (0x221c).

I tested preview mode and scanning at 75dpi, 150dpi, 300dpi, 600dpi,
1200dpi and 2400dpi. All worked.

There were a few minor issues noticed. Unless mentioned the
scan area was set to 'full':

1) In some modes there is a 'klunk' noise after the scanning head
finishes scanning and before it starts its return journey.
Possibly the scan head is travelling just a little too far
and hitting the end of the track? This 'klunk' is not there when
the same operation is done under windows.
The nature of the klunk varies with the scan mode as below:

Preview: soft klunk

75dpi: soft klunk

150dpi: nasty klunk and short grinding noise as the scan head hits
the end of it's travel. I think the grinding noise is the gear
drive of the scan head skipping a couple of teeth as the scan head
can't go any further.

300dpi: no klunk. Nice and smooth. If the scan area is set to the
bottom quarter of the page, there is a 'klunk' as the scan head reaches
the end of its travel. The scanning is a little noisier than windows
(but it's faster??)

600dpi: no klunk. The stepper motor makes a medium noise. Under
windows it is audible, but much a quieter low level hum.

1200dpi: no klunk. The stepper motor makes a lot of noise. Under
windows it is almost silent.


2) Before each scan the scan head spends some time dithering backwards
and forwards, before commencing the scan. Some sort of a calibration
run? Under windows the scanner does not do this. I did observe though
that when the windows software was installed it spend a minute or so
doing a calibration run and storing the results.


I'm not sure if the above issues are LiDE 60 specific, or also
present with the LiDE 35. Either way, the driver seems to be a great
piece of work and just needs some fine tuning for the LiDE 60.

When I get a chance I'll try a usbsnoop on the windows driver,
put the log on my website and post a link. (I gather you are
experienced at reverse engineering USB logs Pierre? Do you
have any interest in looking at an LiDE 60 log, or guiding me
though the process?)

I also plan to do an audio recording of the scanner driven by both
sane and its windows drivers. Hopefully I can then accurately
compare scan times and by doing an FFT, and looking at the audio
spectrum, figure out whether there is any difference in the rate
at which the stepper motor is being driven.


An additional issue. When xsane starts up, it presents a list
of found scanners for em to chose from. The LiDE 60 does not appear
in this list. I have to explicitly provide the device
genesys:libusb:005:006, as reported by sane-find-scanner, on
the xsane command line. Does anyone know how to get a USB scanner
to appear in the list of available scanners?

Regards
John
Post by Pierre Willenbrock
Stretched that "shortly" a bit. Canon LiDE 35/40/50 support is now in
experimental cvs.
Henning Meier-Geinitz
2005-10-17 16:41:11 UTC
Permalink
Hi,
Post by John William Dalton
An additional issue. When xsane starts up, it presents a list
of found scanners for em to chose from. The LiDE 60 does not appear
in this list. I have to explicitly provide the device
genesys:libusb:005:006, as reported by sane-find-scanner, on
the xsane command line. Does anyone know how to get a USB scanner
to appear in the list of available scanners?
If "xsane genesys" works, check that "genesys" is listed in dll.conf.

If that's not the problem, something in the genesys backend still
doesn't look automatically for the LiDE 60 ids but accept it when you
manually tell it which device to probe.

Bye,
Henning
Pierre Willenbrock
2005-10-18 15:41:18 UTC
Permalink
Post by John William Dalton
I've managed to get sane/xsane working with my Canon LiDE 60.
I did this by compiling the experimental CVS genesys
backend (including Pierre's recent support for the LiDE35/40/50).
Before compilation I replaced every instance of the LiDE 35
USB ID (0x2213) with the USB ID for the LiDE 60 (0x221c).
I tested preview mode and scanning at 75dpi, 150dpi, 300dpi, 600dpi,
1200dpi and 2400dpi. All worked.
There were a few minor issues noticed. Unless mentioned the
1) In some modes there is a 'klunk' noise after the scanning head
finishes scanning and before it starts its return journey.
Possibly the scan head is travelling just a little too far
and hitting the end of the track? This 'klunk' is not there when
the same operation is done under windows.
Preview: soft klunk
Preview is just a regular scan(75dpi in most cases). We (currently)
don't handle that in a different way.
Post by John William Dalton
75dpi: soft klunk
150dpi: nasty klunk and short grinding noise as the scan head hits
the end of it's travel. I think the grinding noise is the gear
drive of the scan head skipping a couple of teeth as the scan head
can't go any further.
300dpi: no klunk. Nice and smooth. If the scan area is set to the
bottom quarter of the page, there is a 'klunk' as the scan head reaches
the end of its travel. The scanning is a little noisier than windows
(but it's faster??)
At 150 and 75dpi modes the stepper motor is driven at highest speed,
which is indeed faster than with the windows driver. I did a bit of hand
tuning of the acceleration/deceleration curve.

I think the deceleration is too fast(At least the first few steps. Many
later steps will then be misaligned, until the motor is at a speed below
its max start speed). Could you try to change the maximum final speed in
genesys_devices.c, lines 383 and 389. The speed there is expressed in
time per step, therefore higher value means lower speed.

Another value which can be tuned is the step count. This is the total
number of steps used for acceleration/deceleration.

genesys_devices.c:381
{{
3000, //maximum start speed, time/step
1300, //maximum final speed, time/step
50, //step count
0.8,
},

After changing anything in tat file you need to update the timestamp of
genesys.c, using touch or saving it again.

Another place you could look at is the y size of the scan area
(genesys_devices.c:456), if the scan head really hits its upper position.
Post by John William Dalton
600dpi: no klunk. The stepper motor makes a medium noise. Under
windows it is audible, but much a quieter low level hum.
1200dpi: no klunk. The stepper motor makes a lot of noise. Under
windows it is almost silent.
I need to research that a bit. I can imagine two problems:
-The scanners feature some kind of power selection for the stepper
motor, so it should be set differently for high resolution modes.
-The motor is used in full step mode although it should be used in half
step mode.
Post by John William Dalton
2) Before each scan the scan head spends some time dithering backwards
and forwards, before commencing the scan. Some sort of a calibration
run? Under windows the scanner does not do this. I did observe though
that when the windows software was installed it spend a minute or so
doing a calibration run and storing the results.
That is indeed the calibration, which is done before every scan. This is
because we do not cache the calibration results.
Post by John William Dalton
I'm not sure if the above issues are LiDE 60 specific, or also
present with the LiDE 35. Either way, the driver seems to be a great
piece of work and just needs some fine tuning for the LiDE 60.
When I get a chance I'll try a usbsnoop on the windows driver,
put the log on my website and post a link. (I gather you are
experienced at reverse engineering USB logs Pierre? Do you
have any interest in looking at an LiDE 60 log, or guiding me
though the process?)
Getting a usb log is easy. Start the sniffer, select the device, replug
it, and there you go. The larger Problem is analyzing the resulting log.
I created a script for that, which reformats the log and does some
interpretation. That output was the base for my test program.
Post by John William Dalton
I also plan to do an audio recording of the scanner driven by both
sane and its windows drivers. Hopefully I can then accurately
compare scan times and by doing an FFT, and looking at the audio
spectrum, figure out whether there is any difference in the rate
at which the stepper motor is being driven.
An additional issue. When xsane starts up, it presents a list
of found scanners for em to chose from. The LiDE 60 does not appear
in this list. I have to explicitly provide the device
genesys:libusb:005:006, as reported by sane-find-scanner, on
the xsane command line. Does anyone know how to get a USB scanner
to appear in the list of available scanners?
No idea, why it doesn't show up in xsanes scanner list.

Regards,
Pierre
Jens Luedicke
2005-08-31 11:22:24 UTC
Permalink
Hiya...

I get the following compiler errors when trying to build the
genesys backend:

***@gattaca ~ $ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: ../gcc-3.3.3/configure --host=i686-pc-linux-gnu
- --enable-languages=c++ --prefix=/usr --infodir=/usr/share/info
- --mandir=/usr/share/man --enable-__cxa_atexit --enable-threads
- --disable-nls --enable-target-optspace --with-gnu-ld --with-system-zlib
- --enable-shared
Thread model: posix
gcc version 3.3.3


***@gattaca ~/devel/sane-backends $ make
making all in include
make[1]: Entering directory `/home/jens/devel/sane-backends/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jens/devel/sane-backends/include'
making all in lib
make[1]: Entering directory `/home/jens/devel/sane-backends/lib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jens/devel/sane-backends/lib'
making all in sanei
make[1]: Entering directory `/home/jens/devel/sane-backends/sanei'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jens/devel/sane-backends/sanei'
making all in backend
make[1]: Entering directory `/home/jens/devel/sane-backends/backend'
gcc -c -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations
- -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes
- -pedantic -ansi -DHAVE_CONFIG_H -I. -I. -I../include -I../include
- -DPATH_SANE_CONFIG_DIR=/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/share
- -DPATH_SANE_LOCK_DIR=/usr/var -DV_MAJOR=1 -DV_MINOR=0
- -DBACKEND_NAME=genesys_gl646 -DLIBDIR=/usr/lib/sane genesys_gl646.c
- -fPIC -DPIC -o .libs/genesys_gl646.o
genesys_gl646.c:4300: warning: initialization from incompatible pointer type
genesys_gl646.c:4303: warning: initialization from incompatible pointer type
genesys_gl646.c:4306: warning: initialization from incompatible pointer type
genesys_gl646.c:4308: warning: initialization from incompatible pointer type
genesys_gl646.c:4309: warning: excess elements in struct initializer
genesys_gl646.c:4309: warning: (near initialization for `gl646_cmd_set')
genesys_gl646.c:4310: warning: excess elements in struct initializer
genesys_gl646.c:4310: warning: (near initialization for `gl646_cmd_set')
gcc -c -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations
- -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes
- -pedantic -ansi -DHAVE_CONFIG_H -I. -I. -I../include -I../include
- -DPATH_SANE_CONFIG_DIR=/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/share
- -DPATH_SANE_LOCK_DIR=/usr/var -DV_MAJOR=1 -DV_MINOR=0
- -DBACKEND_NAME=genesys_gl841 -DLIBDIR=/usr/lib/sane genesys_gl841.c
- -fPIC -DPIC -o .libs/genesys_gl841.o
genesys_gl841.c:4790: warning: initialization from incompatible pointer type
genesys_gl841.c:4793: warning: initialization from incompatible pointer type
genesys_gl841.c:4796: warning: initialization from incompatible pointer type
genesys_gl841.c:4798: warning: initialization from incompatible pointer type
genesys_gl841.c:4799: warning: excess elements in struct initializer
genesys_gl841.c:4799: warning: (near initialization for `gl841_cmd_set')
genesys_gl841.c:4800: warning: excess elements in struct initializer
genesys_gl841.c:4800: warning: (near initialization for `gl841_cmd_set')
gcc -c -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations
- -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes
- -pedantic -ansi -DHAVE_CONFIG_H -I. -I. -I../include -I../include
- -DPATH_SANE_CONFIG_DIR=/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/share
- -DPATH_SANE_LOCK_DIR=/usr/var -DV_MAJOR=1 -DV_MINOR=0
- -DBACKEND_NAME=genesys -DLIBDIR=/usr/lib/sane genesys.c -fPIC -DPIC -o
.libs/genesys.o
In file included from genesys.c:72:
genesys_devices.c:246: warning: excess elements in struct initializer
genesys_devices.c:246: warning: (near initialization for `Motor[0]')
genesys_devices.c:247: error: extra brace group at end of initializer
genesys_devices.c:247: error: (near initialization for `Motor[0]')
genesys_devices.c:247: error: extra brace group at end of initializer
genesys_devices.c:247: error: (near initialization for `Motor[0]')
genesys_devices.c:253: error: extra brace group at end of initializer
genesys_devices.c:253: error: (near initialization for `Motor[0]')
genesys_devices.c:259: warning: excess elements in struct initializer
genesys_devices.c:259: warning: (near initialization for `Motor[0]')
genesys_devices.c:264: warning: excess elements in struct initializer
genesys_devices.c:264: warning: (near initialization for `Motor[1]')
genesys_devices.c:265: error: extra brace group at end of initializer
genesys_devices.c:265: error: (near initialization for `Motor[1]')
genesys_devices.c:265: error: extra brace group at end of initializer
genesys_devices.c:265: error: (near initialization for `Motor[1]')
genesys_devices.c:271: error: extra brace group at end of initializer
genesys_devices.c:271: error: (near initialization for `Motor[1]')
genesys_devices.c:277: warning: excess elements in struct initializer
genesys_devices.c:277: warning: (near initialization for `Motor[1]')
genesys_devices.c:282: warning: excess elements in struct initializer
genesys_devices.c:282: warning: (near initialization for `Motor[2]')
genesys_devices.c:283: error: extra brace group at end of initializer
genesys_devices.c:283: error: (near initialization for `Motor[2]')
genesys_devices.c:283: error: extra brace group at end of initializer
genesys_devices.c:283: error: (near initialization for `Motor[2]')
genesys_devices.c:289: error: extra brace group at end of initializer
genesys_devices.c:289: error: (near initialization for `Motor[2]')
genesys_devices.c:295: warning: excess elements in struct initializer
genesys_devices.c:295: warning: (near initialization for `Motor[2]')
genesys_devices.c:300: warning: excess elements in struct initializer
genesys_devices.c:300: warning: (near initialization for `Motor[3]')
genesys_devices.c:301: error: extra brace group at end of initializer
genesys_devices.c:301: error: (near initialization for `Motor[3]')
genesys_devices.c:301: error: extra brace group at end of initializer
genesys_devices.c:301: error: (near initialization for `Motor[3]')
genesys_devices.c:307: error: extra brace group at end of initializer
genesys_devices.c:307: error: (near initialization for `Motor[3]')
genesys_devices.c:313: warning: excess elements in struct initializer
genesys_devices.c:313: warning: (near initialization for `Motor[3]')
genesys_devices.c:318: warning: excess elements in struct initializer
genesys_devices.c:318: warning: (near initialization for `Motor[4]')
genesys_devices.c:319: error: extra brace group at end of initializer
genesys_devices.c:319: error: (near initialization for `Motor[4]')
genesys_devices.c:319: error: extra brace group at end of initializer
genesys_devices.c:319: error: (near initialization for `Motor[4]')
genesys_devices.c:325: error: extra brace group at end of initializer
genesys_devices.c:325: error: (near initialization for `Motor[4]')
genesys_devices.c:331: warning: excess elements in struct initializer
genesys_devices.c:331: warning: (near initialization for `Motor[4]')
genesys_devices.c:336: warning: excess elements in struct initializer
genesys_devices.c:336: warning: (near initialization for `Motor[5]')
genesys_devices.c:337: error: extra brace group at end of initializer
genesys_devices.c:337: error: (near initialization for `Motor[5]')
genesys_devices.c:337: error: extra brace group at end of initializer
genesys_devices.c:337: error: (near initialization for `Motor[5]')
genesys_devices.c:343: error: extra brace group at end of initializer
genesys_devices.c:343: error: (near initialization for `Motor[5]')
genesys_devices.c:349: warning: excess elements in struct initializer
genesys_devices.c:349: warning: (near initialization for `Motor[5]')
genesys.c: In function `sanei_genesys_fe_write_data':
genesys.c:399: error: structure has no member named `bulk_write_register'
genesys.c: At top level:
genesys.c:628: warning: no previous prototype for
`sanei_genesys_create_slope_table3'
genesys.c: In function `sanei_genesys_create_slope_table3':
genesys.c:644: error: structure has no member named `slopes'
genesys.c:645: error: structure has no member named `slopes'
genesys.c:667: error: structure has no member named `slopes'
genesys.c:668: error: structure has no member named `slopes'
genesys.c: In function `genesys_create_slope_table4':
genesys.c:706: error: structure has no member named `slopes'
genesys.c:707: error: structure has no member named `slopes'
genesys.c:729: error: structure has no member named `slopes'
genesys.c:730: error: structure has no member named `slopes'
genesys.c: In function `sanei_genesys_create_slope_table':
genesys.c:894: error: `GENESYS_FLAG_ALT_SLOPE_CREATE' undeclared (first
use in this function)
genesys.c:894: error: (Each undeclared identifier is reported only once
genesys.c:894: error: for each function it appears in.)
genesys.c: At top level:
genesys.c:1059: error: conflicting types for
`sanei_genesys_create_gamma_table'
genesys_low.h:503: error: previous declaration of
`sanei_genesys_create_gamma_table'
genesys.c:1086: warning: no previous prototype for
`sanei_genesys_exposure_time2'
genesys.c: In function `sanei_genesys_exposure_time2':
genesys.c:1088: error: structure has no member named `slopes'
genesys.c: In function `genesys_send_offset_and_shading':
genesys.c:1242: error: structure has no member named `bulk_write_data'
genesys.c: In function `sanei_genesys_read_data_from_scanner':
genesys.c:1373: error: structure has no member named `bulk_read_data'
genesys.c: In function `genesys_dark_shading_calibration':
genesys.c:2144: error: structure has no member named `bulk_write_register'
genesys.c:2191: error: structure has no member named `bulk_write_register'
genesys.c: In function `genesys_white_shading_calibration':
genesys.c:2367: error: structure has no member named `bulk_write_register'
genesys.c: In function `genesys_start_scan':
genesys.c:3160: error: structure has no member named `bulk_write_register'
genesys.c: In function `genesys_read_ordered_data':
genesys.c:3536: error: structure has no member named `bulk_read_data'
genesys.c: In function `sane_genesys_close':
genesys.c:4530: warning: passing arg 1 of `free' discards qualifiers
from pointer target type
make[1]: *** [genesys.lo] Error 1
make[1]: Leaving directory `/home/jens/devel/sane-backends/backend'
make: *** [all-recursive] Error 1



- --
Jens Luedicke
web: http://perldude.de
Pierre Willenbrock
2005-08-31 12:18:35 UTC
Permalink
Post by Jens Luedicke
Hiya...
I get the following compiler errors when trying to build the
...
Post by Jens Luedicke
genesys.c:2144: error: structure has no member named `bulk_write_register'
genesys.c:2191: error: structure has no member named `bulk_write_register'
genesys.c:2367: error: structure has no member named `bulk_write_register'
genesys.c:3160: error: structure has no member named `bulk_write_register'
genesys.c:3536: error: structure has no member named `bulk_read_data'
genesys.c:4530: warning: passing arg 1 of `free' discards qualifiers
from pointer target type
make[1]: *** [genesys.lo] Error 1
make[1]: Leaving directory `/home/jens/devel/sane-backends/backend'
make: *** [all-recursive] Error 1
Looks like a really old genesys_low.h to me.
Stéphane, there is still the old version in experimental cvs.
Jens, please copy this file, too. At least bulk_write_register is
already defined in experimental cvs.

Regards,
Pierre
Jens Luedicke
2005-08-31 13:42:27 UTC
Permalink
Post by Pierre Willenbrock
Looks like a really old genesys_low.h to me.
Stéphane, there is still the old version in experimental cvs.
Jens, please copy this file, too. At least bulk_write_register is
already defined in experimental cvs.
I copied all the *.[h|c] files from experimental into backend/
and the list of warnings/errors is only slightly different.

the error you quoted is gone though.
--
Jens Luedicke
web: http://perldude.de/
Stéphane VOLTZ
2005-08-31 15:06:19 UTC
Permalink
Post by Pierre Willenbrock
Looks like a really old genesys_low.h to me.
Stéphane, there is still the old version in experimental cvs.
Jens, please copy this file, too. At least bulk_write_register is
already defined in experimental cvs.
Regards,
Pierre
Hello,

I checked the geneys_low.h that I forgot this morning.

By the way, are you sure ImageMagick has it wrong with 16 bits pictures ?
The 16 bits images produced by the backend are displayed fine in 'xsane' and
'display'. Only KDE can't show them correctly. If I take any random pnm file
and convert it to 16 bits (with pnmdepth), gimp-2.2 and ImageMagick display
them correctly and not KDE.
I haven't been able to find a definitive anwser on the netpbm site. But I
think the pnm currently produced are fine.

Regards,
Stef
Jens Luedicke
2005-08-31 18:07:42 UTC
Permalink
Post by Stéphane VOLTZ
I checked the geneys_low.h that I forgot this morning.
btw, the current changes don't work at all for me (LiDE 50):

scanimage: open of device genesys:libusb:001:006 failed: Error during
device I/O



- --
Jens Luedicke
web: http://perldude.de
Pierre Willenbrock
2005-08-31 18:41:33 UTC
Permalink
Post by Jens Luedicke
Post by Stéphane VOLTZ
I checked the geneys_low.h that I forgot this morning.
scanimage: open of device genesys:libusb:001:006 failed: Error during
device I/O
I prefer to not change too much at a time. The genesys_gl841.c code is
mostly the old one. The final patch will replace a large amount of code
there, but my codebase is not yet stable enough. I updated the patch on
my website, but there are no improvements over the patch posted on this
list.

http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2

Regards,
Pierre
Pierre Willenbrock
2005-08-31 21:25:26 UTC
Permalink
Hi,
Post by Stéphane VOLTZ
Hello,
I checked the geneys_low.h that I forgot this morning.
By the way, are you sure ImageMagick has it wrong with 16 bits pictures ?
The 16 bits images produced by the backend are displayed fine in 'xsane' and
'display'. Only KDE can't show them correctly. If I take any random pnm file
and convert it to 16 bits (with pnmdepth), gimp-2.2 and ImageMagick display
them correctly and not KDE.
I haven't been able to find a definitive anwser on the netpbm site. But I
think the pnm currently produced are fine.
Regards,
Stef
According to
http://netpbm.sourceforge.net/doc/ppm.html
Post by Stéphane VOLTZ
A raster of Height rows, in order from top to bottom. Each row
consists of Width pixels, in order from left to right. Each pixel is a
triplet of red, green, and blue samples, in that order. Each sample is
represented in pure binary by either 1 or 2 bytes. If the Maxval is
less than 256, it is 1 byte. Otherwise, it is 2 bytes. The most
significant byte is first.
A row of an image is horizontal. A column is vertical. The pixels in
the image are square and contiguous.
pnmdepth is not usable for this kind of test. it just duplicates each
byte(at least for maxval=65535). I used the raw data of a scan, which is
always little endian, and the output of scanimage, which is big endian.
The raw data should look like noise when viewed with a correct viewer.
Using xv i the raw data looks okay, and the final image is just noise.

My error was to think the xv program is part of ImageMagick.
ImageMagick is indeed correct. But kde gets it wrong both ways, which is
really interesting. And my gimp-2.2 is completely unable to read binary
encoded 16bit pnm("Invalid maximum value"). It only reads the plain ones.

Regards,
Pierre
Stéphane VOLTZ
2005-08-25 06:07:26 UTC
Permalink
Post by Pierre Willenbrock
Hi
The canon lide 35 is now scanning in color at any resolution. No
calibration yet. I'd like the calibration code to use a more generic
interface to the scanning logic before. But that will have to wait.
This time i want to propose a new mechanism for generating slope tables
in the genesys backend, which i implemented for my work.
In my opinion it is sufficient to describe one slope for each step type.
This slope is truncated as soon as the exposure time is reached. This
leads to a variable step count, which can be used to shorten the
acceleration/deceleration considerably.
I used slopes derived from a start step time(vstart), a final step
p[i] = (i/(steps-1))^g
t[i] = vstart*(1-p[i])+vend*p[i]
For i in 0..(steps-1).
+ less Constants
+ a means for calculating exposure time(which is limited by maximum
motor speed and number of pixels processed per line)
- variable step count
- may be not applicable to all supported scanners
- breaks the current code
I attached the code i am using.
Related to this and just out of interest: Does the gl646 expect its
slope tables to contain STEPNO*2 resp. FASTNO*2 steps, too?
Regards,
Pierre
Hello,

the slope table creation you propose is simpler, and surely good enough.
However, I'm reluctant to propagate the change to the allready supported
scanners. They would have to be tuned again, which takes time, without giving
any advantage. Since this tuning hasn't been done for your scanner, your
choice may be different.
Also, current code gives slope tables that are really close to the ones used
by the windows driver. Generally (not allways...) it is doing things for good
reasons, even we don't know them. I feel more comfortable keeking close to
the way the scanner is designed to work.
So I think we should keep both slope generation functions and add yet another
flag so that scanners can choose to use the current slope generation or the
new you are creating. At our choice we will be able to switch to the one that
suit us better.

Regards,
Stef
Pierre Willenbrock
2005-11-19 23:17:30 UTC
Permalink
Hi all,

after some e-mail exchange and bug-hunting with Stéphane the genesys
backend should now support gl646 and gl841 based scanners.
The Canon LiDE 35/40/50 scanners are now supported in cvs.

I hope we didn't break any of the currently supported scanners.

I want to thank everyone, especially Stéphane, for their input.

Regards,
Pierre
Henning Meier-Geinitz
2005-11-20 13:40:59 UTC
Permalink
Hi,
Post by Pierre Willenbrock
after some e-mail exchange and bug-hunting with Stéphane the genesys
backend should now support gl646 and gl841 based scanners.
The Canon LiDE 35/40/50 scanners are now supported in cvs.
Thanks for all your work!
As far as I know, you use a LiDE 35. So i marked this scanner's
support as "good". If you think the level of support is different,
please change it in genesys.desc.

I tested a Canon LiDE 50. To get it running, I had to uncomment its
id in genesys.conf. I changed this in CVS. I Also changed the name of
the scanners to also show the Canon LiDE 40. Also I used a build
number of 7, because the last one in CVS was already 6.

The test results for my Canon Lide 50:

Generelly: Sometimes I have a dark vertical stripe near the left
border (about 1 cm width, over the complete image). This happens in
Preview but very seldomly. Also I have vertical stripes, especially in
medium-bright areas.

Color:
75: Works, images are a bit too bright (over-imposed). Black
looks grayish and some brighter colors are nearly white.

150: Sometimes works, most of the time the scan hangs at about 95%.
I.e. there is a normal scan but the scan head stops and xsane never
displays the image. Also tested with scanimage. When it works, the
image looks like at 75 dpi. The problem depends on image width. E.g.
at a width of 20 mm, it always works at 150 dpi but not with the full
width. Sledomly, I also get a segmentation fault.

The log shows that this part is repeated endlessly in case of a freeze:
[genesys] genesys_read_ordered_data: using filters: reorder
[genesys] genesys_read_ordered_data: frontend requested 32768 bytes
[genesys] genesys_read_ordered_data: bytes_to_read=6814665,
total_bytes_read=6803082
[genesys] genesys_read_ordered_data: 3 lines left by output
[genesys] genesys_read_ordered_data: 3 lines left by input
[genesys] genesys_fill_read_buffer: start
[genesys] genesys_fill_read_buffer: reading 7723 bytes
[genesys] genesys_fill_read_buffer: failed to read 7723 bytes (Invalid
argument)
[genesys] genesys_read_ordered_data: reordering 0 lines
[genesys] genesys_read_ordered_data: completed, 0 bytes read
[genesys] sane_read: start
[genesys] genesys_read_ordered_data
[genesys] genesys_read_ordered_data: dumping current_setup:
pixels: 1287
lines: 1765
depth: 8
channels: 3
exposure_time: 5276
xres: 150
yres: 150
half_ccd: yes
stagger: 0
max_shift: 0

After the freeze or segmentation fault, the scanner is sometimes not found
anymore. Replugging fixes that.

300, 600 dpi: Works (overimposed) in full width. Doesn't work at e.g. width
100 mm (see above).

1200 dpi: Doesn't work in full width (see above). Works at e.g. a
width of 20 mm. This is much darker and has vertical stripes
(calibration problem?)

2400 dpi: Same as 1200 dpi. In addition, the image is too long (factor
2). I.e., in modes like 1200x2400 dpi the x resolution must be
"inflated" by either just duplicating pixels or, better yet,
interpolating them.

Gray:
75 dpi: Works, but is over-imposed.
150-600: see color
1200, 2400: see color 1200/2400

Lineart: similar to gray

I also did a spot check on color 16 bit and this seems to be less
over-imposed.

For now, I mark the support of this scanner as "minimal".
I marked the Canon LiDE 40 as "Untested". Can somebody please test
this scanner?

Thanks again,

Henning
Stéphane VOLTZ
2005-11-20 16:17:53 UTC
Permalink
Hello,

there are quite some issues with gl646:

- 250, 400 and 500 dpi modes fail with 'invalid argument'.
- lineart mode is broken .
- after a few scan, especially when changing dpi, I get 'color noise' instead
of pictures. Restarting the scanning program fix it.

Regards,
Stef
Pierre Willenbrock
2005-11-20 23:47:33 UTC
Permalink
Hi,
Post by Stéphane VOLTZ
Hello,
- 250, 400 and 500 dpi modes fail with 'invalid argument'.
At least in the log you sent me it fails in gl646_search_start_position,
trying to read the last 64 bytes of a scan. I am not aware of any
changes affecting that function.
Post by Stéphane VOLTZ
- lineart mode is broken .
I could change read_ordered_data to convert gray data to lineart. But
the changes to make the scanner output lineart are small: Set lineart
bit, modify read_bytes_left and words_per_line to correctly take lineart
into account(which would be setting depth correctly).
At least that did the trick for my scanner. I cannot test on a gl646, so
i am just attaching my idea of the changes needed. Please test.
Post by Stéphane VOLTZ
- after a few scan, especially when changing dpi, I get 'color noise' instead
of pictures. Restarting the scanning program fix it.
Sounds like memory corruption. Thats always hard to track down..

Regards,
Pierre
Pierre Willenbrock
2005-11-20 22:40:47 UTC
Permalink
Hi,
Post by Henning Meier-Geinitz
Hi,
Thanks for all your work!
As far as I know, you use a LiDE 35. So i marked this scanner's
support as "good". If you think the level of support is different,
please change it in genesys.desc.
It is working for me in daily use, so "good" seems to be okay.
Post by Henning Meier-Geinitz
I tested a Canon LiDE 50. To get it running, I had to uncomment its
id in genesys.conf. I changed this in CVS. I Also changed the name of
the scanners to also show the Canon LiDE 40. Also I used a build
number of 7, because the last one in CVS was already 6.
Generelly: Sometimes I have a dark vertical stripe near the left
border (about 1 cm width, over the complete image). This happens in
Preview but very seldomly. Also I have vertical stripes, especially in
medium-bright areas.
75: Works, images are a bit too bright (over-imposed). Black
looks grayish and some brighter colors are nearly white.
Seems like the shading calibration does not work correctly for you.
Grayish black is okay, i don't want to cut the color range. But brighter
colors getting near white is not.

When using SANE_DEBUG_GENESYS=255 there should be an image named
"black_white_shading.pnm" in the current working directory. It contains
a scan of the calibration area. Please send it to me.
Post by Henning Meier-Geinitz
150: Sometimes works, most of the time the scan hangs at about 95%.
I.e. there is a normal scan but the scan head stops and xsane never
displays the image. Also tested with scanimage. When it works, the
image looks like at 75 dpi. The problem depends on image width. E.g.
at a width of 20 mm, it always works at 150 dpi but not with the full
width. Sledomly, I also get a segmentation fault.
Mine does not expose such behaviour. Could you please send a complete
log with SANE_DEBUG_GENESYS=255 and SANE_DEBUG_GENESYS_GL841=255?
I already see one problem: The result of "genesys_fill_read_buffer"
really should not be ignored.
[log]
Post by Henning Meier-Geinitz
After the freeze or segmentation fault, the scanner is sometimes not found
anymore. Replugging fixes that.
300, 600 dpi: Works (overimposed) in full width. Doesn't work at e.g. width
100 mm (see above).
1200 dpi: Doesn't work in full width (see above). Works at e.g. a
width of 20 mm. This is much darker and has vertical stripes
(calibration problem?)
2400 dpi: Same as 1200 dpi. In addition, the image is too long (factor
2). I.e., in modes like 1200x2400 dpi the x resolution must be
"inflated" by either just duplicating pixels or, better yet,
interpolating them.
I must admit that i never tested 2400dpi. But looking at my logs, i see
that scanimage requests 1200x2400dpi, and we are delivering that. So,
the correct behaviour if we get different resolutions for x and y is to
use them internally, and interpolate to create an image with the maximum
of x and y resolution(2400dpi in that case)?
Post by Henning Meier-Geinitz
75 dpi: Works, but is over-imposed.
150-600: see color
1200, 2400: see color 1200/2400
Lineart: similar to gray
I also did a spot check on color 16 bit and this seems to be less
over-imposed.
16 bit doesn't use any gamma. For 8 bit there is a gamma of 2.2 or
0.4(don't remember which one), which should match what Canon does(at
least i am sending a very similar gamma table).

Thanks for your testing.

Regards,
Pierre
Henning Meier-Geinitz
2005-11-20 14:06:37 UTC
Permalink
Hi again,
Post by Pierre Willenbrock
after some e-mail exchange and bug-hunting with Stéphane the genesys
backend should now support gl646 and gl841 based scanners.
The Canon LiDE 35/40/50 scanners are now supported in cvs.
I also added the ids of the Canon LiDE 60 to the backend but didn't
enable it yet in genesys.conf. Reports about this scanner are welcome,
especially about the "klunks" reported here:
http://lists.alioth.debian.org/pipermail/sane-devel/2005-October/015059.html

Bye,
Henning
Nikolas Arend
2005-11-20 14:53:43 UTC
Permalink
Post by Nikolas Arend
Hi all,
after some e-mail exchange and bug-hunting with Stéphane the genesys
backend should now support gl646 and gl841 based scanners.
The Canon LiDE 35/40/50 scanners are now supported in cvs.
Hi,

how about the Canon LiDE 80? That one is gl841 based AFAIK, but last I
tried the CVS version I couldn't get it to work. I'll give it another
try but wanted to ask first whether it is supposed to work at all. Did
anyone manage to get it running?

Thanks and best regards,

Nick.
Henning Meier-Geinitz
2005-11-20 15:06:56 UTC
Permalink
Hi,
Post by Nikolas Arend
how about the Canon LiDE 80? That one is gl841 based AFAIK, but last I
tried the CVS version I couldn't get it to work. I'll give it another
try but wanted to ask first whether it is supposed to work at all. Did
anyone manage to get it running?
It won't work out of the box with the CVS code but you can try to get
it running by adding it's id to genesys.conf and to genesys_devices.c
(near the end, e.g. exchange the one of the LiDE 60). Most probably
it's necessary to adjust the respective canon_lide_*_model struct or
even the code itsself but it's worth a try.

Bye,
Henning
Juan Jose Pablos
2005-11-25 20:12:08 UTC
Permalink
Post by Henning Meier-Geinitz
It won't work out of the box with the CVS code but you can try to get
it running by adding it's id to genesys.conf and to genesys_devices.c
(near the end, e.g. exchange the one of the LiDE 60). Most probably
it's necessary to adjust the respective canon_lide_*_model struct or
even the code itsself but it's worth a try.
I did those changes for the Genius CPSLim 1200 USB2, but I am getting:

[genesys] sane_init: exit
[genesys] sane_get_devices: start: local_only = false
[genesys] sane_get_devices: exit
[genesys] sane_open: start (devicename = `libusb:004:005')
[genesys] sane_open: found `genius-cpslim-1200' in devlist
[genesys] init_options: start
[genesys] init_options: exit
scanimage: open of device genesys:libusb:004:005 failed: Invalid argument


what do you think that it would be the next step to follow?


Thanks!
Henning Meier-Geinitz
2005-11-25 21:17:26 UTC
Permalink
Hi,
Post by Juan Jose Pablos
[genesys] sane_init: exit
[genesys] sane_get_devices: start: local_only = false
[genesys] sane_get_devices: exit
[genesys] sane_open: start (devicename = `libusb:004:005')
[genesys] sane_open: found `genius-cpslim-1200' in devlist
[genesys] init_options: start
[genesys] init_options: exit
scanimage: open of device genesys:libusb:004:005 failed: Invalid argument
what do you think that it would be the next step to follow?
export SANE_DEBUG_GENESYS_GL841=255

to check why dev->model->cmd_set->init (dev) fails.

Bye,
Henning
Henning Meier-Geinitz
2005-11-26 12:59:56 UTC
Permalink
Hi,
Post by Henning Meier-Geinitz
to check why dev->model->cmd_set->init (dev) fails.
[genesys_gl841] gl841_init
[genesys_gl841] gl841_init_registers
[genesys_gl841] gl841_setup_sensor
[genesys_gl841] gl841_init_registers complete
scanimage: open of device genesys:libusb:004:007 failed: Invalid argument
it does not tell me much try to run it usin gdb, and these are the
4916 RIE (sanei_usb_control_msg (dev->dn, REQUEST_TYPE_OUT,
REQUEST_REGISTER,
(gdb)
5064 }
(gdb)
This is the complete line:
RIE (sanei_usb_control_msg (dev->dn, REQUEST_TYPE_OUT, REQUEST_REGISTER,
VALUE_INIT, INDEX, 1, &val));

As far as I can see this is the first command sent to the scanner. If
it fails, I guess this scanner is either not a gl841 scanner or it's
somehow blocked. Try to replug it. If it has a power supply, check if
it's properly connected.

You can also set SANE_DEBUG_SANEI_USB=255 to see why the command fails
exactly.

This is really a "Genius ColorPage-Slim 1200 USB2"? Have you checked
the vendor/product ids? They should be:
vendor=0x0458 [Genius]
product=0x2020 [CP-Slim 1200 USB2]

Bye,
henning
Juan Jose Pablos
2005-11-26 18:38:00 UTC
Permalink
Post by Henning Meier-Geinitz
You can also set SANE_DEBUG_SANEI_USB=255 to see why the command fails
exactly.
Here is the output:

[sanei_usb] sanei_usb_open: trying to open device `libusb:004:004'
[sanei_usb] sanei_usb_open: configuration nr: 0
[sanei_usb] sanei_usb_open: interface nr: 0
[sanei_usb] sanei_usb_open: alt_setting nr: 0
[sanei_usb] sanei_usb_open: endpoint nr: 0
[sanei_usb] sanei_usb_open: direction: 128
[sanei_usb] sanei_usb_open: address: 1 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-in endpoint (address 0x01)
[sanei_usb] sanei_usb_open: we already have a bulk-in endpoint (address:
0x81), ignoring the new one
[sanei_usb] sanei_usb_open: endpoint nr: 1
[sanei_usb] sanei_usb_open: direction: 0
[sanei_usb] sanei_usb_open: address: 2 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-out endpoint (address 0x02)
[sanei_usb] sanei_usb_open: we already have a bulk-out endpoint
(address: 0x02), ignoring the new one
[sanei_usb] sanei_usb_open: endpoint nr: 2
[sanei_usb] sanei_usb_open: direction: 128
[sanei_usb] sanei_usb_open: address: 3 transfertype: 3
[sanei_usb] sanei_usb_open: found interrupt-in endpoint (address 0x03)
[sanei_usb] sanei_usb_open: we already have a int-in endpoint (address:
0x83), i gnoring the new one
[sanei_usb] sanei_usb_open: opened usb device `libusb:004:004' (*dn=0)
[sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 12, value = 135,
index = 0, len = 1
[sanei_usb] 0000: 04
.............. ..
USB error: error sending control message: Connection timed out
[sanei_usb] sanei_usb_control_msg: libusb complained: error sending
control message: Connection timed out
scanimage: open of device genesys:libusb:004:004 failed: Invalid argument
Post by Henning Meier-Geinitz
This is really a "Genius ColorPage-Slim 1200 USB2"? Have you checked
the vendor/product ids?
yes, I did, and it is that product.
Henning Meier-Geinitz
2005-11-27 11:18:16 UTC
Permalink
Hi,
Post by Juan Jose Pablos
[sanei_usb] sanei_usb_open: opened usb device `libusb:004:004' (*dn=0)
[sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 12, value = 135,
index = 0, len = 1
[sanei_usb] 0000: 04
.............. ..
USB error: error sending control message: Connection timed out
So the scanner did not respond to the first command.
Post by Juan Jose Pablos
yes, I did, and it is that product.
In this case I'm afraid that it's actually not a gl841 or at least it
bahves differently than other gl841. Comparing USB logs from the
windows driver may help to find out what#s wrong.

Bye,
Henning

Loading...