On Tue, 3 Aug 1999, Oliver Rauch wrote:
> If the nikon coolscan is the only device that uses an IR channel, the nicon
> backend
> is the right place for the filter and the backend will send a SANE_FRAME_RGB
> to the frontend. In that case we would not need a SANE_FRAME_RGBI.
No - just because it is POSSIBLE to do heavy duty processing in the backend
doesn't mean that it is necessary or desirable to do so.
> If there are other backends that support scanners with IR channel, it would
> be
> a good idea to position the filter between backend and frontend - a kind of
> "midend",
> this would be somenthing like the sane-dll that handles as a backend for the
> frontend
> and looks like a frontend for the backend. In that case it would be the right
> way to add SANE_FRAME_RGBI to the standard.
This has the same disadvantage as above, and all the wrong behaviour for the
user, unless we also had lots of behind-the-scenes features to make it
more transparent for them.
> It does not make sense to include this filter into each frontend. We would
have
> to write it for each frontend (scanimage, xscanimage, xsane,
staroffice-scan-UI
> and others). Then it would be better to include it into the coolscan backend.
>
> If the filter is included into an external program, we do not need a
> SANE_FRAME_RGBI,
> then it would be better to pass the data as a SANE_FRAME_RAW.
Why? As far as I can see, there are only disadvantages to SANE_FRAME_RAW
> SANE_FRAME_RGBI. As long there is no such filter we do not need this
> frame type!
No. We need this frame type to send RGBI data through SANE.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com