Discussion:
Additional frame types in Sane 1
(too old to reply)
m. allan noah
2007-05-25 17:31:21 UTC
Permalink
Quite a few recent scanners have the ability to output jpeg data,
including most fujitsus. I have been contracted to extend sane to
support this capability. I can keep the modifications private, or i
can try to get them included in sane proper (which i prefer).

Therefore, I have reviewed the sane-devel mailing lists for the past
several years, and tried to come up with a plan based on those
discussions. Many of them center around Sane2, and proposals such a
Mime or Textual frame-type determination. Given the speed at which
Sane2 has moved, (most of these discussions are 5 years old!), and the
relative complexity of those approaches, i am suggesting a more
trivial alternative, specific new frame types.

In all, i found mention of only 5 additional types of data sane does
not handle well:

JPEG, IR, ICC profile, EXIF data, and compressed TIF (G4 fax).

Really, it seems like only the first three get repeated mentions in
the archives. I dont know much about ICC, so my proposal is therefore
quite simple. Rather than continue to wait for sane2, i am prepared to
extend sane1 with 2 new choices: SANE_FRAME_JPEG and SANE_FRAME_RGBI.
I would try to leave enough framework for others to add ICC and FAX
support.

yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
(though i probably wont support all the possible conversions). it will
also require (in the case of compression) that the front-end be able
to deal with variable length data.

comments, requests, flames? :)

allan
--
"The truth is an offense, but not a sin"
Gerard Klaver
2007-05-25 17:49:50 UTC
Permalink
Post by m. allan noah
Quite a few recent scanners have the ability to output jpeg data,
including most fujitsus. I have been contracted to extend sane to
support this capability. I can keep the modifications private, or i
can try to get them included in sane proper (which i prefer).
Therefore, I have reviewed the sane-devel mailing lists for the past
several years, and tried to come up with a plan based on those
discussions. Many of them center around Sane2, and proposals such a
Mime or Textual frame-type determination. Given the speed at which
Sane2 has moved, (most of these discussions are 5 years old!), and the
relative complexity of those approaches, i am suggesting a more
trivial alternative, specific new frame types.
In all, i found mention of only 5 additional types of data sane does
JPEG, IR, ICC profile, EXIF data, and compressed TIF (G4 fax).
Really, it seems like only the first three get repeated mentions in
the archives. I dont know much about ICC, so my proposal is therefore
quite simple. Rather than continue to wait for sane2, i am prepared to
extend sane1 with 2 new choices: SANE_FRAME_JPEG and SANE_FRAME_RGBI.
I would try to leave enough framework for others to add ICC and FAX
support.
yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
(though i probably wont support all the possible conversions). it will
also require (in the case of compression) that the front-end be able
to deal with variable length data.
comments, requests, flames? :)
allan
--
"The truth is an offense, but not a sin"
Nice, SANE_FRAME_JPEG option is usefull for xcam, variable length data,
for some devices a larger buf size is enough (scanimage -B or xcam -B
option), i don't know how much effort it will be to extend xcam, but it
sounds interresting.
--
--------
m.vr.gr.
Gerard Klaver
Julien BLACHE
2007-05-25 20:30:26 UTC
Permalink
Post by m. allan noah
yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
Do you plan to change either the current API or ABI ? (wrt soversion
bump to libsane.so.2)

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
m. allan noah
2007-05-25 23:19:24 UTC
Permalink
Post by Julien BLACHE
Post by m. allan noah
yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
Do you plan to change either the current API or ABI ? (wrt soversion
bump to libsane.so.2)
at this moment, i think that i would NOT bump the soversion, because i
do not wish to imply that this is sane2. i see two possibilities for
frontend error:

1. SANE_FRAME_* code does not handle unknown frametype
2. the sane_read() loop dies when getting an early SANE_STATUS_EOF

Both of these conditions would currently be handled in robust
frontend, so i think all i propose is to formalize the handling of
these two conditions. That sounds like soversion 1 still.

but, my mind could be changed :) Comments?

allan
Post by Julien BLACHE
JB.
--
Julien BLACHE <http://www.jblache.org>
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"The truth is an offense, but not a sin"
Julien BLACHE
2007-05-26 08:19:57 UTC
Permalink
"m. allan noah" <***@gmail.com> wrote:

Hi,
Post by m. allan noah
at this moment, i think that i would NOT bump the soversion, because i
do not wish to imply that this is sane2. i see two possibilities for
1. SANE_FRAME_* code does not handle unknown frametype
2. the sane_read() loop dies when getting an early SANE_STATUS_EOF
Both of these conditions would currently be handled in robust
frontend, so i think all i propose is to formalize the handling of
these two conditions. That sounds like soversion 1 still.
Sounds good :)

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Étienne Bersac
2007-05-25 21:59:16 UTC
Permalink
Hi,

