[sane-devel] infrared, SANE_FRAME_RGBA

Stéphane VOLTZ stef.dev at free.fr
Fri Dec 15 06:50:19 CET 2006

Le jeudi 14 décembre 2006 21:18, m. allan noah a écrit :
> On Thu, 14 Dec 2006, Giuseppe Sacco wrote:
> > Hi Gerard and all SANE developers,
> >
> > Il giorno gio, 14/12/2006 alle 13.40 +0100, Gerhard Jaeger ha scritto:
> > [...]
> >
> >> But I think you are right, we are moving into a dead-end. We have
> >> devices that are able to do much more than we are able to support
> >> with the SANE 1 standard AND we have a not yet finished (if finished
> >> ever) SANE 2 standard.
> >>
> >> I'd like to hear/read some more opinions on that.
> >> Any?
> i would vote for re-openning the discussion of SANE2, and begin a project
> to port a limited number of backends forward. use a whole new SONAME, such
> that sane1 and 2 libs can co-exist for awhile. many backends will never be
> ported to sane2, because the scanners have not been made in 10+ years, and
> there is no-one to do it.
> my personal list of things other folks have mentioned:
> 1. i hate threading/forking in backends. it makes debugging a mess, and
> there are plenty of non-interactive uses for sane that dont need it (the
> single most popular front-end, scanimage, for one :) As per recent
> discussions on this list, any frontend that cares about non-blocking, has
> already implemented a threading solution to deal with all the backends
> that block. lets drop the non-blocking functions.
> 2. network protocol overhaul- this keeps coming up, but i dont understand
> it fully.
> 3. stackable/modular compression libs- lots of scanners give back jpeg as
> their native format, and we usually open it up to a huge pixmap, just to
> hand to front-end. this is esp. noticable over saned. zlib, jpeg, what
> else?
> 4. inconsistent option names and arguments between backends.
> 5. inconsistent gamma/brightness/contrast implementations (sanei_gamma
> i have been playing with here)
> 6. persistent device naming. none of this libusb:xxx stuff, i want
> the backend to provide the name, using something like serial number,
> rather than using the sanei_usb name.
> 7. inconsistent conf file layouts- i actually would like to see something
> more like samba.conf, with [sections], etc.

	Some months ago, it was thought of exposing configuration parameters the same 
way the scanning parameters are exposed. That would allow frontends or other 
tools to configure backends easily. 

> 8. inconsistent debug levels. not that big of a deal i guess. i would
> rather that they were a bitmask instead of a linear progression.
> 9. i HATE the frontends changing br-x/y and tl-x/y into t/b/l/r- i have a
> front-end that takes cli args like scanimage, and i have to do the same
> option manipulations so that users can use their scanimage commands in my
> prog. it also means that my back-ends provided help text for those options
> is not useful.
> 10. button support. getting better, but not there yet.
> comments?
> allan
> --
> "so don't tell us it can't be done, putting down what you don't know.
> money isn't our god, integrity will free our souls" - Max Cavalera


More information about the sane-devel mailing list