[sane-devel] infrared, SANE_FRAME_RGBA
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 Regards, Stef
[sane-devel] infrared, SANE_FRAME_RGBA
On Thursday 14 December 2006 21:18, m. allan noah wrote: 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. okay - move that responsibility over to the frontends? Otherwise the responsiveness of i.e. XSane will decrease to zero. 2. network protocol overhaul- this keeps coming up, but i dont understand it fully. No idea about that, but I think there are others around. 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? ACK. 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. Full ACK. 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. ACK 11. Overhaul build system - Gerhard
[sane-devel] infrared, SANE_FRAME_RGBA
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 From an...@pfeiffer.edu Fri Dec 15 14:59:54 2006 From: an...@pfeiffer.edu (m. allan noah) Date: Fri Dec 15 15:00:35 2006 Subject: [sane-devel] infrared, SANE_FRAME_RGBA In-Reply-To: 200612150841.39323.gerh...@gjaeger.de References: 20061212170210.688b48d9@inspiron 1166123681.1067.19.camel@casa pine.lnx.4.61.0612141456570.17...@limos.pfeiffer.edu 200612150841.39323.gerh...@gjaeger.de Message-ID: pine.lnx.4.61.0612150851170.20...@limos.pfeiffer.edu On Fri, 15 Dec 2006, Gerhard Jaeger wrote: On Thursday 14 December 2006 21:18, m. allan noah wrote: 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
[sane-devel] infrared, SANE_FRAME_RGBA
On Tuesday 12 December 2006 17:02, Alessandro Zummo wrote: Hello, I would like to add proper infrared support to my Coolscan LS-2000. This would require modifications to the current sources of coolscan2 and scanimage. coolscan2, when fixed with my patch, gives back the infrared channel on a second pass, passing batch-count=2 to scanimage. I would like to add the format SANE_FRAME_RGBA and have the infrared channel passed back as the alpha channel. I would then patch scanimage to save this channel to a tiff file. In order to the infrared channel to be useful, the driver will refuse to alter the image in any way (i.e. no gamma) when in RGBA mode. [SNIPSNAP] Hi, sorry for the noise, but AFAIR, we had this discussion already here about extending the currently available image data formats. The conclusion was, that with SANE 1.0 we should not do that - SANE 2.0 will be the solution ;) - Henning??? I see that your changes won't probably break anything, but I think it is again time for the discussion - Allow extending SANE 1.0 or not - SANE 2.0 is far from being ever started :( Gerhard
[sane-devel] infrared, SANE_FRAME_RGBA
On Thu, 14 Dec 2006 08:48:38 +0100 Gerhard Jaeger gerh...@gjaeger.de wrote: I would like to add the format SANE_FRAME_RGBA and have the infrared channel passed back as the alpha channel. I would then patch scanimage to save this channel to a tiff file. sorry for the noise, but AFAIR, we had this discussion already here about extending the currently available image data formats. The conclusion was, that with SANE 1.0 we should not do that - SANE 2.0 will be the solution ;) - Henning??? I see that your changes won't probably break anything, but I think it is again time for the discussion - Allow extending SANE 1.0 or not - SANE 2.0 is far from being ever started :( I would really appreciate a sane 2, but we have a problem: who will write it? who will port the drivers? some drivers are old. original authors are not available. original testers are neither and they might no more have the equipment. I've got 0 (zero) answers to my call for beta testers for the epson2 driver. the code must be completely reviewed and each driver has some code/style standard of its own to handle the things.. a complete rewrite could take no less than 1 year if appropriate development forces (and equipment) are available, which it doesn't seem the case. (there are open bugs in the bug tracking which are more than 3 years old). And that is when development is started, but first we should agree on the sane2 specs, which could take months. So we either find a way to pay 2/3 developers full time or I guess we should stick to sane 1 :-D So, my opinion is to stick to sane 1, document what we have at the deepest level (i'm, for one, adding comments to epson2 in order to explain what's done). we can reorganize the drivers, split the code and add some features (like new frame formats, which are a quite easy thing and would not break anything) maybe add a wiki and a new friendlier bug tracking system (trac has both). some things that have been agreed on sane2 can easily be implemented in sane1 with no/minor compatibility issues. minor tweaks, like agreeing on common names for scan sources are implementable (ADF vs Automatic Document Feeder). so, while having sane2 is a good thing, IMHO we are not at a point where this can be done. improving sane1 is still doable though and would be helpful in the path to sane2. my suggestions, thus, are: - wiki - trac - comments - dropping support for anything that is not C99 - code reorganization (no more 6K lines in a single file!) - standard debug levels for drivers (no more SANE_DEBUG_DRIVERNAME) - conformance and call that sane 1.5 :) just my two cents... -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it
[sane-devel] infrared, SANE_FRAME_RGBA
On Thursday 14 December 2006 12:11, Alessandro Zummo wrote: On Thu, 14 Dec 2006 08:48:38 +0100 Gerhard Jaeger gerh...@gjaeger.de wrote: I would like to add the format SANE_FRAME_RGBA and have the infrared channel passed back as the alpha channel. I would then patch scanimage to save this channel to a tiff file. sorry for the noise, but AFAIR, we had this discussion already here about extending the currently available image data formats. The conclusion was, that with SANE 1.0 we should not do that - SANE 2.0 will be the solution ;) - Henning??? I see that your changes won't probably break anything, but I think it is again time for the discussion - Allow extending SANE 1.0 or not - SANE 2.0 is far from being ever started :( I would really appreciate a sane 2, but we have a problem: Guess we have much more than one ;) who will write it? who will port the drivers? some drivers are old. original authors are not available. original testers are neither and they might no more have the equipment. I've got 0 (zero) answers to my call for beta testers for the epson2 driver. the code must be completely reviewed and each driver has some code/style standard of its own to handle the things.. a complete rewrite could take no less than 1 year if appropriate development forces (and equipment) are available, which it doesn't seem the case. (there are open bugs in the bug tracking which are more than 3 years old). Full ACK. And that is when development is started, but first we should agree on the sane2 specs, which could take months. It already took us years ;) So we either find a way to pay 2/3 developers full time or I guess we should stick to sane 1 :-D he, he... So, my opinion is to stick to sane 1, document what we have at the deepest level (i'm, for one, adding comments to epson2 in order to explain what's done). we can reorganize the drivers, split the code and add some features (like new frame formats, which are a quite easy thing and would not break anything) maybe add a wiki and a new friendlier bug tracking system (trac has both). any volunteers? some things that have been agreed on sane2 can easily be implemented in sane1 with no/minor compatibility issues. ACK. minor tweaks, like agreeing on common names for scan sources are implementable (ADF vs Automatic Document Feeder). so, while having sane2 is a good thing, IMHO we are not at a point where this can be done. improving sane1 is still doable though and would be helpful in the path to sane2. my suggestions, thus, are: - wiki Hmmm, it's like everything around here in the net: * a lot of the information is hopelessly outdated * if up to date, nobody uses it - they ask on the mailing list - trac - comments * Good thing, we started usage of doxygen... - dropping support for anything that is not C99 - code reorganization (no more 6K lines in a single file!) - standard debug levels for drivers (no more SANE_DEBUG_DRIVERNAME) - conformance The same problem as porting the stuff to SANE 2 - you'll need the authors... and call that sane 1.5 :) just my two cents... Only two ;) All of your point sound reasonable and doable for me - of course, but as I said: We ran into these discussion often enough and the result was: No new features, they are for SANE2. 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? Gerhard
[sane-devel] infrared, SANE_FRAME_RGBA
On Thu, 14 Dec 2006 13:40:45 +0100 Gerhard Jaeger gerh...@gjaeger.de wrote: maybe add a wiki and a new friendlier bug tracking system (trac has both). any volunteers? if someone has a machine, installing trac is easy, and I can eventually do it. I can use a machine at my company, but would prefer to keep it on an open sever. my suggestions, thus, are: - wiki Hmmm, it's like everything around here in the net: * a lot of the information is hopelessly outdated * if up to date, nobody uses it - they ask on the mailing list well.. it depends on the community.. I've seen bad and good wikis. But we don't know what will happen unless we try :) - trac - comments * Good thing, we started usage of doxygen... /me hates it :) - dropping support for anything that is not C99 - code reorganization (no more 6K lines in a single file!) - standard debug levels for drivers (no more SANE_DEBUG_DRIVERNAME) - conformance The same problem as porting the stuff to SANE 2 - you'll need the authors... not for everything... I have some time to reorganize epson2 and maybe coolscan 2... dropping support for C99 is also easy :) and.. if you break a driver you will surely get complaints :-D All of your point sound reasonable and doable for me - of course, but as I said: We ran into these discussion often enough and the result was: No new features, they are for SANE2. I'd agree on the principle if it is implementable :) 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. Event if finished, it could take years to code. And given that we are in 2007 I think we can wait no more. I'd like to hear/read some more opinions on that. Any? btw.. I've appreciated your quick response to my email! -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it
[sane-devel] infrared, SANE_FRAME_RGBA
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 am not an active SANE developer, but I follow the list since some year; I tested SANE on many scanners and on a few operating system versions; I worked at the italian translation. Lately I decided to work more on coolscan2 driver in order to work with Coolscan V LS-50 ED, so I requested all documentation to Nikon and I am actually waiting for it. Moreover I develop an application that uses scanners on Windows (via TWAIN), and MacOSX and Linux (via SANE). So take my opinion as the less important among SANE developers opinions. My impression is that SANE is nice peace of software, but there are some incompatibilities among the backends. As an exemple: a common user interface (arguments) would be useful to applications that invoke SANE. I have to re-read the SANE2 specification. I think it could be useful in making it easy to develop backends and to interface with them. I don't remember what were pro and cons in previous threads, but I am in favour of starting sane2 implementation now since nothing will change in the next months. Some backends will be ported to sane2 earlier than other; maybe others will never be ported. But I think that sane does not require a complete compatibility with sane1. It may be a different application. Bye, Giuseppe
[sane-devel] infrared, SANE_FRAME_RGBA
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
[sane-devel] infrared, SANE_FRAME_RGBA
On Thu, 14 Dec 2006 15:18:41 -0500 (EST) m. allan noah an...@pfeiffer.edu wrote: 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. I agree, but propose to re-open only after a number of developers a really interested in writing code. 4. inconsistent option names and arguments between backends. 5. inconsistent gamma/brightness/contrast implementations (sanei_gamma i have been playing with here) 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. those 3 items are quite important imho. -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it
