> Oliver, please use a mail client which can do proper line wrap, it is
> getting annoying to keep reformatting your text so that it is readable
> in the replies.
>
> On Tue, 3 Aug 1999, Oliver Rauch wrote:
> > It is not good to add one format that does not make sense. So we should
> > not wait until we have 5 bad formats.
> >
> > I don`t say that we should not add SANE_FRAME_INFRARED or RGBI.
> > I only say it does not make any sense if we do not define how to save
> > and handle them.
> >
> > As long as there is no file format for RGBIr and another one for RGBUv
> > and we have to handle it the same way and ony the user knows the difference,
> > why should we add two different formats for this.
>
> Stop obsessing over file formats Oliver. If all you are going to do is
> save it as a JPEG and put it on the web, then just don't choose "Infrared
> mode" from the Coolscan backend.
>
> To handle RGBI you should apply a filter which can compensate for the
> scratches, prints, dust etc. revealed on the Infrared channel. You also
> need to compensate for the leakage between RED and IR detection.
Ok, now you make a suggestion that does bring us a bit forward!
Write a filter for that or find someone who does it.
> If a frontend doesn't have such a filter, it has two choices -- it can
> refuse to handle the unknown FRAME type, or it could send the data for
> post-processing in another application. I really DO NOT CARE whether
> XSane can handle this, or not -- just so long as SANE makes it possible
> for someone to write a SANE-compliant application which does it.
>
> Understand me here Oliver -- this is not about adding features to
> XSane, or not adding them, it is about supporting the Coolscan in SANE
The question is if the filter should be included in the backend, the frontend,
an external program or between backend and frontend.
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.
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.
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.
I suggest you write that filter and if you implement it as "midend" we will add a
SANE_FRAME_RGBI. As long there is no such filter we do not need this
frame type!
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com