[sane-devel] infrared, SANE_FRAME_RGBA

[m. allan noah]

On Fri, 15 Dec 2006, Stéphane VOLTZ wrote:

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

but then the frontend would have to do that every time you made a scan? 
these type of settings usually stay set once determined, and some of them 
might be bad for the equipment if set wrong, so now you have to worry 
about user accidentally changing one.

>
>>
>> 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
>
> Regards,
> 	Stef
>

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