[sane-devel] Additional frame types in Sane 1

[m. allan noah]

On 5/28/07, René Rebe <rene at exactcode.de> wrote:
> 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.

should, yes, but they dont. look at scanimage.c for instance.

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

what are you currently doing with the backside scan of a duplex adf
scanner? a 36x24mm 8bit 5400dpi is only 40 megs? even 16 bit IR at 80
megs is smaller than a 600 dpi 24bit rgb A4 (90+ megs), and you are
already buffering that somehow.

i want to cause as little headache for the frontend writers as
possible. that means they should be able to add a simple loop to eat
any frames they dont understand, rather than special handling for
RGBI.

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

this is true, but dont forget that the discussion is not just about IR
channel, but also about other 'frames' that the backend might be able
to provide. jpeg, icc, etc.

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

allan

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