> I agree with this requirement. Luckily, in the Bell+Howell case, the
> scanner supports bit-depth 1, grayscale, so this is very easy to do.
> This is the default format that the backend will send; a --compression
> option (Values None, G4, G3-2D, G3-1D) controls the format of the data
> sent. The default is None which sends _GRAY with bits_per_pixel = 1.
> If this option needs to be changed to a "well known" option, that is
> easily done as well.
O.K. - so you are with me with respect to letting the user or frontend choose
compressed datatype by using a well-known option - right ?
> > 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).
I see. I also do not say, that the parameter struct shall always be empty
or bogus, if we use the MIME transfer type.
If a field makes sense, we should fill it out reasonably.
> (It'd be nice to have the resolution(s)
> in the SANE_Parameter structure, but not at all necessary).
O.K. - I see the point in this. So it seems necessary to extend the params
struct anyway - right ?
If so, I suggest to add two short strings in there that allow to transfer
a textual type description (MIME or better, if we have something better),
and a suggested filename.
Moreover additions that seem to be wanted are dpix/dpiy and probably a flag
that separates pages instead of images, as some scanners can deliver multiple
images per page.
> The cost would seem to me to be the extra complexity in parsing through
> the mime stuff to get at the actual data stream.
Yes. And actuallz I should have phrased my proposal in another order.
I as well think, that transferring the mimetype outband is better, as it is
easier to do for both the front- and the backend, and we need less special
casing to transfer the actual datastream.
> 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.
It does. Mimetypes can have extra attributes. You could use
"tiff/g3; height=452; width=7834; dpix= ...". However I agree with you, that
this is not a good idea. WE should use fields in the params struct for it.
they are already there, why waste them.
> 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.
You are proposing something in between of 5-10 new frametypes. And
frametypes are very indescriptive with respect to binary compatibility.
You can convey any information you can put into a frametype in a string
as well. And a string can be displayed to the user or looked up in a
user-readable/writeable database to find something to do with the data.
> > 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.
We could use that to simplify backend writing by writing middleends that
by their existence allow to write backends that do not export the RAW
datatypes.
> > 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.
Yes. I even thought it the other way round: You open the source, and when you
find it doesn't transfer in a format you can handle, but you really
want to handle the data instead of just saving them away, you re-open the
source through the middleend, and will magically get a bunch of new formats,
especially RAW.
> > 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.
O.K. - but this outband data is readily available from params - right ?
> I think the multiple image frametypes are deserving of first class
> attention (e.g. their own frame types).
Note, that this is very bad for binary compatibility. If you get a backend
that is newer than your frontend (not unusual, once manufacturer's start
making backends), chances are, that you find it is willing to transmit in
an unknown frametype. There is no reasonable way to find out, what this
number means.
A string gives the chance to ask the user.
> The MIME frametype has the advantage of extensibility, but seems to
> require more smarts in the frontend.
Apart from replacing a switch() with a chain of if (strcmp()==) else if ...
I see no difference.
> 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.
I do not see a difference in complexity.
> 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) {
> ...
> }
> }
Why at all having the extra types, then ?
The point is: If an application wants to handle a frametype, it needs to
know it. If it knows the frametype, it as well knows the mimetype, as there
is a 1:1 relation.
> 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.
As the third case is a simple superset of the others, I see no gain. It's
just a question of where the code gets written down. In your above scheme
I would do:
> switch(parms.frametype) {
> case FT_JPG: jpg: ...
> case FT_TIFFG3: g3 : ...
> case FT_MIME:
> if (strcmp(parms.mimetype,"image/jpeg")==0) {
> goto jpg;
> } else if (strcmp(parms.mimetype,"image/tiffg3")==0) {
> goto g3;
> }
> }
You see: no gain making a difference. It will be handled by the same code
anyway.
> > 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.
O.K. - this is a problem, but negotiating per frame would be a bit comple I
think. IMHO the well known option should take care for the bulk "payload"
data. If other chunks exist - o.k. The user can use his/her brain to use
more detailed options.
> > 2. Add a single bew frametype that announces the transmission of arbitrarily
> 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.
O.K. - if it really really really pleases all people here, we can add that
types. But as said, I am afraid of opening a neverending growth of the
frame types, which is very bad regarding compatibility and cannot be easily
extended by just editing a textfile or something.
CU, ANdy
-- Andreas Beck | Email : <Andreas.Beck@ggi-project.org>
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com