I agree with the proposal. Even if i wonder who do SANE 2, and if this
change does not actually open the SANE 2 development … do you intend
to create at least a SANE 2 branch in CVS or save SANE 1 in a CVS
branch ? (i don't know if CVS handle branch like SVN)

Would be nice also to harmonize source options ;-).

Étienne
--
verso l'
Gerhard Jaeger
2007-05-27 11:38:31 UTC
Permalink
On Freitag, 25. Mai 2007, m. allan noah wrote:
[SNIPSNAP]
Post by m. allan noah
yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
(though i probably wont support all the possible conversions). it will
also require (in the case of compression) that the front-end be able
to deal with variable length data.
comments, requests, flames? :)
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.

As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...

- Gerhard
René Rebe
2007-05-27 17:56:05 UTC
Permalink
Hi Allan,
hi all,
Post by Gerhard Jaeger
[SNIPSNAP]
Post by m. allan noah
yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
(though i probably wont support all the possible conversions). it will
also require (in the case of compression) that the front-end be able
to deal with variable length data.
comments, requests, flames? :)
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!

As we already discuseed in private +1 from me as well.

When we are at it please let's add the INFRARED frame type
I need for the latest (Avision OEM) Konica Minolta devices that
deliver infra-red data for dust & co removal.
Post by Gerhard Jaeger
Post by m. allan noah
--- sane.h 2007-05-16 02:34:53.000000000 +0000
+++ sane.h.new 2007-05-16 15:28:52.000000000 +0000
@@ -169,7 +169,10 @@
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
Geschäftsführer: Susanne Klaus, René Rebe
Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
USt-IdNr.: DE251602478
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
m. allan noah
2007-05-27 18:08:01 UTC
Permalink
Post by René Rebe
Hi Allan,
hi all,
Post by Gerhard Jaeger
[SNIPSNAP]
Post by m. allan noah
yes, this will require that a front-end would have to be updated to
understand this type of data. I can extend scanimage and scanadf
(though i probably wont support all the possible conversions). it will
also require (in the case of compression) that the front-end be able
to deal with variable length data.
comments, requests, flames? :)
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
As we already discuseed in private +1 from me as well.
When we are at it please let's add the INFRARED frame type
I need for the latest (Avision OEM) Konica Minolta devices that
deliver infra-red data for dust & co removal.
Post by Gerhard Jaeger
Post by m. allan noah
--- sane.h 2007-05-16 02:34:53.000000000 +0000
+++ sane.h.new 2007-05-16 15:28:52.000000000 +0000
@@ -169,7 +169,10 @@
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.

allan
--
"The truth is an offense, but not a sin"
Oliver Rauch
2007-05-28 11:04:28 UTC
Permalink
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.

(see my following comment)
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Post by m. allan noah
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.

A new backend will not work properly with an old frontend.


I suggest to do all this in SANE2 because it is incompatible to SANE1.
In the moment a frontend has to handle 3 modes:
GRAY
RGB
RGB 3-pass

With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.

The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.

Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.

Finish the SANE2 standard. That solves all problems.

Oliver
m. allan noah
2007-05-28 12:08:37 UTC
Permalink
Post by Oliver Rauch
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Post by m. allan noah
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.
Post by Oliver Rauch
I suggest to do all this in SANE2 because it is incompatible to SANE1.
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
i specifically want to avoid RGBI, so think of it this way-

GRAY
RGB
RGB 3pass
Anything + IR

every frontend does not have to handle IR (some dont handle 3 pass rgb now), so:

case default
discard_frame();

where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.
Post by Oliver Rauch
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
i disagree with 'a lot', but yes, it is a change.
Post by Oliver Rauch
Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
i wish to see sane2 as well, but i do not believe that there are huge
numbers of developers lurking on this mailing list, just waiting for
us to get started on sane2. perhaps i am wrong, but i am not sure we
have the critical mass required to start that project.

allan
--
"The truth is an offense, but not a sin"
René Rebe
2007-05-28 16:46:53 UTC
Permalink
Hi,
Post by m. allan noah
Post by Oliver Rauch
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Post by m. allan noah
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.
They should better handle it, either via the network or a buggy frontend
they can get a random frametype today.
Post by m. allan noah
Post by Oliver Rauch
I suggest to do all this in SANE2 because it is incompatible to SANE1.
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
i specifically want to avoid RGBI, so think of it this way-
GRAY
RGB
RGB 3pass
Anything + IR
case default
discard_frame();
where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.
It is not practical to send the IR data at the end as additional frame, with
5400 optical dpi (in my case) it is no fun to buffer hundreds of MB of IR
data just in case.
Post by m. allan noah
Post by Oliver Rauch
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
i disagree with 'a lot', but yes, it is a change.
I disagree as well, it's just another optional frametype and we need
"soon" not in years. The emphasis lies on optional, most frontends are
of little use for dia scanners anyway.
Post by m. allan noah
Post by Oliver Rauch
Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
:-)
Post by m. allan noah
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
i wish to see sane2 as well, but i do not believe that there are huge
numbers of developers lurking on this mailing list, just waiting for
us to get started on sane2. perhaps i am wrong, but i am not sure we
have the critical mass required to start that project.
SANE 2 has way too many unnecessary changes just for the fun
of it. It would have been way more productive to gradually transform
the current SANE codebase step by step, with clear compatibility pathes,
maybe even mid-layer converters.

