Subject:
Re: Antwort: Re: USB Test-Version 41_4
From:
Gene Heskett ####@####.####
Date:
10 Feb 2002 16:19:58 -0000
Message-Id: <20020210161543604.AAA669@mail.iolinc.net@there>
On Sunday 10 February 2002 09:01 am, Jaeger, Gerhard wrote:
>On Sunday, 10. February 2002 04:51, Gene Heskett wrote:
>[SNIP]
>
>> Yeah, I know, its poor form to answer ones own posts. I did
>> take it back and got another, same model. I've been playing
>> with it for a few hours now and can say that these cheaper
>> ones don't seem to be very consistent.
>
>Why not answer its own stuff, while nobody else did it ;-)))
>
>> 1. All the OriginY settings shifted by at least 20 units. The
>> scanner actually tracks such as to make a slight
>> parallelogram, quarter of a millimeter I'd guess, of interest
>> only to architects probably.
>>
>> 2. The shading problem still exists, but is now of a different
>> form (magenta on the left inch, yellow on the right inch) so
>> I'm somewhat convinced its the variability of the paint job on
>> the calibration strip. Experimentally, I moved the
>> ShadingOriginY down to about 140 which puts the calibration
>> position actually on the end of the paper being scanned. This
>> stopped the shading, or so I thought, but the paper wasn't as
>> bright with two glass surfaces to read it thru, so everything
>> got shifted white and probably bleached out the white
>> inbalance.
>>
>> Too bad they didn't extend the glass to the rear of the unit
>> so it was in the calibration light path too.
>>
>> I figure there is a range multiplier someplace in the
>> calibration routines, one that can scale the whole thing to
>> effectively cancel the glass losses and restore the grey scale
>> to the prior range. If anyone can tell me which variable that
>> may be, and in what routine in backend/plustek-usbshading.c,
>> I'd appreciate it.
>
>I'll check this! The shading stuff is a suspect code fragment
> which I currently didn't understand very well for now...
I've been walking around in it myself, but as you said once, its
written in swahili or something, no offense to to author intended
of course.
>> 3. On this one, I had to extend the 3508 in the top line of
>> the cap file to 3588 to get it to go just barely past an A4
>> page end. I don't recall, and wasn't using the same sample to
>> scan before I got this one, but I don't think the previous one
>> would go more than a pixel or 5 past the end of a letter (11")
>> page, so that particular variable setting will need expanded a
>> bit for A4 paper users. From the looks of the drive and
>> carriage at the turnaround point, it might be able to go
>> another 50 or so pixels before hitting anything.
>>
>> 4. At 150 and 300 dpi, the stepper is fairly noisy, and in
>> fact managed to get stuck in place quite a few times, usually
>> at the active scan start position, but once or twice in the
>> home position, requireing I call kpm to kill the process, do a
>> powerdown on the scanner and restart the scan. This is maybe
>> an indication of the wrong phasing to the motor at those
>> settings? At 600 dpi, it was very quiet, and seemingly dead
>> reliable. But 100+ meg files take forever to display... I
>> sure wish I had my scope on the motor for some definitive
>> readings, but I've not yet figured out a clean way to get into
>> one of these things. :-)
>
>For the motor stuff, you might play around with the motorspeed,
>stepper phase correction and stepper motor control registers...
IMO, the motor should microstep pretty quietly if the phases are
all in a row. One could use the motor noise as a hint when
playing, but I've not played around with any of that so far.
>I will try and extract such info from the epson1250 code...
>
>> 5. What perms do I have to give this stuff so I can run it
>> non-root? I'm sick of looking at the warning signs...
>
>What do you mean? You still run the sane stuff as root?
>No need to do this - simply change the permission of your
>scanner device /dev/usb/scanner0 of whatever you use:
>i.e. chmod 666 /dev/usb/scanner0
Got that sorted thanks.
>Gene, I see a lot of postings from you 'til now. Especially
>ones concerning the shading stuff. Can you please make a short
>summary of what is the current status.
It seems to be related to the individual scanner. I took the
first one back and got another, which still suffers somewhat, but
now the right edge of the scan is fairly clean while the left
edge still has the magenta tint that blends away to white over
the first inch.
>What are the settings in plustek-devs.c, that produce a rather
> good result. Maybe Reinhard can also give us a short summary of
> his
>efforts.
>
>Thanks in advance
> Gerhard
Here are the appropriate snips from plustek-devs.c that I have.
/* Epson Perfection/Photo1250
* NS9832 + Button + CCD????
*/
static DCapsDef Cap0x04B8_0x010F_0 =
{
{
{ 27, 80 }, /* active scan start, x, y edges may show */
10, /* shading origin Y, can goto 50 before noticeable effect */
{2550, 3568}, /* end area scannable, max x, max y */
{ 100, 100 }, COLOR_BW }, /* min res, modes */
{{ 0, 0}, 0, {0, 0}, { 0, 0 }, 0 }, /* no negative yet */
{{ 0, 0}, 0, {0, 0}, { 0, 0 }, 0 }, /* no transparency's yet */
{{ 0, 0}, 0, {0, 0}, { 0, 0 }, 0 }, /* no ADF(cheap toy :) */
{1200, 1200}, /* max res */
0,
SENSORORDER_rgb,
8, /* sensor distance (focus) */
4, /* number of buttons, was 2 */
kNEC8861, /* use default settings during calibration */
0, /* not used here... */
_WAF_MISC_IO6_LAMP /* use miscio 6 for lamp switching */
};
[snip]
/* EPSON Perfection/Photo 1250 */
static HWDef Hw0x04B8_0x010F_0 =
{
1.0, /* dMaxMotorSpeed (Max_Speed) */
0.9, /* dMaxMoveSpeed (Max_Speed) */
12, /* wIntegrationTimeLowLamp */
12, /* wIntegrationTimeHighLamp */
600, /* wMotorDpi (Full step DPI) */
512, /* wRAMSize (KB) */
4, /* wMinIntegrationTimeLowres (ms) */
5, /* wMinIntegrationTimeHighres (ms) */
3000, /* ok wGreenPWMDutyCycleLow (reg 0x2a + 0x2b) */
4095, /* ok wGreenPWMDutyCycleHigh (reg 0x2a + 0x2b) */
0x02, /* ok bSensorConfiguration (0x0b) */
0x04, /* ok sensor control settings (reg 0x0c) */
0x7f, /* ok sensor control settings (reg 0x0d) */
0x13, /* ok sensor control settings (reg 0x0e) */
{0x02, 0x07, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00},
/* ?? mono (reg 0x0f to 0x18) */
{0x06, 0x16, 0x00, 0x05, 0x0c, 0x17, 0x00, 0x00, 0x08, 0x14},
/* ok color (reg 0x0f to 0x18) */
_GREEN_CH, /* ok bReg_0x26 color mode - bits 4 and 5 */
0x40, /* ok bReg 0x27 color mode */
1, /* ok StepperPhaseCorrection (reg 0x1a + 0x1b) */
0x00, /* ok bOpticBlackStart (reg 0x1c) */
0x42, /* ok bOpticBlackEnd (reg 0x1d) */
69, /* ok wActivePixelsStart (reg 0x1e + 0x1f) */
10766, /* ok wLineEnd (reg 0x20 + 0x21) */
16383, /* ok red lamp on (reg 0x2c + 0x2d) */
0, /* ok red lamp off (reg 0x2e + 0x2f) */
16383, /* ok green lamp on (reg 0x30 + 0x31) */
0, /* ok green lamp off (reg 0x32 + 0x33) */
16383, /* ok blue lamp on (reg 0x34 + 0x35) */
0, /* ok blue lamp off (reg 0x36 + 0x37) */
3, /* ok stepper motor control (reg 0x45) */
0, /* ok wStepsAfterPaperSensor2 (reg 0x4c + 0x4d) */
0x0c, /* ok acceleration profile (reg 0x51) */
0, /* ok lines to process (reg 0x54) */
0x0f, /* ok kickstart (reg 0x55) */
0x02, /* ok pwm freq (reg 0x56) */
1, /* ok pwm duty cycle (reg 0x57) */
0x0d, /* ok Paper sense (reg 0x58) */
0x41, /* ok misc io12 (reg 0x59) */
0x44, /* ok misc io34 (reg 0x5a) */
0x49, /* ok misc io56 (reg 0x5b) */
0, /* ok test mode ADC Output CODE MSB (reg 0x5c) */
0, /* ok test mode ADC Output CODE LSB (reg 0x5d) */
0, /* ok test mode (reg 0x5e) */
SANE_FALSE, /* has a lm9831? */
MODEL_NOPLUSTEK
};
And I have a sleep() call added in plustek-usbio.c to hold it for
a few seconds immediately after the lamp is turned back on, but
that has not made a noticeable difference other than killing the
time.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
98.5+% setiathome rank, not too shabby for a hillbilly
