[sane-devel] Canon LiDE 90
Hello,
OK, I'll try this tonight. What is the best : WITH or WITHOUT
SCAN_FLAG_DISABLE_LAMP ?
Regards
Guillaume
Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
Guillaume Gastebois schrieb:
Hello,
I made two tests today :
test 1 : too bright/too dard = 10/65525 WITH flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test1.tar
test 2 : too bright/too dard = 10/65525 WITHOUT flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test2.tar
Not what i expected, although the debug images are looking good.
Please try to change the first pixel used for minimum calculation to 200
at about lines 4596 and 4712:
- for (i = 0; i num_pixels; i++)
+ for (i = 150; i num_pixels; i++)
{
if (dev-model-is_cis)
val =
Regards,
Pierre
[sane-devel] Canon LiDE 90
Guillaume Gastebois schrieb:
Hello,
OK, I'll try this tonight. What is the best : WITH or WITHOUT
SCAN_FLAG_DISABLE_LAMP ?
Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
to get black levels on a white-only calibration area.
Regards,
Pierre
Regards
Guillaume
Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
Guillaume Gastebois schrieb:
Hello,
I made two tests today :
test 1 : too bright/too dard = 10/65525 WITH flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test1.tar
test 2 : too bright/too dard = 10/65525 WITHOUT flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test2.tar
Not what i expected, although the debug images are looking good.
Please try to change the first pixel used for minimum calculation to 200
at about lines 4596 and 4712:
- for (i = 0; i num_pixels; i++)
+ for (i = 150; i num_pixels; i++)
{
if (dev-model-is_cis)
val =
Regards,
Pierre
[sane-devel] coolscan3 driver
I've just committed the coolscan3 driver. It enables infrared scanning (when used with tiffscan or any other 1.1 capable fronted - lol) and has a couple of other minor improvements over coolscan2. I've also bumped sane version to 1.1.0 -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] [sane-commit] CVS update of sane-backends (configure configure.in include/sane/sane.h)
On Tuesday 19 February 2008 11:37:06 Alessandro Zummo wrote: Date: Tuesday, February 19, 2008 @ 10:37:06 Author: azummo-guest Path: /cvsroot/sane/sane-backends Modified: configure configure.in include/sane/sane.h configure, configure.in, include/sanei.h: bumped version number to 1.1.0 and enabled 1.1 frame types. -+ configure | 26 +- configure.in|8 include/sane/sane.h | 26 +- 3 files changed, 30 insertions(+), 30 deletions(-) Hi, in general I have no objections about moving forward, but has the branch in CVS been done? What I'd like to see is at least having the 1.0.x branch for maintainance and proceeding with head for the 1.1.x series (no matter if it is compatible or not). Any comments? Gerhard
[sane-devel] [sane-commit] CVS update of sane-backends (configure configure.in include/sane/sane.h)
On Tue, 19 Feb 2008 11:59:15 +0100 Gerhard Jaeger gerhard at gjaeger.de wrote: Hi, in general I have no objections about moving forward, but has the branch in CVS been done? What I'd like to see is at least having the 1.0.x branch for maintainance and proceeding with head for the 1.1.x series (no matter if it is compatible or not). Any comments? right, I forgot it. it's been a while since I last branched on a CVS... are you able to do it? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] [sane-commit] CVS update of sane-backends (configure configure.in include/sane/sane.h)
On Tuesday 19 February 2008 12:22:40 Alessandro Zummo wrote: On Tue, 19 Feb 2008 11:59:15 +0100 Gerhard Jaeger gerhard at gjaeger.de wrote: Hi, in general I have no objections about moving forward, but has the branch in CVS been done? What I'd like to see is at least having the 1.0.x branch for maintainance and proceeding with head for the 1.1.x series (no matter if it is compatible or not). Any comments? right, I forgot it. it's been a while since I last branched on a CVS... are you able to do it? Think so, but we have to revert then latest changes before branching... Anyway, I hope I'll find some time this evening for doing the branch. Ciao, Gerhard
[sane-devel] [sane-commit] CVS update of sane-backends (configure configure.in include/sane/sane.h)
On Tuesday 19 February 2008 13:56:47 Sergey Vlasov wrote: On Tue, Feb 19, 2008 at 01:29:13PM +0100, Gerhard Jaeger wrote: On Tuesday 19 February 2008 12:22:40 Alessandro Zummo wrote: On Tue, 19 Feb 2008 11:59:15 +0100 Gerhard Jaeger gerhard at gjaeger.de wrote: Hi, in general I have no objections about moving forward, but has the branch in CVS been done? What I'd like to see is at least having the 1.0.x branch for maintainance and proceeding with head for the 1.1.x series (no matter if it is compatible or not). Any comments? right, I forgot it. it's been a while since I last branched on a CVS... are you able to do it? Think so, but we have to revert then latest changes before branching... Actually, if you have a tag for the last release, you can easily start a branch from it even if something was committed to the trunk later. Yep, thanks for the hint. The TAG RELEASE_1_0_19 will be the branch point, and all commits except the latest from Allesandro will be merged. - Gerhard
[sane-devel] [sane-commit] CVS update of sane-backends (configure configure.in include/sane/sane.h)
On Tue, Feb 19, 2008 at 01:29:13PM +0100, Gerhard Jaeger wrote: On Tuesday 19 February 2008 12:22:40 Alessandro Zummo wrote: On Tue, 19 Feb 2008 11:59:15 +0100 Gerhard Jaeger gerhard at gjaeger.de wrote: Hi, in general I have no objections about moving forward, but has the branch in CVS been done? What I'd like to see is at least having the 1.0.x branch for maintainance and proceeding with head for the 1.1.x series (no matter if it is compatible or not). Any comments? right, I forgot it. it's been a while since I last branched on a CVS... are you able to do it? Think so, but we have to revert then latest changes before branching... Actually, if you have a tag for the last release, you can easily start a branch from it even if something was committed to the trunk later. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080219/bcddb0db/attachment.pgp
[sane-devel] proposal for enabling 1.1 features
On Feb 18, 2008 3:36 PM, Alessandro Zummo azummo-lists at towertech.it wrote: On Mon, 18 Feb 2008 15:32:42 -0500 m. allan noah kitno455 at gmail.com wrote: cause it is what is on the user's box. well, it is not absurd for an user to install a recent -dev package if he wants to compile a recent frontend. if a frontend author wants ease the burden of its users, we can just provide a small .h file which contains the two or three macros. i dont say that this is a likely situation, but you are requiring that all front-ends be modified to use sane 1.1 features. i guess my personal measure of what should go into sane 1.1 would be - 'does it require modification of a well-written front-end?' that pretty much limits us to well-known options and extending enums, but i think that is enough to take SANE forward without re-examining every detail of SANE 2 over and over again. i'd like some other opinions before we go much farther. allan -- The truth is an offense, but not a sin
[sane-devel] proposal for enabling 1.1 features
On Feb 19, 2008 12:57 PM, Alessandro Zummo azummo-lists at towertech.it wrote: On Tue, 19 Feb 2008 10:16:29 -0500 m. allan noah kitno455 at gmail.com wrote: i dont say that this is a likely situation, but you are requiring that all front-ends be modified to use sane 1.1 features. no, I'm not requiring this. why? an 1.0 fronted will just work. only an 1.1 frontend will have to use the mechanism to activate 1.1 features. fair enough, but why go thru all the trouble with extending existing functions? a simple well-known option would be enough? allan -- The truth is an offense, but not a sin
[sane-devel] proposal for enabling 1.1 features
On Tue, 19 Feb 2008 13:19:53 -0500 m. allan noah kitno455 at gmail.com wrote: i dont say that this is a likely situation, but you are requiring that all front-ends be modified to use sane 1.1 features. no, I'm not requiring this. why? an 1.0 fronted will just work. only an 1.1 frontend will have to use the mechanism to activate 1.1 features. fair enough, but why go thru all the trouble with extending existing functions? a simple well-known option would be enough? a well known option would solve the problem, but an user can activate it by chance. and we don't want to hassle frontend authors with emails from angry users :-D with the proposed way, only a frontend can activate it and it would even work when we will make the switch to sane 2.0 . -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Canon LiDE 90
Hello,
I modified lines 4596 and 4712 and reenable SCAN_FLAG_DISABLE_LAMP flag.
Result can be found on : http://ggastebois.free.fr/lide90_snoop/19_test1.tar
Regards
Guillaume
Pierre Willenbrock a ?crit :
Guillaume Gastebois schrieb:
Hello,
OK, I'll try this tonight. What is the best : WITH or WITHOUT
SCAN_FLAG_DISABLE_LAMP ?
Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
to get black levels on a white-only calibration area.
Regards,
Pierre
Regards
Guillaume
Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
Guillaume Gastebois schrieb:
Hello,
I made two tests today :
test 1 : too bright/too dard = 10/65525 WITH flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test1.tar
test 2 : too bright/too dard = 10/65525 WITHOUT flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test2.tar
Not what i expected, although the debug images are looking good.
Please try to change the first pixel used for minimum calculation to 200
at about lines 4596 and 4712:
- for (i = 0; i num_pixels; i++)
+ for (i = 150; i num_pixels; i++)
{
if (dev-model-is_cis)
val =
Regards,
Pierre
[sane-devel] Canon LiDE 90
Guillaume Gastebois schrieb:
Hello,
I modified lines 4596 and 4712 and reenable SCAN_FLAG_DISABLE_LAMP flag.
Result can be found on : http://ggastebois.free.fr/lide90_snoop/19_test1.tar
Okay, results look good so far:
[genesys_gl841] gl841_offset_calibration: first set: 191/683,191/482,191/76
but there must be a little bug in the code:
[genesys_gl841] gl841_offset_calibration: second set:
0/-1080773208,8/-1212144018,-1080773236/134721688
this very much looks like the variables for the second set are getting
overwritten/not initialized. Please try to find the problem(misplaced
brackets perhaps? copy+pasto when calculating the second set?), or send
the source.
Regards,
Pierre
Regards
Guillaume
Pierre Willenbrock a ?crit :
Guillaume Gastebois schrieb:
Hello,
OK, I'll try this tonight. What is the best : WITH or WITHOUT
SCAN_FLAG_DISABLE_LAMP ?
Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
to get black levels on a white-only calibration area.
Regards,
Pierre
Regards
Guillaume
Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
Guillaume Gastebois schrieb:
Hello,
I made two tests today :
test 1 : too bright/too dard = 10/65525 WITH flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test1.tar
test 2 : too bright/too dard = 10/65525 WITHOUT flag :
SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
http://ggastebois.free.fr/lide90_snoop/18_test2.tar
Not what i expected, although the debug images are looking good.
Please try to change the first pixel used for minimum calculation to 200
at about lines 4596 and 4712:
- for (i = 0; i num_pixels; i++)
+ for (i = 150; i num_pixels; i++)
{
if (dev-model-is_cis)
val =
Regards,
Pierre
