<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
