[sane-devel] SANE2 standard revisited: image data format

[Henning Meier-Geinitz]

Hi,

On Mon, Dec 09, 2002 at 11:51:29AM -0500, Matto Marjanovic wrote:
> The only snag is that for PLANAR formats, the image size needs to be known
>  ahead of time (because the image data is simply one plane after the other,
>  with no separators).  This means that a PLANAR format is incompatible with
>  old sheet-fed scanners that determine the number of lines when they reach
>  the end of the page.  But those sheet-fed scanners do not do multi-pass
>  scans *anyway*, so it is no problem.

Well, the frontend can just buffer all the data (to RAM or disk). When
it's finished, it will know how much lines it is because lines and bpl
are the same for all planes of the frame so just use total_bytes /
(depth / 8) / channels / bpl or something like that to get the lines.
Now interleave the the channels. Not nice, but possible.
And as you said, not really a problem.

I think the test backend is the only one that implements handscanner +
threepass mode.


[MIME]
> I didn't like the idea at first, either, but now it doesn't bother me so
>  much --- as long as there is no expectation of doing anything more than
>  saving the data as a file.  It should be noted in the standard that the
>  intent of this option is to support those specialized scanners which 
>  support on the fly page-compression, barcode reading, OCR, and stuff
>  like that.

I'm working with Oliver on how to phrase that.

>  >| # SANE_PFLAG_MORE_IMAGES (bit 1, bitvalue 2) is set to 1 to indicate
>  ...
>  >So this flag is intended to flag the availability of some sort of ADF,
>  >or film holder? I didn't understand this on my first read. Maybe
>  >rewrite like this:
>  >
>  >"# SANE_PFLAG_MORE_IMAGES (bit 1, bitvalue 2) is set to 1 to indicate
>  >   further pending images. The frontend is expected to call sane_start
>  >   again after the end of the current scan to get more images, e.g. from an
>  >   automatic document feeder. It is permissible to set that value to 1
>  >   "in ..."
> 
> Yeah, that is more clear, but I haven't quite thought out the code-flow
>  involved...

No change in code_flow. Just means, that the backend calls sane_start
again without asking the user before. Like in scanadf or the batch
mode of scanimage.

>  >| The members dpi_x, dpi_y encode the horizontal and vertical
>  >| resolution.
>  >
>  >Which value to use if the resolution is unknown (e.g. for cameras)?
> 
> How about "-1" used to represent "unknown/unspecified" for all the fields,
>  since all the numeric fields should be >0 if they are valid.

Yesm I have uses -1 for every int now. Will be in CVS as soon as it
works again.

>  ...
>  >Maybe:
>  >
>  >" Member bytes_per_line specifies the number of bytes that comprise one
>  >  scan line. For SANE_FRAME_MIME, this value may not be applicable and
>  >  must be set to 0. In this case the frontend should call sane_read()
>  >  until SANE_STATUS_EOF is returned."
> 
> It might be good for the backend to be able to suggest a maximum image data
>  size --- this would allow a frontend to allocate a sufficient image buffer
>  ahead of time --- useful if the image is not simply getting written to disk.

Looks reasonable for MIME types like text.

Bye,
  Henning