Scan Size Clarification and JPEG/whatever format data

Sean Reifschneider (jafo@tummy.com)
Fri, 23 Oct 1998 03:52:30 -0600

It's not entirely clear to me from the draft document how soon after
doing a "start scan" that it's expected the X and Y image size will
be known. The back-end I'm working on right now doesn't actually
have the exact size (only an estimate because of auto-page-size
detection) until after the first data read has completed.

I suspect that some front-ends will expect it to be accurate before
reading the first data-block (for writing a header or allocating
the image buffer).

Also, in the JPEG/MPEG/RAW image format arena... I would propose that
the only additional image type to be added be "RAW", with a standard
option presenting the available image formats. The front end would
then request a specific format through the normal channels, the back-end
would send it as RAW, and the front-end would either decode it or
just write the raw bits to a file.

This is in keeping with the idea that the protocol just be the medium
which the frontend and backend communicate. If a back-end implements,
say, G3 compression, and the front-end knows how to handle that, it's
not an issue. As soon as you encode these values into SANE itself,
you get into the business of having to track everyone's pet format.

For the time being, it looks like I'll implement this using just the
standard GREY format.

Also, any suggestions on the best back-end to use as a model for a new
one would be appreciated.

Thanks,
Sean

-- 
 A smart terminal is not a smart*ass* terminal, but rather a terminal
 you can educate.  -- Rob Pike
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.





--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com