On Sat, 2008-06-07 at 22:09 -0400, m. allan noah wrote: > > JPEG output works fine. I?s the compression done by the scanner or the > > backend? > > the scanner itself. it appears that every fi-series Fujitsu might be > able to do this. >
When I was on windows I noticed that the jpeg quality was pretty bad compared to scans from my flatbed compressed to the same file size. But then, the windows software applied a very 'happy' color adjustment, which could not be changed, and which really made the compression artifacts stand out - and uncompressed output was not available. Better redo those tests now... > > 2. The mechanism for determining the color interlace mode is now > > automatic, so please see if color scans look weird, particularly if > > the scanner has done a color scan in windows without being power > > cycled. > > > > Not really tested, but no problems observed. > > if a non-jpeg color scan looks ok, then that is all the testing we need > really. > All good then. > > ?[...] > > The page-height option works as expected in combination with > > dfdetect=Length except that dfdiff seems to be fixed at 10mm. > > odd. do you get an error when you set the other lengths? > No, the value is just ignored. The fixed difference may actually be 12 mm, but maybe there is some tolerance to these values? > A long page > > (paper jam) occurring as the last sheet of a batch is detected only on the > > next invocation of scanimage. (May be a limitation of the scanner's > > detection mechanism, or a scanimage issue?) > > hmm, i need to look into that. it is possible that the scanner does > not report the error to us until after the page is fully sent, so > there is no way to inform the front-end. > It is not a big issue, but of course it would be more elegant to always have it detected. > > Some additional observations about this scanner, for the record: > > ?[...] > > - the overscan option seems to be ignored, although I am not sure I fully > > understand its purpose. The output looks identical, with no additional space > > at the top. What is the bgcolor option mentioned in the --help -d output? > > when overscan is enabled, the x and y values of the scan area can > extend slightly larger than the page width, and the scanner outputs a > few mm of the background before the top of the page hits the sensor. > if your machine has a white background stripe behind the sensor, try > scanning a darker sheet and see if the white background shows above. > It does not. For the same values of t, l, x, y the scans with and without overscan are as identical as can be expected. > the bgcolor option is only for scanners which have a servo driven > black/white background in the adf, such as the fi-5120C > Aha... :-) Best regards, Jacob Nielsen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080608/e5b313fd/attachment.htm
