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

[Matto Marjanovic]

Wow, am I late getting into this longgggg thread... (better late than never).

 >On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
 ...
 >I guess the image format is the most controversal point so I'll start
 >with that one. Please keep calm everyone, I don't like to create a
 >flamewar again :-)
 >
 >| Section 3.2 (Image Data format):
 >http://www.meier-geinitz.de/sane/sane2/0.07/doc008.html
 >
 >| 3.2.1 Pixel oriented frames
 >
 >I like the approach with SANE_FRAME_RAW and textual descriptions of
 >the channels. But: SANE1 was complicated enough and provided many pitfalls.
 >Remember 1 bit bit-order issues? With SANE2 it's even more complicated
 >because you have more options. E.g. you could do a scan with 4
 >channels and two frames: "red" and "green,infrared,blue". Oh well.
 >
 >So the question is: do we really need the concept of a frame? Is there
 >any other use than in the old three-pass-scanners? Couldn't the
 >backend just buffer the image data and transfer it using rgb frames
 >for these old scanners? The frontend have to buffer the image anyway.
 >
 >Removing the frame paradigm would at least save us one pitfall.

I agree:  I think "frames" are the wrong solution to the problem.

The problem, as I understand it, is to reduce the memory and/or processing
 requirements of the backend (which may be running on some dinky little
 machine used as a scanner server).  The goal was to allow the backend's
 image transmission layer to be as thin as possible when used with 3-pass
 scanners, which naturally transmit one plane at a time.

So, how about this:  remove the "frames" concept altogether.  The whole
 notion of calling start_scan() repeatedly to scan the same document was
 always rather gruesome anyway.

Instead, we give the choice of a PACKED (i.e. byte-interleaved) format,
 or a PLANAR (i.e. one channel of the image at a time) format.  For the
 PLANAR format, useful for multi-pass scanners, the backend just does
 the multiple passes on its own, and transmits the data one pass at a 
 time.  The frontend does not need to know if the scanner is multipass
 or not.

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.

No "frames", no issue of "how many channels per frame?", no more silliness
 with multiple start_scan()'s....

 >| 3.2.2 Arbitrary data frames
 >
 >I'm still not sure if MIME is the right approach (instead of e.g.
 >SANE_FRAME_JPG or other specific frame types). 
 >I fear that increasing usage of strange MIME types leads to backends
 >that can be only used with one frontend and vice-versa. 
 >
 >That said, I can live with the both frame types and won't oppose them.

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.

 >| 4.3.8 sane_get_parameters
 >http://www.meier-geinitz.de/sane/sane2/0.07/doc012.html#s4.3.8
 ...
 >| # SANE_PFLAG_LAST_FRAME (bit 0, bitvalue 1) is set to 1 if and only if
 >| the frame that is currently being acquired (or the frame that will be
 >| acquired next if there is no current frame) is the last frame of a
 >| multi frame image (e.g., the current frame is the blue component of a
 >| red, green, blue image). Note, that it is possible to transmit
 >| multiple images in succession.
 >
 >It has to be set to 1 for single-frame images, too!
 
Get rid of this altogether, along with frames.

 ...
 >| # 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...


 >| 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.

 ...
 >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.


-matt m.