[sane-devel] SANE_FRAME_JPEG support

[Gerard Klaver]

<lines deleted>
On Tue, 2007-07-10 at 13:38 -0400, m. allan noah wrote:

> ---------- 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"
> 

I agree, adding a raw mode is useful for debugging.
-- 
--------
m.vr.gr.
Gerard Klaver