Hi, Guillaume Gastebois schrieb: > Hello, > > I updated from CVS and modified flag GENESYS_FLAG_DARK_WHITE_CALIBRATION > in GENESYS_FLAG_DARK_CALIBRATION. > > Summary of current modifications : > genesys_devices.c : see attachment > genesys_gl841.c : added SCAN_FLAG_DISABLE_LAMP (line 4461), > commented "status = gl841_feed(dev, 280)" (line 4241 and 4843), modified > 0 to 150 in "for (i = 150; i < num_pixels; i++)" (line 4617 and 4733). ^^^ 450 is probably still better. > > Tonight I play with 52-57 regs. > > I test 01/03/00/00/00/00, 01/04/00/00/00/00, 01/05/00/00/00/00, > 02/03/00/00/00/00, 02/04/00/00/00/00, 02/05/00/00/00/00.
None of these are perfect, the best seems to be 2/4. I thought a bit about these results, and conclude that this scanner does not use a WM819x, which can output 2*8 bits, but instead uses one which only does 4*4bits. This also matches that the chip did not react when changing the data output mode. As the GL842 cannot handle that format, another chip is put in between, converting the 4*4 to 2*8bits. This way, when the analog frontend is located in the scanning head, it is only needed to wire 4 data pins instead of 8. For correct timing, this seems to need additional clocks. We seem to be always sampling on the signal edge, which leads to the glitches in the data. (The chip in between is very probably the VHC175, latching its inputs on the higher 4 bits from the AFE. Then, when the lower 4 bits are available, the GL842 reads them directly from the AFE, together with the high bits from the VHC175. Just the clock used by the VHC175 is not known.) So, we need to check what parts of the clocking we need to setup differently. Candidates: reg sane windows 0x1a 0x00 0x24 enable clock 3,4 manual output, invert clock 4 0x1d 0x04 0x02 just a smaller toggle "shoulder". 0x71 0x00 0x05 RS signal seems to be not used. 0x72 0x00 0x07 CP signal seems to be not used. 0x73 0x00 0x09 CP signal seems to be not used. 0x75 0x00 0x01 clock 1 bitmap 0x76 0x00 0xff clock 1 bitmap 0x79 0x00 0x3f clock 3 bitmap 0x7c 0x00 0x1e clock 4 bitmap 0x7d 0x00 0x11 change RS on falling edge of system clock, use DLY 0x7f 0x00 0x50 delay each of BSMP and VSMP by 8.33ns (DLY) The clock 1 stuff seems to be not needed, as it is in automatic mode. But clock 3/4 look interesting. The delay of BSMP/VSMP may be useful, too. > Result of experiment can be found on : > http://ggastebois.free.fr/lide90_snoop/21_tests.tar > > Is that true that as written in genesys_devices.c : "/*[GB](HI|LOW) not > needed for cis */" because bests results are found with regs 52-57 with > 01/03/05/07/09/11 !! Results of this test on : > http://ggastebois.free.fr/lide90_snoop/21_test2.tar Sorry, that one does look no better than the 01/03/00/00/00/00 variant. Anyway, color scans would be missing colors if [GB](HI|LOW) were used. > Another thing : I always have a brither vertical line where there is a > small black rectangle in the calibration area. The small black rectangle is included when acquiring the white level. Reduce shading_lines(second to last entry) in Genesys_Model to 250, that way it is not seen anymore. > To finish, I find that images seems to be more in relief as reality. Do > you understand what I say ? To speak clearly, when there is 0.1mm real > relief between paper and glass, on the image we have an impression of > 1mm relief ! Why ???? I don't know if you think of the same thing as i do, but the light and optics are probably looking at the original at an angle, thus increasing the size of shadows and other structures. > Regards > Guillaume > P.S. : Where is located this new code for GENESYS_FLAG_DARK_CALIBRATION > ? I used meld to see differences between my genesys_gl841.c file and > this from CVS and only see my modifications !!! The only thing that was missing was disabling the lamp when the genesys_dark_shading_calibration requests that. That change is just the small bit in genesys_gl841.c, gl841_set_lamp_power. Oh, and please update from cvs again. A small mistake in gl841_bulk_write_registers made the debug register dumps useless. Regards, Pierre > Pierre Willenbrock a ?crit : >> Pierre Willenbrock schrieb: >>> Hi, >>> >>> Guillaume Gastebois schrieb: >>>> Hello, >>>> >>>> So, what's the next step ? Re-enabling shading ? >>> Yes, but only after the shading-calibration is able to get black level >>> information.(This really needs a better api..) >> >> I commited a prerequisite for shading calibration to work for your >> scanner. When enabling shading, update from cvs and then use >> GENESYS_FLAG_DARK_CALIBRATION instead of >> GENESYS_FLAG_DARK_WHITE_CALIBRATION. >> >> Regards, >> Pierre >> >>>> Do you think that last modification "for (i = 150; i..." is necessary ? >>> Yes. Some time back, that part of the code just used the middle half of >>> the scan, exactly to drop the dummy black pixels at the begin. That >>> didn't work too well, missing some low black levels. >>> >>>> Is it time to fine tune registers 52... ? >>> Try increasing register 53, 55, 57 by one. Attached is a small program, >>> that shows the probability of any two-byte pair appearing in a file. It >>> takes the file as input and dumps an portable anymap(pnm) as output. >>> I created that program for something completely unrelated, but it proved >>> useful. >>> >>> I used it on offset1_1.pnm(as offset1_0.pnm is only black). >>> The image should show a fuzzy vertical and horizontal bar, near >>> top/left. Currently, the horizontal bar is more a line, the vertical bar >>> is correct(it shows the relationship between the low byte of one pixel >>> and the high byte of the _next_ pixel). >>> >>>> Regards >>>> Guillaume >>> Regards, >>> Pierre >