> The SANE parameter 'depth' can remain what is currently (ie the native
> depth), and not setting it to 16 for depths>8. Then we don't need a
> new parameter.
Personally, I vote for a separation between "actual" depth and
"transmission" depth. I like the option of writing code driven entirely by
the parameters, and not by "arbitrary" rules about certain parameters. In
this case, overloading 'depth' this way would mean that depth=1 would
imply 1-bit transmission, 8 >= depth >1 implies 8-bit transmission, etc.
But I don't like where that leaves us when we support 24-bit or 32-bit
transmission. I'd prefer if a frontend could be safe just acting on the
data it was given.
> On the subject of new additions to the SANE standard, perhaps it's
> good to add a SANE_FRAME_RGBI frame format in anticipation of support
> for filmscanners with the Digital ICE feature (it's an extra infrared
> channel to localize scratches and dust on the film).
If we go this route, may I suggest calling it SANE_FRAME_RGBIR instead?
RGBI already has meaning (RGB+Intensity) in the video world.
However, it might at this point make sense to revisit the general frame
description mechanism. Something more self-describing, like the way
parameters work, might give us more flexibility in responding to whatever
cool new tricks the imaging device vendors throw at us. But I don't have
any fleshed out ideas :-)
-- Tripp Lilley + Innovative Workflow Engineering, Inc. + (tripp@iweinc.com) ------------------------------------------------------------------------------ "You know, this /is/ kinda like the community room in a mental ward."
-- Mary Papadopoulos (roommate), commenting on our office/rec room
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com