For me SANE 2 solves nothing, with the avision backend supporting
nearly 100 devices I only have more work to make sure they work
after a massive SANE transformation.

As we saw the last years a totally new scanning API for Un*x will go
unnoticed and unsupported.
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
m. allan noah
2007-05-28 20:05:41 UTC
Permalink
Post by René Rebe
Hi,
Post by m. allan noah
Post by Oliver Rauch
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Post by m. allan noah
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.
They should better handle it, either via the network or a buggy frontend
they can get a random frametype today.
should, yes, but they dont. look at scanimage.c for instance.
Post by René Rebe
Post by m. allan noah
Post by Oliver Rauch
I suggest to do all this in SANE2 because it is incompatible to SANE1.
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
i specifically want to avoid RGBI, so think of it this way-
GRAY
RGB
RGB 3pass
Anything + IR
case default
discard_frame();
where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.
It is not practical to send the IR data at the end as additional frame, with
5400 optical dpi (in my case) it is no fun to buffer hundreds of MB of IR
data just in case.
what are you currently doing with the backside scan of a duplex adf
scanner? a 36x24mm 8bit 5400dpi is only 40 megs? even 16 bit IR at 80
megs is smaller than a 600 dpi 24bit rgb A4 (90+ megs), and you are
already buffering that somehow.

i want to cause as little headache for the frontend writers as
possible. that means they should be able to add a simple loop to eat
any frames they dont understand, rather than special handling for
RGBI.
Post by René Rebe
Post by m. allan noah
Post by Oliver Rauch
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
i disagree with 'a lot', but yes, it is a change.
I disagree as well, it's just another optional frametype and we need
"soon" not in years. The emphasis lies on optional, most frontends are
of little use for dia scanners anyway.
this is true, but dont forget that the discussion is not just about IR
channel, but also about other 'frames' that the backend might be able
to provide. jpeg, icc, etc.
Post by René Rebe
Post by m. allan noah
Post by Oliver Rauch
Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
:-)
Post by m. allan noah
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
i wish to see sane2 as well, but i do not believe that there are huge
numbers of developers lurking on this mailing list, just waiting for
us to get started on sane2. perhaps i am wrong, but i am not sure we
have the critical mass required to start that project.
SANE 2 has way too many unnecessary changes just for the fun
of it. It would have been way more productive to gradually transform
the current SANE codebase step by step, with clear compatibility pathes,
maybe even mid-layer converters.
For me SANE 2 solves nothing, with the avision backend supporting
nearly 100 devices I only have more work to make sure they work
after a massive SANE transformation.
As we saw the last years a totally new scanning API for Un*x will go
unnoticed and unsupported.
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
allan
--
"The truth is an offense, but not a sin"
René Rebe
2007-05-29 07:17:09 UTC
Permalink
Hi all,
What about SANE 1.2 ? Adding some frametype and well-known options
would improve and clean SANE without the burden of a brand new from
scratch release. This without the fear of the "major release
migration".
Exactly. I'm all for it as we need solutions sometime soon and
not in decades.
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
m. allan noah
2007-05-29 14:22:23 UTC
Permalink
Post by René Rebe
Hi all,
What about SANE 1.2 ? Adding some frametype and well-known options
would improve and clean SANE without the burden of a brand new from
scratch release. This without the fear of the "major release
migration".
Exactly. I'm all for it as we need solutions sometime soon and
not in decades.
i like the idea of working toward an improved sane with small steps,
but i dont like bumping the soversion every time, especially when the
change is small. will distros install all these versions?

allan
--
"The truth is an offense, but not a sin"
Étienne Bersac
2007-05-28 19:49:37 UTC
Permalink
Hi,

