Re: SANE_FRAME Formats (was Re: xsane-0.31 available)

Tom Martone (tom@martoneconsulting.com)
Tue, 03 Aug 1999 22:43:48 -0400

Oliver Rauch wrote:
>
> Stephen Williams wrote:
>
> > If all applications must support any combination of frame types, then
> > the application writers will go nuts. If, on the other hand the scanner
> > vendors must work with an excessively short list of formats, they will
> > not be able to demonstrate the value of their nifty expensive equipment.
>
> I think we must find a good way between that.
> If a frontend is not able to handle a special file format: ok - no problem
> We should add formats that will be used by different backends.
> That will e.g. be some formats for still cameras.
>
> If there is one backend that uses a prorietary format it has to convert
> it into another format or it has to pass it trough in raw format.
Greetings,

Document scanners such as the Bell+Howell scanners can produce CCITT-G3,
CCITT-G3-2D, and CCITT-G4 compressed image streams. I'm not sure if it
would be appropriate to classify these formats as proprietary although
they are certainly not specifically supported by SANE.

What I've done in the Bell+Howell backend when the user chooses a
compressed format is to lie and state that the frame type is _GREY
and to use a modified scanimage that has a --raw option that when
use avoids writing the PBM header, thereby writing the raw data to a file.
When the user chooses an uncompressed format, _GREY is used and all
frontends will be happy.

Then to process that raw file (e.g. to convert the raw G4 data to a
TIFF file) you need the resolution, height, and width of the scanned
image. Height and Width are gotten from the parameter block and
the resolution value(s) is gotten from the option setting(s).
For each image scanned a user supplied script is invoked which receives
the datafile as an argument and the resolution, height, and width as
environment variables. Armed with this information, the script can
process the compressed data as it pleases.

It seems that a _RAW frame format would be helpful, so that I need not
lie and say that it is _GREY and then --raw option would not be
needed as the appropriate behavior for dealing with _RAW frames would
be to pass them unmodified to a file. I think adding _G3, _G32D, and _G4
frame formats would be unnecessary, even though I'm pretty sure that
there are other document scanners that support these compressed formats.

And then to get *really* strange, this scanner is capable of decoding
barcodes. So you want to get the decoded barcode data back from the
scanner through SANE. That's where you *really* have to lie, because
this is not image data at all. What I've done in this case is to write
the barcode data into an XML format and send it back as "raw". So, I
think it's important to have the _RAW (don't touch me) format as I'm
sure that adding an _XML or _TEXT frame format will be objected to
for one reason or another and I would be inclined agree with the
objection myself.

Tom Martone

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