[sane-devel] infrared, SANE_FRAME_RGBA
gerhard at gjaeger.de
Thu Dec 14 13:40:45 CET 2006
On Thursday 14 December 2006 12:11, Alessandro Zummo wrote:
> On Thu, 14 Dec 2006 08:48:38 +0100
> Gerhard Jaeger <gerhard at 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).
> 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
> 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
> 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
> 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.
More information about the sane-devel