Matt> Looks like right now the entire image must be
Matt> buffered,converted and then sent to the frontend piecemeal
Matt> (kind of like the fake pnm driver). Can't imagine that the
Matt> current API would allow any other approach, as it "steals"
Matt> away the data as soon as it arrives from the scanner; no
Matt> chance for subsequent manipulation.
The idea would be to make it as incremental as possible. I'm not too
familiar with JPG details, but you might be able to get away with
buffering just 16 lines at a time (assuming JPG uses a 16x16 pixel
blocks). Buffering the entire image is _definitely_ something to
avoid whenever possible. Note, however, that this buffering is
inherently necessary due to the mismatch between source and
destination format---it's not due to a limitation of SANE's read()
interface.
Matt> Wondering if Rasterman's Imlib would be a good way to go for
Matt> image conversion. Supposedly it can display and convert all
Matt> kinds of formats. (haven't programmed with it, only used it)
Could be, but again the incremental feature is important. Scanned
images can be huge and the less buffering the better.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com