> On Tue, 3 Aug 1999, Andreas Rick wrote:
> > The problem with defining all thinkable formats is that it
> > adds a considerable amount of complexity to the frontend
> > which is only used for one specific backend which is able
> > to produce that one particular data-type.
>
> And if we don't, we don't get any functionality for that particular data
> type. So I don't see what we're losing.
If an image generating device uses its own data format there are
two ways to handle this:
1) The backend transforms it into a known data format
2) The backend sends this data as a raw data to the frontend
that saves it without any transformation.
> The infrared channel is not
> useful unless you know what to do with it -- it's not "REAL" image data
> in the usual sense.
That is exactly what I say and so why should we add a special frame format
for it if it does not make sense?
> It's a trap. The data flow depends only on number of channels, which
> we already know. So now I wonder why SANE defines all these FRAME types
> if not to tell me what's inside the frame...
The backend does not tell you what is in the frame, it tells the frontend
what is in the frame. And if you don`t tell me how xsane shall handle this,
xsane will not handle this.
> If I treat an infrared scan from my Nikon Coolscan as simple RGBA, I
> will get nonsense out. The scanner knew what was in that data, and
> SANE knows right now. But with Oliver's design, suddenly SANE forgets
> this useful knowledge, and I just have junk in my alpha channel
Ok SANE knows what is in that data.
And I now ask again. How shall a frontend handle this knowledge?
> NB Just because you can't save "channel 4 is infrared" in PNG, doesn't
> mean you can't export the fouth channel directly to Gimp as
> "Additional channel: Name: Infrared, Colour: Orange 50%", and let a
> Gimp plug-in do the rest. You can even attach a parasite (in 1.1.x)
The sense of SANE is not ONLY to be a plugin for the GIMP.
We need to now what we have to do if we do not run as GIMP plugin!
If we add a multi channel format with not-visible bands we should
add a more general format that can handles (n) channels
and the backend tells the frontend in a string what is in each channel.
Then you also can write a backend for a (radio-) telescope and the (radio-)
telescop backend tells the frontend:
channel 1=gray
channel 2=infrared
channel 3=ultraviolett
channel 4=gamma rays with wavelenght xyz
channel 5=gamma rays with wacelength abc
But we also need a format to save this channels.
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