[sane-devel] Additional frame types in Sane 1
m. allan noah
kitno455 at gmail.com
Sun May 27 18:08:01 UTC 2007
On 5/27/07, René Rebe <rene at exactcode.de> wrote:
> Hi Allan,
> hi all,
> On Sunday 27 May 2007 13:38:31 Gerhard Jaeger wrote:
> > On Freitag, 25. Mai 2007, m. allan noah wrote:
> > [SNIPSNAP]
> > > yes, this will require that a front-end would have to be updated to
> > > understand this type of data. I can extend scanimage and scanadf
> > > (though i probably wont support all the possible conversions). it will
> > > also require (in the case of compression) that the front-end be able
> > > to deal with variable length data.
> > >
> > > comments, requests, flames? :)
> > >
> > 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 :-)!
> As we already discuseed in private +1 from me as well.
> When we are at it please let's add the INFRARED frame type
> I need for the latest (Avision OEM) Konica Minolta devices that
> deliver infra-red data for dust & co removal.
> On 2007-05-16 17:40 I proposed this:
> > > --- sane.h 2007-05-16 02:34:53.000000000 +0000
> > > +++ sane.h.new 2007-05-16 15:28:52.000000000 +0000
> > > @@ -169,7 +169,10 @@
> > > 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.
"The truth is an offense, but not a sin"
More information about the sane-devel