> :) I guess I'll hold of >8bit support until there is some agreement on it. I
> can tell you right now that if my frontend has to specifically support
> different scanners for >8bit that it ain't going to happen. I doubt this is
> the desire of the SANE project either.
There already is agreement on the SANE standard, the source of disagreement
is Ewald's (as yet unreleased) frontend, and perhaps the HP backend, which
are apparently non-compliant. There are no end of non-compliant and down
right broken components in the sample implementation, so when the
behaviour you see in a SANE component disagrees with the standard, it's
usually because the observed behaviour is wrong.
I think I got the most vital examples fixed for 1.0.1, so you should get
that if you're having problems. I am working on a testbed backend, complete
with 12-bit and 16-bit support but it won't be finished for a while yet.
> Which is MSB xxxxxx98 76543210 is the way that the HP backend data then it
> is perfectly acceptable, lame but acceptable. It just doesn't scale the
> value and the image will need to be brightened... if it is bit packed then
> that is a problem.
I'm still hoping this is a dreadful mistake in the HP backend, and the
actual hardware format doesn't resemble this at all. It's an incredibly
stupid alignment, not least because it's not convenient for any apps,
except perhaps Ewald's (as yet unreleased) frontend. If they've done this
in hardware, SANE compliance is the least of their worries.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com