[sane-devel] Additional frame types in Sane 1

[René Rebe]

Hi,

On Monday 28 May 2007 13:04:28 Oliver Rauch 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.
> 
> 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.

First of all most frontends do not even support the few FAME types we
currently have.

Second most frontends are so badly written they do not even support
an unknown lenght at scan start, some just error out, even others
pop up some warning that "handheld devices would not supported".

However, this tocally sucks for all document scanners and thus I think
most backends currently fill out with white or simillar when the paper
run out before the setup scan height is reached.

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

However, SANE2 will not happen the next ten years. Some reason why this
is so:

 - all the open source apps support SANE 1 already

 - most professionaly are glad to have SANE 1 custom applications
   running today. They do not want spend thousands of money just
   to jump on some SANE 2 wagon.

 - we are happy to have so many devices supported at all, support
   for most old devices will never show up in a totally redone from
   scratch SANE2.

 + a probably a lot more that currently does not come to mind

How long do some discuss a possible SANE 2?

Furtheremore when we do not get a more step by step future
road going most big companies would rather go TWAIN 2.0 (for
Linux) than some jeopardy from scrathc undertaking.

Btw. the reason Linux is so successful is because it was not
rewritten from scratch every 5 years, but gradually improved
and cleaned up.

> Where is the advantage to put it into SANE1?

To have proper support for the backends and the few frontends
that need it tomorrow and not in 10 years?

> You will get incompatibilities between frontends and backends and you
> slow down (if this is possible at all) the development of SANE2.

Yeah, "if possible at all".

Sane already has so many options that are unsupported by
most frontends, yet another frametype will not matter much
at all.

If I feel like setting a bitdepth of 32 or 64 bits all frontends
I saw so far will not handle this as well.

> Finish the SANE2 standard. That solves all problems.

I stopped listening to the SANE 2 bla bla like 5 years ago when
it became clear to me that the people talking about just want to
talk and not code.

Yours,

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