[sane-devel] sane-coolscan2.
On Tuesday 14 December 2004 10:47, Johannes Berg wrote: Hi, What do you mean? I need it? :P But do you know another tool for removing dust and scratches? I use compressed air and a very soft brush. :-) There's a recent message giving a hint that someone has implemented this in gimp-fu (and you can google for that relatively easily) johannes There is a script-fu/gimp1-plugin for the coolscan2-backend available at: www.xs4all.nl/~ljm/dirtyduster.tar Works quite well for small scratches or dust. You'll need some experimenting with enhancing the contrast in the infra-red image. Also, see http://andreas.rick.free.fr/sane/ for the original plugin. The plug-in part from my tar is practically an unchanged copy of this. Andreas also explains a bit how it works. -- (c) ljm ( xs4all)No part of this copyright message may be reproduced, read or seen, dead or alive or by any means, including but not limited to telepathy without the benevolence of the author.
[sane-devel] sane-coolscan2.
On Wed, 2004-12-15 at 00:05 +0100, Laurent-jan Dullaart wrote: There is a script-fu/gimp1-plugin for the coolscan2-backend available at: www.xs4all.nl/~ljm/dirtyduster.tar Works quite well for small scratches or dust. You'll need some experimenting with enhancing the contrast in the infra-red image. Also, see http://andreas.rick.free.fr/sane/ for the original plugin. The plug-in part from my tar is practically an unchanged copy of this. Andreas also explains a bit how it works. At one time I did port it to Gimp-1.2. Patch available there: http://www.figuiere.net/projects/dustrm/ Perhaps should I port it to 2.0 ? Cheers Hub -- Crazy French - http://www.figuiere.net/hub/
[sane-devel] sane-coolscan2.
On Wed, 15 Dec 2004 00:34:21 -0500 Hubert Figuiere hfigui...@teaser.fr wrote: At one time I did port it to Gimp-1.2. Patch available there: =20 http://www.figuiere.net/projects/dustrm/ =20 Perhaps should I port it to 2.0 ? Or 2.2. :P Cheers =20 Hub --=20 Crazy French - http://www.figuiere.net/hub/ --=20 MVH Peter Ankerst=E5l.
[sane-devel] [genesy backend] some patches and a few questions
Hello, I have worked on the genesys experimental backend to make my MD6471 work. First here are some patches: - I had to put back a MD6471 sensor since there is a little difference with the ST24: http://perso.wanadoo.fr/septieme/MD6471/03_md6471_sensor.patch - since the motors from the different scanners are different, I added a motor_type field in the device structure. I haven't created a Genesys_Motor struct since I haven't a clear idea of what it should really contain. http://perso.wanadoo.fr/septieme/MD6471/04_motor_type.patch - I have removed the parameter override in genesys_create_slope_table, and changed a little the pow() computing, since my compiler produces buggy code when 'j' is 0. http://perso.wanadoo.fr/septieme/MD6471/05_create_slope_params.patch Then comes some problems: - I believe that there's a bug in genesys_create_slope_table. We cuurently have: time_period = /* time required for full steps */ (u_int32_t) (yres * exposure_time / dev-model-base_ydpi) / (start_speed + (1 - start_speed) * t); and I think it should be (multiply instead of a divide): time_period = /* time required for full steps */ (u_int32_t) (yres * exposure_time / dev-model-base_ydpi) * * (start_speed + (1 - start_speed) * t); With the first formula (divided by (start_speed + ), I cannot reach satsifying parameters to have a good slope_table, while with the second formula (multyply by ...), I can find near perfect match with the slope tables in the USB logs. However, changing it would mean changing the start_speed and 'acceleration'. I can do it for the MD6471, but not fot the other scanners. - the MD6471 doesn't need the extensive asic test done at init, and I feel like adding a flag to optionally skip it. - another problem is the warmup function, I think this isn't warmup, but offset calibration. In th MD6471 logs, a one line scan is done with AFE offset at zero, then at a higher value, but both with a coarse gain at zero. And since this takes place where it should (right before coarse gain calibration), I really believe it is offset calibration. Lamp warmup detection is only a byproduct. - I have created for my needs a genesys_par_head() which is used instead of slow_back_home() which doesn't work for my scanner. In fact, it is really close to genesys_check_scanner_lock(). It sends the head back home by setting motor to reverse direction, 2 table scanning and steps before scan area to 65535. If parking head after moving it doesn't work, this will indeed detect if the head is locked, but doesn't seem the real goal of the function. - and last, I resurrected genesys_search_start_position(), but taylored for the MD6471, would it be OK to add it, with a device flag to control if the backend calls it ? I need this to locate the black and with stripes below the scanner's top in order to make offset and coarse gain calibration work reliably. To sum up is it OK to: - change genesy_create_slope_table() - add a flag for optional lazy init - add a genesys_park_head() and a flag to control it's use - add a flag to control the use of genesys_search_start_position(), and resurrect this function. - either modify warmup(), or create a genesys_offset_calibration with it's assorted flag Regards, Stef
[sane-devel] [genesy backend] some patches and a few questions
Hi, On Wednesday 15 December 2004 07:50, St=E9phane VOLTZ wrote: Hello, =20 I have worked on the genesys experimental backend to make my MD6471 wor= k.=20 First here are some patches: - I had to put back a MD6471 sensor since there is a little difference wi= th=20 the ST24: http://perso.wanadoo.fr/septieme/MD6471/03_md6471_sensor.patch =20 - since the motors from the different scanners are different, I added a=20 motor_type field in the device structure. I haven't created a Genesys_Mot= or=20 struct since I haven't a clear idea of what it should really contain. well, what about the PWM stuff, the MOTOR_SPEED_MAX etc? - I have removed the parameter override in genesys_create_slope_table, an= d=20 changed a little the pow() computing, since my compiler produces buggy co= de when 'j' is 0. http://perso.wanadoo.fr/septieme/MD6471/05_create_slope_params.patch Ah, that's what I've detected too in my little test-programm. Then comes some problems: - I believe that there's a bug in genesys_create_slope_table. We cuurentl= y=20 have: time_period =3D /* time required for full steps */ (u_int32_t) (yres * exposure_time / dev-model-base_ydpi) / (start_speed + (1 - start_speed) * t); =20 =20 and I think it should be (multiply instead of a divide): time_period =3D /* time required for full steps */ (u_int32_t) (yres * exposure_time / dev-model-base_ydpi) * * (start_speed + (1 - start_speed) * t); =20 With the first formula (divided by (start_speed + ), I cannot reach satsifying parameters to have a good slope_table, while with the second formula (multyply by ...), I can find near perfect match with the slope t= ables in the USB logs.=20 How did you test? Simply start the scanner and check the logs? I created a samll test-programm with the slope-table function and tried to find out the correct values, but there are too much variables. One big question will be, how to find out the correct settings for other scanners - I've no idea so far. However, changing it would mean changing the start_speed=20 and 'acceleration'. I can do it for the MD6471, but not fot the other=20 scanners.=20 Maybe these values are other candidates for the motor-struct. My problem is, how the figure out these values for my ST24 out of the USB-Logs? - the MD6471 doesn't need the extensive asic test done at init, and I fee= l=20 like adding a flag to optionally skip it. I guess this test is only for testing. Feel free to add this flag. - another problem is the warmup function, I think this isn't warmup, but offset calibration. In th MD6471 logs, a one line scan is done with AFE o= ffset=20 at zero, then at a higher value, but both with a coarse gain at zero. And= =20 since this takes place where it should (right before coarse gain=20 calibration), I really believe it is offset calibration. Lamp warmup=20 detection is only a byproduct. =20 - I have created for my needs a genesys_par_head() which is used instead = of=20 slow_back_home() which doesn't work for my scanner. In fact, it is really= =20 close to genesys_check_scanner_lock(). It sends the head back home by set= ting=20 motor to reverse direction, 2 table scanning and steps before scan area t= o=20 65535. If parking head after moving it doesn't work, this will indeed det= ect=20 if the head is locked, but doesn't seem the real goal of the function. =20 - and last, I resurrected genesys_search_start_position(), but taylored f= or=20 the MD6471, would it be OK to add it, with a device flag to control if th= e=20 backend calls it ? I need this to locate the black and with stripes below= the=20 scanner's top in order to make offset and coarse gain calibration work=20 reliably. =20 To sum up is it OK to: - change genesy_create_slope_table() - add a flag for optional lazy init - add a genesys_park_head() and a flag to control it's use - add a flag to control the use of genesys_search_start_position(), and resurrect this function. - either modify warmup(), or create a genesys_offset_calibration with it'= s=20 assorted flag Check it in, maybe I got some more ideas then for the Plustek devices. I think we should now add a new file: genesys_devices.c, where we put in all the device structures... Keep up your work on that Gerhard
[sane-devel] sane-coolscan2.
On Wednesday 15 December 2004 06:34, Hubert Figuiere wrote: On Wed, 2004-12-15 at 00:05 +0100, Laurent-jan Dullaart wrote: There is a script-fu/gimp1-plugin for the coolscan2-backend available at: www.xs4all.nl/~ljm/dirtyduster.tar Works quite well for small scratches or dust. You'll need some experimenting with enhancing the contrast in the infra-red image. Also, see http://andreas.rick.free.fr/sane/ for the original plugin. The plug-in part from my tar is practically an unchanged copy of this. Andreas also explains a bit how it works. At one time I did port it to Gimp-1.2. Patch available there: http://www.figuiere.net/projects/dustrm/ Perhaps should I port it to 2.0 ? Cheers Hub -- Julien Blache promissed to have a look at it and help port it to GIMP2. I am still running GIMP1.2, so I have no experience writing plug-ins for GIMP2 and I cannot test it. Of course, if you'd port it, you'd save him some work :-) Just wondering: how many scanners are there (apart from the coolscan series) that support an infra-red channel? And how do the backends for those scanners handle this channel; how do you get it in the GIMP? As an alpha chanel (like the coolscan) or as an additional picture (like the coolscan2)? From previous discussions about the coolscan, I remember that the SANE-standard does not really cover this. -- (c) ljm ( xs4all)No part of this copyright message may be reproduced, read or seen, dead or alive or by any means, including but not limited to telepathy without the benevolence of the author.
[sane-devel] Re: SANE LS50ED
This is a multi-part message in MIME format. --070209090002000602030408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ariel Garcia schrieb: great, then send me the code, i will test it asap to see how far is goes with that So I've been looking through the code and the specs and couldn't really find anything that differs between the LS50ED specs and the current coolscan2 code. Here's a trivial patch to enable the detection of the LS50 and LS5000, maybe this is all that is required to get these devices to work for a start. You may need to adjust usb IDs too, not sure. johannes --070209090002000602030408 Content-Type: text/plain; name=ls50.patch Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=ls50.patch --- coolscan2.c.orig2004-12-15 00:28:00.439585600 +0100 +++ coolscan2.c 2004-12-15 00:47:25.174392000 +0100 @@ -114,8 +114,10 @@ CS2_TYPE_UNKOWN, CS2_TYPE_LS30, CS2_TYPE_LS40, + CS2_TYPE_LS50, CS2_TYPE_LS2000, CS2_TYPE_LS4000, + CS2_TYPE_LS5000, CS2_TYPE_LS8000 } cs2_type_t; @@ -1769,10 +1771,14 @@ s-type = CS2_TYPE_LS30; else if (!strncmp (s-product_string, LS-40 ED, 16)) s-type = CS2_TYPE_LS40; + else if (!strncmp (s-product_string, LS-50 ED, 16)) +s-type = CS2_TYPE_LS50; else if (!strncmp (s-product_string, LS-2000 , 16)) s-type = CS2_TYPE_LS2000; else if (!strncmp (s-product_string, LS-4000 ED , 16)) s-type = CS2_TYPE_LS4000; + else if (!strncmp (s-product_string, LS-5000 ED , 16)) +s-type = CS2_TYPE_LS5000; else if (!strncmp (s-product_string, LS-8000 ED , 16)) s-type = CS2_TYPE_LS8000; @@ -2505,7 +2511,7 @@ cs2_parse_cmd (s, 25 01 00 00 00); cs2_pack_byte (s, cs2_colour_list[i_colour]); cs2_parse_cmd (s, 00 00 3a 00); - s-n_recv = 58; + s-n_recv = 0x3A; /* = 50 + 8 */ status = cs2_issue_cmd (s); if (status) return status; --070209090002000602030408--
[sane-devel] Re: SANE LS50ED
So I've been looking through the code and the specs and couldn't really find anything that differs between the LS50ED specs and the current coolscan2 code. Here's a trivial patch to enable the detection of the LS50 and LS5000, maybe this is all that is required to get these devices to work for a start. You may need to adjust usb IDs too, not sure. johannes That's my problem exactly. I've tried the patch you attached, and a few things more, without any success so far. There's one major difference between the specs and the code: the LS-50/5k doesn't support Boundary information, only Boundary2. I've changed the code (not in CVS yet) to reflect that, no success nevertheless. Andras
[sane-devel] Re: SANE LS50ED
Major A schrieb: That's my problem exactly. I've tried the patch you attached, and a few things more, without any success so far. Oh. Weird, ok. I'll keep looking. Do you have access to the technical specs of the 50/5k? There's one major difference between the specs and the code: the LS-50/5k doesn't support Boundary information, only Boundary2. I've changed the code (not in CVS yet) to reflect that, no success nevertheless. Could you send me said patch? I don't have the device (yet) but would like to look over it. Thanks, johannes
[sane-devel] [genesy backend] some patches and a few questions
On Wednesday 15 December 2004 07:50, St=E9phane VOLTZ wrote: [SNIPSNAP] - I have removed the parameter override in genesys_create_slope_table, an= d=20 changed a little the pow() computing, since my compiler produces buggy co= de when 'j' is 0. http://perso.wanadoo.fr/septieme/MD6471/05_create_slope_params.patch =20 One more comment: =2D in the patch, which I've now submitted to CVS, I moved the parameters g= and start_speed back to inside the genesys_create_slope_table() as they're somewhat static. Gerhard
[sane-devel] [genesy backend] some patches and a few questions
--qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's the OpenOffice spreadshhet I use to find correct values. Slope0 is the slope table found in log, and Slope1 the computed one. I usually tune strat speed then g. In the graph on the '2500' slide, you can see that both curves matches really well. Regards, Stef --qMm9M+Fa2AknHoGS Content-Type: application/vnd.sun.xml.calc Content-Disposition: attachment; filename=slopes.sxc Content-Transfer-Encoding: base64 UEsDBBQAANShjzFFvBOUHBwIbWltZXR5cGVhcHBsaWNhdGlvbi92bmQu c3VuLnhtbC5jYWxjUEsDBBQACAAIANShjzELY29udGVudC54bWzc vWuzXcdxJfh9fgWH4+iQezY281WVVbLkjraldnvabTta6uiZmJgPEAFKmCYJBgDqMb9+Mvcl qcp9iUedk1tGFJ84WBfn5j21dlXmqnz87D/88asvP/n981evX7z8+uef4g6ffvL8689fPnvx 9W9//ul///V/etI+/Q9/+7/87H/9xb/8/a//r3/95Scvv/jixefPf/rs5efffvX86zdPPn/5 9Rv7/yf/+t//7p/+8e8/+fTJZ5/9yzfPv/6X48v2l69++9lnv/j1Lz55eP2L7/7UJ/Z9Pvvs l//86SefPrzf/uzNs0//9mdve3Oz8evXP31Af/7p7968+eann3320r7Nyz9/GwKAzx5ef/rd H3j95k9fvvvrj6/4/svfPP/jm3d+tX/BD1/89Dfvee/jK77/8mevnv7hnV/tX2Cf+fdf/8XL H776D3/4w/4HPr4Se++f/Z+/+qfP/tPLV189/cGWP3754uv/+davP9Dvv/Trb7/6zfNX77bk 6Zun4XN5/fvf/tibP3yAv//B5M9/9/TVuz+/4yv+/Inws/d8Ivzs+y+2H/Z3b/kB22f/1cDj P//1n/788b366p1v7l/ww8/3+asX37zb8ocv+fR79n/+5dPXr3/+6etvXj1/+uz1754//zMU HqUfGP3w5z/74fUXRuwnz55//uXrv/3Z8Vn/+Xc+eXj99dOvjF7/9O3nL549/eRXT79+/cl/ //qFPZe2Kl+8fPjqL55+9eLLP/3803/39JuXr//mR770Afj0k+E7fPPizef2Sf7+6asXBz0/ e/f3//XT37386unjb/n979/+zv/RvuzLx2/83W8Pf/IBefLb518/f/Xic/vQ//Di9ev3fefP fuRz/u63nn77xkx/8+LzJ8db/LAAx3+DiZ+/xB++z3fmHc+0bUtffvvV159+/ye/eWWUefXm xfPX/uP8xjjxP5/85rkxzN7Dv9v3b/Lwx5784cUzJzPtVPXzrw5rBwvebs6rt5nz6uUffsyW h98w8Mnvnr/47e+M4LAL+bd8t5nfvn7+5OU3b1589fTLJ+OffvPq2+cfbu2bpz9u7fe/+ZXt Mc9fPfnm6W+fP3n4E794/sXTb79882M/yvEnf/rsxetvvnz6p1lLPn/+tmV8/uUPVPvm6Ss/ cI4X77fHPj8/C548/fLFb7/272DH1Kvv3+rPyJPXL7995SfWFy/+eHzoXz199dsXXz/58vkX vhrfrcTB0T989yH/5uWXz2Z+NLrrR/vuK3zHD/g/I7Q/P8A/9n35qu/bx8f38bP6HfCbl8/+ 9Lc/e6DF8d/vKPLwNr5lf/rd74xv75wMf+q7J/lHvvR49r97z+PI/O5LXz959fyb50/fPLez i77/imcPP9bx0//oz/vZ/Hd963v6mt/wfm//KQrf+nPY7vAj39T3qZN99n4/Zt3z4wvtcfnp N3/7qy/t6YKfffbdy599dn6DG98SU9/y718+/+KLjHc8r+AHfO9ff/VN7sfz61/+669S3/Ef Ut/tl3807+XbV89T3/Tvnr7OfcNfvTGfNvUdf/HNi4z3e+9zL+XYak8P9N1P+O+ffvnt8ydv /vSNn3tfvvQoZQC+25x/+GH91S0/rfvv33759Oef/vz/3v/ql39F/8+//4n94v+wX/zvP8En 3/3yr/+9/eLv7f+ffqBtHi/t9m9vmRb+67/8j1/+t5/85L/9y//4yXf2PKG//sx//Z/MyCf4 139jv/yHv5qwc/gAYYPjrykTP3T3+eFk+PMP84///OufuOn/2T9z+/9/cbs/s1/848wPwCMH 7MU2/zO82+D3srCUYYlL+YsbALsRq4zr6K//khZwDYtQ/y1WQcJeIP8GJtS9Pvz1Zzvq5q/1 L/k5nLbE2z+Fj267R+H+55/NX1283fPEdm/W7K1hbVorjDuCI1trqfs+J+z7O1OXhlyIEYnG 7eMByeWMhQb/JpzhMjyO/upizsgEZ8yanav5CCQNkKKdG9+0bbyVM5LCGW3G7qZdqv83kMah mz7dj5A0gONiwE3PwgRpygxpAPdWegf7tAU02rm1O/l9Ik3JII0gVIXKtZQmrCNpDmiRnYbq cPL6q4tJUydIY9bsArbVMJLUFu20VUglTU0hDRcoosDUwB2OkTQOlUVIQ+PxZK8uJo3OkIbq XsybQSxYT2ZuJfd00hTOFOkVsRpnuPXImQNagzPYx13fXl3MmTbBGbNm19qrYGMViXZumkua lkIaxQ5AILbZdGyBNAe0CGl09C/t1cWk6TOkUdrNndTOYtuNRju3cmeYdyJNTyFNM7eFwXZH 22riRnMgi3CmjB4N3iYpTXAGYYY0BXbkSsKMNQR5hmwoqaRxyxJYY6Ee9lagN3PE4lbjUeAq Ww0H2vDltMEZ2lDfG6lQb3ZGjWGeIVu76cl9O20wgzYFsdlGYydoV64jax6QRViDYTHw6pgb Zy5z7K+dzINsrXbBEg3d6KZg5O2sybjW2QuRdqN5wcK9Bn3vAVqDNtBHJxNu+7FmaDMjCps5 OwLVYxXGDd+RLTfqxhRRuFjs1KABVCWIqvABLRJCgYbF0Dvl+fezZkYWNnN2LN3WAS0CiXZu mCvwYYosXISoNPurSukcSOPITQ78R0iayuNi1Dt9hfeTZkYWNnPshKpM0Mie02ho+gmVoguX gsBYFBSklOAOH9BNIepHSBsZby3t1dW0mRGGzZyd6BBUbbdp0dCN7lQJzrRJUYZL6a4Jt1J7 LaPE5LRxaBHajK6+v7qaNjPSMHDZu/ZeOtgvNRhatp57240p4nCpvtFUUCpaSgyjHFrFs6Fw SNHlh9SMOmzm7EJSbCHU3Mlo6CbJu02KPFxUpFSsyuYOc7jxfoAWoU2IvuH66HtGHzZzdmlY KksthaOhmyTvNikCcWl2mqJQY8ZGGGhzQIvQZsw2w79AAu6MQmzm7NBUsXcminZukHurQCkC scVQ2Li6OkyVYyDl0BqaTW/DNmovrubMhDxs1uzYOpEWcxUkmLlhMmVyxOEu/k9Vc4g13nkf 0Bp5En3MNbMXV1NmYgm6tl0F7CjqXavU0c62ae49FKVIwxVAxZVrVWnhbHpA1qBMHSlTL6fM hC7cq1HGJdbSWeuYa2jIlpsjQSmycIVq1K6lllakR8YYcpPJHx9jysiYe9MO3s+YCU3YrNmB 7YO22JWEg5kbJO8xKZJwRTLXVxpQ97A7UOaAFqEMjGtxufs7oQh36buiMvfGGhRhQ7Z783/O nEkRhCtqQ2YqFtZhlcgZh9bgjIwb/r25t+/nzIQc3AWMM9Vooyx9zBgzJJ0zKWpwJfZ7MWi1 ciyCO5CbtIGPjzKjVtZvuxiZocyEFGzW7P64grKFruMNgiHbvZUTZ8qkKMGV/IpMSwVS7BQ5 Y9Aa15WdxvCVrs6LoAkduBPvHqz2JhTEMQO2kivnUYoKXF3Ga2I7Y1du4aryAVqDMjhGr/dm GryfMhMacMeyC9ih1EtxVWO0s2zJDnCKAlxZe1cL8FB7pegAO7QIZWDc8W87bmcqcif0X4s7 ds8np94tRKUxtgPdbotZ316Rm6L/mpm1KnhNKIUaROPMAS3CmTFouvzOgCf039YtaCoElTui jtuhIZvmZtFwigBcRQmM54Jc68mbcWgNAbiNP5m9uJozE0tg1uwkaudlBa3Qg53ZmVecIwAX rOa01CatYMy8OqA1PODWBjfBXlzNmQkF2HzJ3UJ/rAL23PaRM022e5OYz5zJkYBLMYr30qhB uIR3zhi0xtnUxsTgdnleME9owE11b7bVd2C2sIlHO3VrueIM54jAFdDI0tydCfUdxhmH1kie aWOSdrstkWyGMxMicFPYm5ZS1DyB6M8opHelyRGBzZOxQELsr9Za3GccWuPioI3ytr24mjMT IrBZs0OvrReyqAk12JlctMI5GnBtqI26hUyEopEyDq1BmdFRa/fKZO+nzIQI3IqF2lr8ss9d gdFVL5qdoMc5IrBviAyFiar2eNd0QItwZjyayuVH04QIbNbsAEK1o9Q25pDfbeeZMDkSsHrH q+ZtrgpK9GUMWqTsoI2tduzF1YSZkIDNJbBFkNab1Krh/BTZbtPG3s6ZHA1Y+6E/KjIVigeT Q4tsMmNafLu8K6NMaMCN2y7NvMlO3faacZPhln0wSY4G3Jg8zb3YLiMYDyaHFomzx+xme3E1 Z2Y0YKZd0CKmZmFIG/s3G5JdpCI5GnCrXmwgAlhPYfaBrEGZ8PjS1V2vZEYCpmr+L2svngg8
