Hi,
Surprised by some of the values I was getting in a custom frontend I was
writing, I tried a test using scanimage to be sure it wasn't me. Low and
behold...
% scanimage -x 25.4 -y 25.4 --resolution 100
i.e a 1 inch by 1 inch image, at 100 dots per inch should produce an image
of 100 by 100 pixels.
However it produces an image of 96 by 99 pixels.
Looking at epson.c, sane_get_parameters() line 3767/8 I see there is a
rounding problem when determining the number of pixels :-
s->params.pixels_per_line =
SANE_UNFIX( s->val[ OPT_BR_X].w - s->val[ OPT_TL_X].w)
/ 25.4 * ndpi;
s->params.lines =
SANE_UNFIX( s->val[ OPT_BR_Y].w - s->val[ OPT_TL_Y].w)
/ 25.4 * ndpi;
Should be :-
s->params.pixels_per_line =
SANE_UNFIX( s->val[ OPT_BR_X].w - s->val[ OPT_TL_X].w)
/ 25.4 * ndpi + 0.5;
s->params.lines =
SANE_UNFIX( s->val[ OPT_BR_Y].w - s->val[ OPT_TL_Y].w)
/ 25.4 * ndpi + 0.5;
With the original test, this results in an image of 96 by 100 pixels.
The reason for 96 pixels is on line 3833 where the pixels per line are
rounded down to the nearest multiple of eight (i.e 96, 104, 112...)
s->params.pixels_per_line = s->params.pixels_per_line & ~7;
Why does it do this ? Is it a limitation of the driver, or of Epson
scanners, and if so, why does it not round up, and throw away the unwanted
pixels ?
In a similar vein, is there not also a rounding problem in the definition of
SANE_FIX()
#define SANE_FIX(v) ((SANE_Word) ((v) * (1 << SANE_FIXED_SCALE_SHIFT)))
Should this not be ?
#define SANE_FIX(v) ((SANE_Word) (0.5 + (v)
* (1 << SANE_FIXED_SCALE_SHIFT)))
Cheers,
Guy
