becka@rz.uni-duesseldorf.de wrote:
> > > 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.
I think it would be adviseable to clearly define what the requirements
are in terms of the values in the parameter struct for each frame
type. I think that if you set out to define that for the MIME frame
type that you propose, you may have a long definition that will
refer to different requirements for the different types of data
encoded in the MIME stream. Then, since the MIME is designed to be
extensible, you'll have undefined behavior for any encoded type
that's added after you write the description. How would you word
this in the standard?
> > (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 ?
I'm saying that it would be nice, but I realize that changing the
SANE_Parameter structure would be a more serious change, maybe resulting
in a major version. I'm sure there are other things that might be useful
there, too. I don't think changing the SANE_Parameters structure is
necessary, since the resolution(s) are fairly easily obtainable through
SANE options. My preference would be to add the frame types without
modification to the SANE_Parameters structure, and handle the whole
thing as a minor release. If, in a major release, the SANE_Parameters
were changed, the resolutions would be a good addition.
> > 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 raise the point of binary compatibility which needs serious
attention. I'm certainly no expert with regards to that, but could you
tell me how the MIME frame type avoids the issue or handles it properly?
formats, they are rigorously defined and meant to be cross-platform.
The genesis of these formats was in the telecommunications area for
facsimile transmission. How does this break binary compatibility?
I guess that saned is the key piece here, because it can potentially
transfer data between different platforms. The issues with the CCITT
formats would be color-sex (is 0 white or black?) and bit-sex (what
is the order of the bits within the byte). Do we need to define
the formats further, (e.g. specifying LSB/MSB, etc)? I defer to you
on this.
> 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.
Strings are nice, I agree. Here's a snippet from scanimage and another
snippet from xscanimage. They are converting the existing frametype
numbers into strings for presentation to the user. We could probably
benefit from adding a utility function (in sanei directory?) which
returns the string representation for a frametype. When a frametype
is added, so is the string. Then we can display consistent strings
to the user.
from scanimage.c
static const char *format_name[] =
{
"gray", "RGB", "red", "green", "blue"
};
...
fprintf (stderr, "%s: acquiring %s frame\n", prog_name,
format_name[parm.format]);
from xscanimage.c
switch (scan_win.param.format)
{
case SANE_FRAME_RGB: frame_type = "RGB"; break;
case SANE_FRAME_RED: frame_type = "red"; break;
case SANE_FRAME_GREEN: frame_type = "green"; break;
case SANE_FRAME_BLUE: frame_type = "blue"; break;
case SANE_FRAME_GRAY: frame_type = "gray"; break;
}
> > 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.
Adding the string to the SANE_Parameters struct now breaks binary
compatibility, too, and in a more incompatible way, I think.
If the backend provides a basic format as the default transmission
format, (there seems to be agreement on this), the user of the older
frontend has to select a different format to get the "unknown" format
sent.
> > 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.
It seems as though we have to become MIME parsers to get at any image data
other than _GRAY, _RBG, _RED, _BLUE, and _GREEN. We also hand over the
MIME the job of defining the image transmission formats and my system's
MIME database does not have _G42D, _G32D, _G31D and _JBIG. I guess the
_JFIF is equivalent to image/jpeg, so you have one out of the five
addressed in my MIME database. Maybe I need to enhance my MIME database?
These are the image formats that I see:
image/gif gif
image/ief ief
image/jpeg jpe jpeg jpg
image/x-portable-bitmap pbm
image/x-portable-graymap pgm
image/x-portable-anymap pnm
image/x-portable-pixmap ppm
image/x-cmu-raster ras
image/x-rgb rgb
image/tiff tif tiff
image/x-xbitmap xbm
image/x-xpixmap xpm
image/x-xwindowdump xwd
> 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 ?
I made a sloppy example here. Sorry for the confusion. But given a
well defined, _G42D, _G32D, _G31D and _JFIF, no backend writer would
choose to send that data MIME encoded. So my example should show things
like "audio/ulaw", "video/x-msvideo", and other futuristic things as
the targets of the strcmp.
Or look at it another way. Would you suggest sending the good old _GRAY
and _RGB as "image/x-portable-bitmap", "image/x-portable-graymap",
"image/x-portable-anymap"?
> 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.
What would be the 1:1 relation to _RED, _BLUE, and _GREEN on the MIME
side?
> > 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.
I understand you concern about the neverending growth of frametypes.
I don't see this as neverending, though, especially if we require
rigorous definition that ensures that the data can transmitted between
differing platforms.
But by adding the MIME one you're really opening up a can of worms.
Although it is only one "frametype", you've essentially opened up
the transmission of all present and future mime-types in one fell
swoop without the SANE standard having any role in providing definition.
When you consider the negotiating between frontends and backends, do
they negotiate the MIME frame alone, or each of the MIME types?
If it is the former, the negotiation capability is severely degraded
because if a frontend wants a single or few MIME types, then it then
better be prepared to deal with *all* MIME types.
If it is the latter, then the negotiation gets messy because you are
negotiating both numeric frametypes and, for the MIME frametype, string
subtypes.
Tom Martone
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com