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