> I am fully with you, that SANE is intended for scanners, and should target
> images, but if we can add other file types at no cost, Why not ?
I'd just add that the G31D, G32D, and G42D need the getparm stuff. These
datastreams do not have the height and width encoded within them, but these
are necessary to decoding. You also need the resolution(s) which can be
gotten by querying the option(s). (It'd be nice to have the resolution(s)
in the SANE_Parameter structure, but not at all necessary).
The cost would seem to me to be the extra complexity in parsing through
the mime stuff to get at the actual data stream. And if I understand it
properly, MIME doesn't provide a vehicle for specifying the height, width
and resolution necessary to decode the image data.
I think the MIME idea has merit *in addition* to the frame types that
I proposed earlier. When MIME will be used *instead*, then I'm unhappy.
> To further simplify the process of writing front- or backends in a way that
> allows to finally generate RAW data (in the sense, that the frontend can
> make sense of the data) from common formats, I propose to have "middleends",
> that can attach between a front and a backend (like the net stuff or the
> dll backend does) and can convert from common filetypes to SANE RAW.
This is a good idea and would be very helpful if you had a device that
didn't luckily provide data in one of the basic SANE formats.
> This allows to keep a backend driver simple, as if it is sending a data
> type, for which a converting middleend exists, it doesn't need to worry
> about internal conversion (which would mean code duplication in all backends
> that happen to get a given kind of native input format from their HW).
>
> The other option to allow for full usage with compressed datatypes would be
> implementing conversion in the frontends. This is also not good, as it means
> code-duplication as well.
>
> So from the position of least code duplication, I think the middleends are a
> good solution. It also gives tuneability for the parameters (jpeg-quality)
> in a simple way, as a middleend can extend the optionlist.
And in the high-volume area, you definitely want to avoid the middleend
and send compressed data all the way through for performance reasons.
So, you can choose not to use the middleend. I like this.
> > If the scanner wants to speak text, it's probably beyond the territory
> > we should sensibly stake out for SANE. At that point you're looking at a
> > whole new class of device IMHO.
>
> No. If I got the guy with that high-speed scanning stuff right in his last
> mail, he says, that those scanners can detect barcoded "batch separators".
> Now if he makes a custom frontend, he will want to be able to detect those
> and probably even make use of the data.
>
> I imagine his purpose is document archiving. Now he could just put a bunch
> of pages in the scanner with such a separator page on top. The code on the
> page would tell the frontend where to store/send the resulting files.
> Now if we can convey that information "inline", this would allow to just
> stack more pages with separators on top, and stuff gets sorted in
> automatically.
Yes, you got the idea very well.
> > application/sane?
>
> That the "proposed MIME-type" of the current data stream. It is using extra
> outband data (width and height) from the getparms operation, which all
> other formats we are talking of do not need, as they contain that inband.
As I mentioned earlier the G31D, G32D, and G42D formats need outband data.
I think the JFIF has it inband, and I'm not sure about the JBIG.
> So I don't see much difference between our proposals, except for using
> multiple frametypes vs. a single universal frametype.
I think the multiple image frametypes are deserving of first class
attention (e.g. their own frame types). The MIME frametype has the
advantage of extensibility, but seems to require more smarts in the
frontend. I could see dropping the _ASCII frame format and doing that
through MIME. I'd still prefer the _ASCII from a simplicity point of
view, but I wouldn't fight for it.
> For the frontend I do not see much difference between
>
> switch(parms.frametype) {
> case FT_JPG:...
> case FT_TIFFG3:...
> }
>
> and
>
> if (strcmp(parms.mimetype,"image/jpeg")==0) {
> ...
> } else if (strcmp(parms.mimetype,"image/tiffg3")==0) {
> ...
> }
How about:
switch(parms.frametype) {
case FT_JPG:...
case FT_TIFFG3:...
case FT_MIME:
if (strcmp(parms.mimetype,"image/jpeg")==0) {
...
} else if (strcmp(parms.mimetype,"image/tiffg3")==0) {
...
}
}
This way a frontend, or middleend that wants to support the compressed
image formats but avoid the MIME support can simply drop the third case.
> 1. Add a well-known option that allows to select the transmission format.
Fine, but you get into a bind when you have multiple transmissions in
a single operation. You get the G42D compressed data interspersed with
the decoded barcodes, or simultaneous JFIF and TIFF from a single page,
if I remember Stephen William's description correctly. In the Bell+Howell
backend the image transmission format is specified via the --compression
option and the barcode stuff is specified through a series of options.
And it is also possible to specify --compresion g42d and ask for a
thumbnail (icon) also. The thumbnails are uncompressed, but the full
images are.
> 2. Add a single bew frametype that announces the transmission of arbitrarily
> formatted data. Add two identification fields somewhere that give the
> mimetype and optionally a proposed filename for the data, so one can
> correctly detect and handle the type of data. For "somewhere" I propose
> either the file stream itself, like it is done in metamail, which is a
> little awkward to handle in the frontend, or an extension to the parms
> struct which is easier to handle, but a bit less compatible.
I think the image formats proposed earlier (JFIF, G31D, G32D, G42D, and JBIG)
need their own frame formats. The MIME based one is quite extensible and
can handle future growth.
> 3. To simplify backend generation, middleends should be allowed that can
> extend the available options for 1. by on-the-fly converting data from
> backend format to others.
I think this is a great idea, and is simplified by the image frame types.
Tom Martone
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com