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 Regards Guillaume Pierre Willenbrock a ?crit : > Guillaume Gastebois schrieb: >> Hello, >> >> I try both {0x00, 0x3f, 0x03, 0x26}, and {0x00, 0x3f, 0x00, 0x26}, >> you can find result under : >> http://ggastebois.free.fr/lide90_snoop/17_test1.tar >> and http://ggastebois.free.fr/lide90_snoop/17_test2.tar > > Looks a lot better. The offset*.pnm actually show a black image, > coarse.pnm is gray. That is good. > > I suspect you are still running with the change in thresholds?: > @@ -4545,9 +4546,9 @@ > val = > first_line[i * 2 * channels + 2 * j + 1] * 256 + > first_line[i * 2 * channels + 2 * j]; > - if (val < 10) > + if (val < 1000) > cmin[j]++; > - if (val > 65525) > + if (val > 40000) > cmax[j]++; > } > > Please undo that change. Should give you a nice 2-3-step offset > calibration, that actually works(at least i hope so). > > Regarding the output format of the AFE, stay with {0x00, 0x3f, 0x03, > 0x26} for now. This does not seem to make any difference, but there are > suspicously many 16 bit words with the binary pattern > ".... .fgh .fgh ...."(that is, the two middle nibbles share the lower 3 > bits). We may be sampling the digital image data at the wrong times. As > the most significant byte seems to come through correctly, this does not > need immediate fixing. (On a second thought, this may affect the offset > calibration. See the thesholds. We'll see.) > > Regards, > Pierre > >
