[sane-devel] infrared, SANE_FRAME_RGBA

[Gerhard Jaeger]

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

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