[sane-devel] Additional frame types in Sane 1

[m. allan noah]

On 5/28/07, Oliver Rauch <Oliver.Rauch at rauch-domain.de> wrote:
> Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah:
>
> > > > >
> > > > Well extending SANE1 will certainly start the new discussion
> > > > about finishing SANE2 standard before starting - ACK ;)
> > > > But as we did not move forward and scanner support for Linux
> > > > is more or less stopped in its development, I vote for
> > > > extending SANE1.
> > > >
> > > > As long as it won't hurt the API and the flow-control, introducing
> > > > more frametypes should be no problem...
> > >
> > > Nice to see no big flamewar about the simple frametype addition :-)!
>
> It really is nice that no flamewar starts here but I do not support to
> extend SANE1 this way.
>
> (see my following comment)
>
> > > > >      SANE_FRAME_RGB,            /* pixel-interleaved red/green/blue bands */
> > > > >      SANE_FRAME_RED,            /* red band only */
> > > > >      SANE_FRAME_GREEN,          /* green band only */
> > > > > -    SANE_FRAME_BLUE            /* blue band only */
> > > > > +    SANE_FRAME_BLUE,           /* blue band only */
> > > > > +    SANE_FRAME_INFRARED,       /* infra-red band */
> > > > > +    SANE_FRAME_RGBI,           /* pixel-interleaved red/green/blue/infra-red */
> > > > > +    SANE_FRAME_JPEG            /* Joint Photographic Experts Group's JPEG */
> > > > >    }
> > > > >  SANE_Frame;
> > >
> > > In the meantime I noticed the device can send Gray+IR as well which
> > > would mean SANE_FRAME_GRAYI, as well.
> >
> > i know you probably get RGBIRGBI... from the scanner, but for
> > backwards compatability and to avoid the proliferation of frametypes-
> > i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
> > IR support to any other frametype by sending an extra frame, and
> > existing frontends can be told to ignore the IR frame, and keep using
> > the gray/rgb frames.
>
> Although you do not change the function calls
> at the end you change the SANE API, a frontend that shall handle this
> needs a lot of changes, also a backend needs a lot of changes.
>
> A new backend will not work properly with an old frontend.

yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.

> I suggest to do all this in SANE2 because it is incompatible to SANE1.
> In the moment a frontend has to handle 3 modes:
> GRAY
> RGB
> RGB 3-pass
>
> With the new suggestions it would have to handle
> GRAY
> RGB
> RGB 3pass
> GRAY + INFRARED
> RGB + INFRARED
> RGB 3pass + INFRARED
> RGBI
> JPEG + INFRARED?
> RED + INFRARED?
> etc.

i specifically want to avoid RGBI, so think of it this way-

GRAY
RGB
RGB 3pass
Anything + IR

every frontend does not have to handle IR (some dont handle 3 pass rgb now), so:

case default
  discard_frame();

where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.

> The change of the transmission format hast been put into SANE2
> because it changes a lot in the comunication for frontends and backends.

i disagree with 'a lot', but yes, it is a change.

> Where is the advantage to put it into SANE1?
> You will get incompatibilities between frontends and backends and you
> slow down (if this is possible at all) the development of SANE2.

It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.

> Finish the SANE2 standard. That solves all problems.

i wish to see sane2 as well, but i do not believe that there are huge
numbers of developers lurking on this mailing list, just waiting for
us to get started on sane2. perhaps i am wrong, but i am not sure we
have the critical mass required to start that project.

allan

-- 
"The truth is an offense, but not a sin"