As a frontend developer, i would really enjoy that SANE 2 get
developped, especially for its larger amount of well-known options.
However, i'm not agree with the curent handling of scanner button (as
we discussed earlier).
René Rebe
2007-05-28 16:35:14 UTC
Permalink
Hi,
Post by Oliver Rauch
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
Post by m. allan noah
Post by René Rebe
Post by Gerhard Jaeger
Post by m. allan noah
SANE_FRAME_RGB, /* pixel-interleaved red/green/blue bands */
SANE_FRAME_RED, /* red band only */
SANE_FRAME_GREEN, /* green band only */
- SANE_FRAME_BLUE /* blue band only */
+ SANE_FRAME_BLUE, /* blue band only */
+ SANE_FRAME_INFRARED, /* infra-red band */
+ SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */
+ SANE_FRAME_JPEG /* Joint Photographic Experts Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
I suggest to do all this in SANE2 because it is incompatible to SANE1.
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
First of all most frontends do not even support the few FAME types we
currently have.

Second most frontends are so badly written they do not even support
an unknown lenght at scan start, some just error out, even others
pop up some warning that "handheld devices would not supported".

However, this tocally sucks for all document scanners and thus I think
most backends currently fill out with white or simillar when the paper
run out before the setup scan height is reached.
Post by Oliver Rauch
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
However, SANE2 will not happen the next ten years. Some reason why this
is so:

- all the open source apps support SANE 1 already

- most professionaly are glad to have SANE 1 custom applications
running today. They do not want spend thousands of money just
to jump on some SANE 2 wagon.

- we are happy to have so many devices supported at all, support
for most old devices will never show up in a totally redone from
scratch SANE2.

+ a probably a lot more that currently does not come to mind

How long do some discuss a possible SANE 2?

Furtheremore when we do not get a more step by step future
road going most big companies would rather go TWAIN 2.0 (for
Linux) than some jeopardy from scrathc undertaking.

Btw. the reason Linux is so successful is because it was not
rewritten from scratch every 5 years, but gradually improved
and cleaned up.
Post by Oliver Rauch
Where is the advantage to put it into SANE1?
To have proper support for the backends and the few frontends
that need it tomorrow and not in 10 years?
Post by Oliver Rauch
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
Yeah, "if possible at all".

Sane already has so many options that are unsupported by
most frontends, yet another frametype will not matter much
at all.

If I feel like setting a bitdepth of 32 or 64 bits all frontends
I saw so far will not handle this as well.
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
I stopped listening to the SANE 2 bla bla like 5 years ago when
it became clear to me that the people talking about just want to
talk and not code.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Oliver Rauch
2007-05-28 21:14:22 UTC
Permalink
Post by René Rebe
Sane already has so many options that are unsupported by
most frontends, yet another frametype will not matter much
at all.
Can you give one good example?
Post by René Rebe
If I feel like setting a bitdepth of 32 or 64 bits all frontends
I saw so far will not handle this as well.
This is physically no-sense. Already real 16 bits/sample are only
possible with very low temperature (e.g. fluid nitrogen cooling)
and I have never seen such a scanner.
Post by René Rebe
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
I stopped listening to the SANE 2 bla bla like 5 years ago when
it became clear to me that the people talking about just want to
talk and not code.
But this is no reason to make SANE-1 unusable by creating incompatible
sane1 versions.

When you think sane2 takes too long then make the sane2 proposal to a
sane3 proposal and create a reduced sane2 proposal. But do not make
sane1 corrupt.

Best regards
Oliver
René Rebe
2007-05-29 15:34:06 UTC
Permalink
Post by Oliver Rauch
Post by René Rebe
Sane already has so many options that are unsupported by
most frontends, yet another frametype will not matter much
at all.
Can you give one good example?
All the option names differ from backend to backend already, making
live for a frontend unnecessarily hard.
Post by Oliver Rauch
Post by René Rebe
If I feel like setting a bitdepth of 32 or 64 bits all frontends
I saw so far will not handle this as well.
This is physically no-sense. Already real 16 bits/sample are only
possible with very low temperature (e.g. fluid nitrogen cooling)
and I have never seen such a scanner.
Still it is allowed in current SANE and not all frontends will deal
with it gracefully.
Post by Oliver Rauch
Post by René Rebe
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
I stopped listening to the SANE 2 bla bla like 5 years ago when
it became clear to me that the people talking about just want to
talk and not code.
But this is no reason to make SANE-1 unusable by creating incompatible
sane1 versions.
When you think sane2 takes too long then make the sane2 proposal to a
sane3 proposal and create a reduced sane2 proposal. But do not make
sane1 corrupt.
Adding new frametypes does not corrupt anything. Securely and
sanely written frontends will just say "unsupported frame", and the
user can still update to a new frontend that supports jpeg frames.

Also this will continue to just work, as the backends can easily default
to the known RGB frames, until the user hits the JPEG UI element.

Btw. We are already implementing this anyway, as companies
ask for this. It is just a question to get this into vanilla SANE for
all and starting the overdue evolution of SANE, or having some
"we use the GPL SANE and here are our enhancements to
download".

Btw. Can you please be so kind and keep me CC'ed as I can not
monitor all the noisy folder all day while doing work, thanks.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Oliver Rauch
2007-05-29 16:17:24 UTC
Permalink
Post by René Rebe
Post by Oliver Rauch
Post by René Rebe
Sane already has so many options that are unsupported by
most frontends, yet another frametype will not matter much
at all.
Can you give one good example?
All the option names differ from backend to backend already, making
live for a frontend unnecessarily hard.
And what options are unsupported by frontends?
Post by René Rebe
Post by Oliver Rauch
Post by René Rebe
If I feel like setting a bitdepth of 32 or 64 bits all frontends
I saw so far will not handle this as well.
This is physically no-sense. Already real 16 bits/sample are only
possible with very low temperature (e.g. fluid nitrogen cooling)
and I have never seen such a scanner.
Still it is allowed in current SANE and not all frontends will deal
with it gracefully.
But it still makes no sense and I don`t want to waste my time to discuss
thinks that don`t make sense. So please let`s stop to discuss about
that.
Post by René Rebe
Post by Oliver Rauch
Post by René Rebe
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
I stopped listening to the SANE 2 bla bla like 5 years ago when
it became clear to me that the people talking about just want to
talk and not code.
But this is no reason to make SANE-1 unusable by creating incompatible
sane1 versions.
When you think sane2 takes too long then make the sane2 proposal to a
sane3 proposal and create a reduced sane2 proposal. But do not make
sane1 corrupt.
Adding new frametypes does not corrupt anything. Securely and
sanely written frontends will just say "unsupported frame", and the
user can still update to a new frontend that supports jpeg frames.
Also this will continue to just work, as the backends can easily default
to the known RGB frames, until the user hits the JPEG UI element.
Btw. We are already implementing this anyway, as companies
ask for this. It is just a question to get this into vanilla SANE for
all and starting the overdue evolution of SANE, or having some
"we use the GPL SANE and here are our enhancements to
download".
Btw. Can you please be so kind and keep me CC'ed as I can not
monitor all the noisy folder all day while doing work, thanks.
Yours,
Sorry to say that but when you want to discuss the future of sane
than you should read the sane-devel mailing list. When you say you don`t
read the sane-devel mailing list then I get the feeling you are not
interested in the opinion of the other users and developers.

Best regards
Oliver
René Rebe
2007-05-29 16:21:06 UTC
Permalink
Post by Oliver Rauch
Sorry to say that but when you want to discuss the future of sane
than you should read the sane-devel mailing list. When you say you don`t
read the sane-devel mailing list then I get the feeling you are not
interested in the opinion of the other users and developers.
Reading when time permits and following an current discussion
are two different things.

Please learn Netiquette.
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
René Rebe
2007-05-29 16:37:38 UTC
Permalink
Post by Oliver Rauch
Post by René Rebe
Post by Oliver Rauch
Post by René Rebe
Sane already has so many options that are unsupported by
most frontends, yet another frametype will not matter much
at all.
Can you give one good example?
All the option names differ from backend to backend already, making
live for a frontend unnecessarily hard.
And what options are unsupported by frontends?
I already mentioned a few, gamma tables can be abritary, undefined
scan lengh is commonly unsupported, many backends have individual
source names, etc. etc. I already menioned more in the thread.

Aside when you find 16bit and more insane I bet the hell break loose
if a backend yields 10 or 12 bit as depth (as commonly returned by
some scanners, but up-scaled to 16bit to make the frontends happy
today.
Post by Oliver Rauch
Post by René Rebe
Post by Oliver Rauch
Post by René Rebe
If I feel like setting a bitdepth of 32 or 64 bits all frontends
I saw so far will not handle this as well.
This is physically no-sense. Already real 16 bits/sample are only
possible with very low temperature (e.g. fluid nitrogen cooling)
and I have never seen such a scanner.
Still it is allowed in current SANE and not all frontends will deal
with it gracefully.
But it still makes no sense and I don`t want to waste my time to discuss
thinks that don`t make sense. So please let`s stop to discuss about
that.
This was just an example. And when some comapny in Japan thinks
24bit per channel is good (tm) and returns it in a backend you have
to deal with that, now.
Post by Oliver Rauch
Post by René Rebe
Post by Oliver Rauch
Post by René Rebe
Post by Oliver Rauch
Finish the SANE2 standard. That solves all problems.
I stopped listening to the SANE 2 bla bla like 5 years ago when
it became clear to me that the people talking about just want to
talk and not code.
But this is no reason to make SANE-1 unusable by creating incompatible
sane1 versions.
When you think sane2 takes too long then make the sane2 proposal to a
sane3 proposal and create a reduced sane2 proposal. But do not make
sane1 corrupt.
Adding new frametypes does not corrupt anything. Securely and
sanely written frontends will just say "unsupported frame", and the
user can still update to a new frontend that supports jpeg frames.
Also this will continue to just work, as the backends can easily default
to the known RGB frames, until the user hits the JPEG UI element.
Btw. We are already implementing this anyway, as companies
ask for this. It is just a question to get this into vanilla SANE for
all and starting the overdue evolution of SANE, or having some
"we use the GPL SANE and here are our enhancements to
download".
So what about this arguemnts, nothing?

Apparently for most people SANE 1 is good and enough. As well
as in production use. As we saw over the last years interest
in a start from scratch is rare. Adding some new option frame
types only used in some new backends, where the hack is the
the problem?

Probably you only have interst in your home desktop scanner,
but the professional IT companies using SANE in production,
and I happen to work for one from time to time, only care about
a smooth update path with features ready in weeks, not years.
How should open solutions be competive when we have to
wait for some from sratch rewrite that is beeing talked about
for half a decade, now?

And for my private IR scanner, I can live with my private
backend patch and my own frontend infinitely. But whether
that is progress for all - I have my doubts.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
René Rebe
2007-06-02 19:07:17 UTC
Permalink
Hi,
So what is the conclusion of the thread ?
don't now. Response stopped.

For me it means I'll have a private patch, probably inside the T2 SDE:

http://www.t2-project.org/

I can not and will not spend 4 years of recoding SANE just for 2 new
(missing) frame types.

We need to get free software stable, solid and feature complete - not
ever changing.

I do not see any reason to drastically redo SANE just some people
want too, and neither the free coding slaves to do that. There are not
many reasons why the current SANE standard should be abondone.

As far as I can see gradually enhancing it is way more doable and
reasonable and also matches the available developer resources.

Just my thoughs,

René Rebe
m. allan noah
2007-06-02 20:05:32 UTC
Permalink
Post by René Rebe
Hi,
So what is the conclusion of the thread ?
don't now. Response stopped.
http://www.t2-project.org/
I can not and will not spend 4 years of recoding SANE just for 2 new
(missing) frame types.
We need to get free software stable, solid and feature complete - not
ever changing.
I do not see any reason to drastically redo SANE just some people
want too, and neither the free coding slaves to do that. There are not
many reasons why the current SANE standard should be abondone.
As far as I can see gradually enhancing it is way more doable and
reasonable and also matches the available developer resources.
i have spent some time looking at scanimage.c. i think the
modifications required to support the new frame types will be somewhat
more extensive than i had hoped, but it can be done.

however, oliver's objections to API instability have resonated with
me, such that i am hesitant to commit this to sane cvs without a
little more discussion. yes, it could remain a private patch, but i
would like our work to reach the widest audience possible.

i wonder if the best solution is a 'middle road' of starting iterative
development of sane2 based on current sane1. I know folks are hesitant
to begin without the draft spec completed, so maybe this idea is also
a non-starter.

allan
--
"The truth is an offense, but not a sin"
René Rebe
2007-06-02 20:16:49 UTC
Permalink
Hi,
Post by m. allan noah
Post by René Rebe
Hi,
So what is the conclusion of the thread ?
don't now. Response stopped.
http://www.t2-project.org/
I can not and will not spend 4 years of recoding SANE just for 2 new
(missing) frame types.
We need to get free software stable, solid and feature complete - not
ever changing.
I do not see any reason to drastically redo SANE just some people
want too, and neither the free coding slaves to do that. There are not
many reasons why the current SANE standard should be abondone.
As far as I can see gradually enhancing it is way more doable and
reasonable and also matches the available developer resources.
i have spent some time looking at scanimage.c. i think the
modifications required to support the new frame types will be somewhat
more extensive than i had hoped, but it can be done.
however, oliver's objections to API instability have resonated with
me, such that i am hesitant to commit this to sane cvs without a
little more discussion. yes, it could remain a private patch, but i
would like our work to reach the widest audience possible.
i wonder if the best solution is a 'middle road' of starting iterative
development of sane2 based on current sane1. I know folks are hesitant
to begin without the draft spec completed, so maybe this idea is also
a non-starter.
Thing is, Open Source does not work by sitting in a private round
discussing for years - but by actually coding.

None of the successive projects starts programming "when some
draft was done", but the Linux kernel, GNOME, KDE people just
gradually code what is needed and makes sense.

Also note the similar delay in the big major rewrites, such as
GNOME 1.4 -> GNOME 2 or now KDE 3 -> KDE 4 or e.g.
Gimp 1 -> Gimp 2 took.

Just gradually evolving "what is needed" and not what
"someone thinks might be nice in 5 years" is more what
brought the big projects to where they are today.

Yours,
René
m. allan noah
2007-06-03 00:38:30 UTC
Permalink
Post by René Rebe
Hi,
Post by m. allan noah
Post by René Rebe
Hi,
So what is the conclusion of the thread ?
don't now. Response stopped.
http://www.t2-project.org/
I can not and will not spend 4 years of recoding SANE just for 2 new
(missing) frame types.
We need to get free software stable, solid and feature complete - not
ever changing.
I do not see any reason to drastically redo SANE just some people
want too, and neither the free coding slaves to do that. There are not
many reasons why the current SANE standard should be abondone.
As far as I can see gradually enhancing it is way more doable and
reasonable and also matches the available developer resources.
i have spent some time looking at scanimage.c. i think the
modifications required to support the new frame types will be somewhat
more extensive than i had hoped, but it can be done.
however, oliver's objections to API instability have resonated with
me, such that i am hesitant to commit this to sane cvs without a
little more discussion. yes, it could remain a private patch, but i
would like our work to reach the widest audience possible.
i wonder if the best solution is a 'middle road' of starting iterative
development of sane2 based on current sane1. I know folks are hesitant
to begin without the draft spec completed, so maybe this idea is also
a non-starter.
Thing is, Open Source does not work by sitting in a private round
discussing for years - but by actually coding.
i daresay everyone on this list agrees.
Post by René Rebe
None of the successive projects starts programming "when some
draft was done", but the Linux kernel, GNOME, KDE people just
gradually code what is needed and makes sense.
yes- but perhaps those are not the best examples, as linux has binary
incompatability as a goal :), and the other two are not a suite of
drivers with congruent interfaces like sane. they also have not been
stable for years the way sane has.
Post by René Rebe
Just gradually evolving "what is needed" and not what
"someone thinks might be nice in 5 years" is more what
brought the big projects to where they are today.
agreed, but i bet they bumped the soversion alot more frequently than
sane ever has :)

allan
--
"The truth is an offense, but not a sin"
René Rebe
2007-06-03 03:06:27 UTC
Permalink
Post by m. allan noah
Post by René Rebe
Hi,
Post by m. allan noah
Post by René Rebe
Hi,
So what is the conclusion of the thread ?
don't now. Response stopped.
http://www.t2-project.org/
I can not and will not spend 4 years of recoding SANE just for 2 new
(missing) frame types.
We need to get free software stable, solid and feature complete - not
ever changing.
I do not see any reason to drastically redo SANE just some people
want too, and neither the free coding slaves to do that. There are not
many reasons why the current SANE standard should be abondone.
As far as I can see gradually enhancing it is way more doable and
reasonable and also matches the available developer resources.
i have spent some time looking at scanimage.c. i think the
modifications required to support the new frame types will be somewhat
more extensive than i had hoped, but it can be done.
however, oliver's objections to API instability have resonated with
me, such that i am hesitant to commit this to sane cvs without a
little more discussion. yes, it could remain a private patch, but i
would like our work to reach the widest audience possible.
i wonder if the best solution is a 'middle road' of starting iterative
development of sane2 based on current sane1. I know folks are hesitant
to begin without the draft spec completed, so maybe this idea is also
a non-starter.
Thing is, Open Source does not work by sitting in a private round
discussing for years - but by actually coding.
i daresay everyone on this list agrees.
Post by René Rebe
None of the successive projects starts programming "when some
draft was done", but the Linux kernel, GNOME, KDE people just
gradually code what is needed and makes sense.
yes- but perhaps those are not the best examples, as linux has binary
incompatability as a goal :), and the other two are not a suite of
drivers with congruent interfaces like sane. they also have not been
stable for years the way sane has.
That is not exactly true. The user-land interface never changed. You
can run 7 year old programs and libraries, even A.OUT ones , still.

I'm out of office for the next weeks, so replays will not happen often.

Cu,
--
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
m. allan noah
2007-06-29 21:12:40 UTC
Permalink
well, after letting this sit for a few weeks to see if i could think
of a better way, i stumbled across the fact that the sane backend for
bell and howell scanners already supports 3 additional frame types.
they are used to send variants of G4 fax, and the text that comes from
a hardware bar/patchcode reader. this code has been a part of sane for
years, and it has not hurt anyone.

therefor, i am moving ahead with adding other frame-type support to
the mainline fujitsu backend. i will put the additional frametype
defines in sane.h, unless there are valid objections. i may also move
the ones that are in bh, too, so that the list remains unique.

allan
--
"The truth is an offense, but not a sin"
René Rebe
2007-06-30 07:14:16 UTC
Permalink
Hi,
Post by m. allan noah
well, after letting this sit for a few weeks to see if i could think
of a better way, i stumbled across the fact that the sane backend for
bell and howell scanners already supports 3 additional frame types.
they are used to send variants of G4 fax, and the text that comes from
a hardware bar/patchcode reader. this code has been a part of sane for
years, and it has not hurt anyone.
therefor, i am moving ahead with adding other frame-type support to
the mainline fujitsu backend. i will put the additional frametype
defines in sane.h, unless there are valid objections. i may also move
the ones that are in bh, too, so that the list remains unique.
Oh nice! Thanks for digging up this prior art, did not saw this yet either.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
René Rebe
2007-07-27 10:25:17 UTC
Permalink
Post by René Rebe
Hi,
Post by m. allan noah
well, after letting this sit for a few weeks to see if i could think
of a better way, i stumbled across the fact that the sane backend for
bell and howell scanners already supports 3 additional frame types.
they are used to send variants of G4 fax, and the text that comes from
a hardware bar/patchcode reader. this code has been a part of sane for
years, and it has not hurt anyone.
therefor, i am moving ahead with adding other frame-type support to
the mainline fujitsu backend. i will put the additional frametype
defines in sane.h, unless there are valid objections. i may also move
the ones that are in bh, too, so that the list remains unique.
Oh nice! Thanks for digging up this prior art, did not saw this yet either.
I just notice scanadf includes the same custom-copy of "non-basic"
FRAME types:

1.1 (tommarto 12-Jan-02): #ifndef sane_isbasicframe
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_TEXT 10
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_JPEG 11
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_G31D 12
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_G32D 13
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_G42D 14
1.1 (tommarto 12-Jan-02): #define sane_strframe(f) ( (f) == SANE_FRAME_GRAY ? "gray" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RGB ? "RGB" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RED ? "red" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_GREEN ? "green" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_BLUE ? "blue" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_TEXT ? "text" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_JPEG ? "jpeg" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_G31D ? "g31d" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_G32D ? "g32d" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_G42D ? "g42d" : \
1.1 (tommarto 12-Jan-02): "unknown" )
1.1 (tommarto 12-Jan-02):
1.1 (tommarto 12-Jan-02): #define sane_isbasicframe(f) ( (f) == SANE_FRAME_GRAY || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RGB || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RED || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_GREEN || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_BLUE )
1.1 (tommarto 12-Jan-02):
1.1 (tommarto 12-Jan-02): #endif

Unbelievable this was not added cleanly to SANE back in 2002.

We certainly want to change the bh backend and scanadf to use the
SANE FRAME_JPEG, these days.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
Geschäftsführer: Susanne Klaus, René Rebe
Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
USt-IdNr.: DE251602478
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
René Rebe
2007-07-27 10:44:27 UTC
Permalink
Post by René Rebe
Post by René Rebe
Hi,
Post by m. allan noah
well, after letting this sit for a few weeks to see if i could think
of a better way, i stumbled across the fact that the sane backend for
bell and howell scanners already supports 3 additional frame types.
they are used to send variants of G4 fax, and the text that comes from
a hardware bar/patchcode reader. this code has been a part of sane for
years, and it has not hurt anyone.
therefor, i am moving ahead with adding other frame-type support to
the mainline fujitsu backend. i will put the additional frametype
defines in sane.h, unless there are valid objections. i may also move
the ones that are in bh, too, so that the list remains unique.
Oh nice! Thanks for digging up this prior art, did not saw this yet either.
I just notice scanadf includes the same custom-copy of "non-basic"
1.1 (tommarto 12-Jan-02): #ifndef sane_isbasicframe
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_TEXT 10
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_JPEG 11
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_G31D 12
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_G32D 13
1.1 (tommarto 12-Jan-02): #define SANE_FRAME_G42D 14
1.1 (tommarto 12-Jan-02): #define sane_strframe(f) ( (f) == SANE_FRAME_GRAY ? "gray" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RGB ? "RGB" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RED ? "red" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_GREEN ? "green" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_BLUE ? "blue" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_TEXT ? "text" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_JPEG ? "jpeg" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_G31D ? "g31d" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_G32D ? "g32d" : \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_G42D ? "g42d" : \
1.1 (tommarto 12-Jan-02): "unknown" )
1.1 (tommarto 12-Jan-02): #define sane_isbasicframe(f) ( (f) == SANE_FRAME_GRAY || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RGB || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_RED || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_GREEN || \
1.1 (tommarto 12-Jan-02): (f) == SANE_FRAME_BLUE )
1.1 (tommarto 12-Jan-02): #endif
Unbelievable this was not added cleanly to SANE back in 2002.
actually, not unbelievable at all. i guess tom did not want to start a fight :)
Probably he was not trained from linux-kernel :-)
Post by René Rebe
We certainly want to change the bh backend and scanadf to use the
SANE FRAME_JPEG, these days.
yes- i intend to do this in a month or so (very busy ATM), but i
hesitate to change bh backend, since it's not mine :)
Well - the only problem is that since the now official FRAME_JPEG
has another enum value a new bh backend would pass the JPEG
data with another FRAME value, so the modified bh backend would
only function correctly with an equally updated scanadf.

This non-mainstream FRAME tinkering from 4 years ago is a little
problematic today.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Continue reading on narkive:
Loading...