Re: Pixels vs. Bytes per Line

becka@rz.uni-duesseldorf.de
Wed, 21 Oct 1998 03:17:35 +0200 (MEST)

> I've encountered the following ambiguity:
> scanimage seems to rely on params.bytes_per_line,
> xscanimage for the real scan, too, whereas
> for the preview on params.pixels_per_line.

This is probably because the preview actually interprets the image.
However it should not be used for _reading_ the data. Just for interpreting
it.

> Mustek scanners have problems in color mode with
> odd resolutions (i.e. different from 75, 150,...).
> So resolution is increased to the next even one and
> the image scaled according to the desired one.
> But I forgot to update params.pixels_per_line causing xscanimage to
> crash sometimes.

This is a bug. Both values are guaranteed to be correct.

> But it is intention to have this (except for lineart)
> redundancy? Which is the authoritative variable?

Both. They are not redundant, as modes that have a depth that is not a
multiple of 8 bits might require padding.

Thus you always read bytes_per_line * lines bytes (except if lines==-1,
handscanner mode). Well actually at best you read until sane_read
returns SANE_STATUS_EOF.

The pixels_per_line is there for informative purposes regarding clipping at
the right edge, padding, etc.

Note that the number of bytes per line can be larger than the minimum
value imposed by the right side of this equation. A frontend must be
able to properly cope with such `padded' image formats.

CU,ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com