[sane-devel] infrared, SANE_FRAME_RGBA

[m. allan noah]

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.

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