I've tried to pull together some of the information that has been
passed back and forth on the issue of frame types and offer the following
summary in the form a proposed addition to the SANE 1.0.1 standard. I'm
thinking that this can be handled as a minor update, rather than a 2.0
thing, but I'll leave that up to those more understanding of such issues.
I also have stayed away from the discussion surrounding the negotiation
of supported formats, and middle-layer conversions. These sound like
useful features, but are sort of beyond my abilities at this point.
Instead, I'm trying to concentrate on the definition of the formats.
SANE Frame Formats
I suggest adding the following language to section 3.2.1 Image
Transmission in the section introduced by "This version of the SANE
standard supports the following frame types":
SANE_FRAME_JFIF: The frame contains a JPEG File Interchange Format
encoded datastream representing a compressed image. The image
consists of this frame only. The values specified in
the SANE_Parameters structure represent the parameters of the
decoded image.
SANE_FRAME_G31D: The frame contains a CCITT Group 3 1 Dimensional
encoded datastream representing a greyscale image of pixel depth 1.
The image consists of this frame only. The values specified in
the SANE_Parameters structure represent the parameters of the
decoded image.
SANE_FRAME_G32D: The frame contains a CCITT Group 3 2 Dimensional
encoded datastream representing a greyscale image of pixel depth 1.
The image consists of this frame only. The values specified in
the SANE_Parameters structure represent the parameters of the
decoded image.
SANE_FRAME_G42D: The frame contains a CCITT Group 4 2 Dimensional
encoded datastream representing a greyscale image of pixel depth 1.
The image consists of this frame only. The values specified in
the SANE_Parameters structure represent the parameters of the
decoded image.
SANE_FRAME_JBIG: The frame contains a JBIG (Joint Bi-level Image
Experts Group) encoded datastream representing a greyscale image
of pixel depth 1. The image consists of this frame only. The
values specified in the SANE_Parameters structure represent the
parameters of the decoded image.
SANE_FRAME_ASCII: The frame contains a stream of ASCII text. This
"frame" is not actually image data at all. Typically this is used
to support acquisition devices which are capable of decoding barcodes
and/or patch codes. The actual content of the text is not defined by
the SANE standard; rather, it is defined by the individual SANE backends.
This is a single frame format. The values specified in the
SANE_Parameters structure should be: depth = 0, pixels_per_line = 0,
bytes_per_line = 1, and lines should contain the number of bytes in
the frame or -1 if this not known a priori.
SANE_FRAME_RAW: The frame contains a stream of bytes that should not
be interpreted by the frontend in any way. This is a single frame
format. The values specified in the SANE_Parameters structure
should be: depth = 0, pixels_per_line = 0, bytes_per_line = 1, and
lines should contain the number of bytes in the frame or -1 if this
is not known a priori.
Currently in sane.h we have:
typedef enum
{
SANE_FRAME_GRAY, /* band covering human visual range */
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
SANE_FRAME_BLUE /* blue band only */
}
SANE_Frame;
I propose changing to:
typedef enum
{
SANE_FRAME_GRAY, /* band covering human visual range */
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
SANE_FRAME_BLUE /* blue band only */
SANE_FRAME_JFIF /* JPEG File Interchange Format */
SANE_FRAME_G31D /* CCITT Group 3 One-Dimensional */
SANE_FRAME_G32D /* CCITT Group 3 Two-Dimensional */
SANE_FRAME_G42D /* CCITT Group 4 Two-Dimensional */
SANE_FRAME_ASCII /* ASCII text */
SANE_FRAME_RAW /* RAW bytes */
}
SANE_Frame;
An important issue will be the backward compatibility with front ends.
I see it as a minor issue, since the newly added frame types will have to
be "asked for" by the user by choosing the appropriate options. Here
are my thoughts on that.
Backward compatibility with existing frontends:
When a new frame type (JFIF, G31D, G32D, G42D, etc) is received by
existing front ends, I'd expect that there might be some different
behaviors exhibitted. The issue is how they handle an unexpected frame
type. A frontend might:
1) scream, yell and abort the operation.
2) pass the data onwards without interpretation.
3) try to put a PNM style header on it.
I'd suggest that the "best" behavior for a particular front-end need
not be specified in the SANE standard.
A command-line front-end like scanimage should probably do number 2),
meaning writing the data unmolested, and uninterpreted to stdout.
Perhaps a warning could be issued in verbose mode.
A gui front-end like xsane which has all that support for different
file saving formats and such, might choose 1). After all, it's a
highly interactive application and the user could intervene, choose
a different set of options which will result in the backend sending
a SANE 1.0 frame type and redo the scan. I'm sure that Oliver would
add much more robust and useful behavior, provided that the format
is sufficiently well defined and he judges that his users will benefit.
I think that number 3) would be a bug and would need to be fixed,
because by prepending the header to the unknown frame, the front-end
will have effectively corrupted the data stream.
NOTE: This is how I understand scanimage behavior when encountering
an unexpected frame type:
1) if the FRAME does not need to be buffered (lines >= 0)
The output will be the raw data with a PNM header prepended.
2) if the FRAME needs buffering (lines < 0, size not known a-priori)
The output will be a PNM header only.
Niether one of these is useful behavior and would necessitate a minor
change to scanimage. I'll volunteer to make that change.
Looking forward to comments.
Tom Martone
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com