[sane-devel] SANE_FRAME_JPEG support

[m. allan noah]

for those that are not subscribed to sane-commit, i will forward part
of a mail, and describe my recent changes...

---------- Forwarded message ----------
Modified: ChangeLog backend/fujitsu-scsi.h backend/fujitsu.c
          backend/fujitsu.h frontend/scanimage.c include/sane/sane.h

* backend/fujitsu.[ch], backend/fujitsu-scsi.h: update to v1.0.50,
  add JPEG support, usb command sending and scan params cleanups
* include/sane/sane.h: add SANE_FRAME_JPEG
* frontend/scanimage.c: dont crash on unknown frame types

------------------------+
 ChangeLog              |    7
 backend/fujitsu-scsi.h |   19
 backend/fujitsu.c      | 1037 ++++++++++++++++++++++++++++++++++-------------
 backend/fujitsu.h      |   32 +
 frontend/scanimage.c   |   11
 include/sane/sane.h    |    3
 6 files changed, 823 insertions(+), 286 deletions(-)


Diff URLs:
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/ChangeLog.diff?f=h&cvsroot=sane&r1=1.3080&r2=1.3081
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/fujitsu-scsi.h.diff?f=h&cvsroot=sane&r1=1.19&r2=1.20
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/fujitsu.c.diff?f=h&cvsroot=sane&r1=1.61&r2=1.62
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/fujitsu.h.diff?f=h&cvsroot=sane&r1=1.31&r2=1.32
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/frontend/scanimage.c.diff?f=h&cvsroot=sane&r1=1.43&r2=1.44
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/include/sane/sane.h.diff?f=h&cvsroot=sane&r1=1.6&r2=1.7

---------- End Forwarded message ----------

hopefully those Urls will come thru ok. The changes to the fujitsu
backend to support hardware jpeg were more extensive than i would
like, but the changes to sane.h and scanimage were actually quite
small.

basically, sane.h just got SANE_FRAME_JPEG added to an enum. scanimage
had a fixed-size array of string names for each frametype, and was
using that array in two places to print informational messages. if it
got a frame type that was off the end of the array, bang!

so, i just added JPEG to the end of the array. then, just to be sure
this would not bite the next programmer, i added a little ternary test
any time we look in that array. instead of walking off the end, we
print "Unknown".

my observations: if a backend sends a 'standard' frame type like RGB,
and then sends a jpeg (or other unknown) frame, a proper tiff or pnm
header and data will be written, and the additional frame will be
appended, corrupting the image.

if a backend sends those in reverse order, there will be no tiff/pnm
header, because scanimage only sends those on the first frame of a
known type. the data will consist of all the frames in order received.

I would like to get some opinions about more complex scanimage
modifications before i move on to scanadf. namely, should scanimage
ignore these new frame-types, instead of putting them in the output?
in that case, it would require another format option besides the ones
we have now (tif/pnm) perhaps 'raw'? i personally would find a raw
option useful for debugging the standard frame types too...

comments?

allan

-- 
"The truth is an offense, but not a sin"