[sane-devel] Additional frame types in Sane 1

[René Rebe]

Hi,

On Monday 28 May 2007 14:08:37 m. allan noah wrote:
> 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.

They should better handle it, either via the network or a buggy frontend
they can get a random frametype today.

> > 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.

It is not practical to send the IR data at the end as additional frame, with
5400 optical dpi (in my case) it is no fun to buffer hundreds of MB of IR
data just in case.

> > 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.

I disagree as well, it's just another optional frametype and we need
"soon" not in years. The emphasis lies on optional, most frontends are
of little use for dia scanners anyway.

> > 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.

SANE 2 has way too many unnecessary changes just for the fun
of it. It would have been way more productive to gradually transform
the current SANE codebase step by step, with clear compatibility pathes,
maybe even mid-layer converters.

For me SANE 2 solves nothing, with the avision backend supporting
nearly 100 devices I only have more work to make sure they work
after a massive SANE transformation.

As we saw the last years a totally new scanning API for Un*x will go
unnoticed and unsupported.

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name