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. The infrared channel is not
useful unless you know what to do with it -- it's not "REAL" image data
in the usual sense.
Also, you are falling into the same trap as Oliver with regard to the
number of additional formats. Since SANE's inception, only one new
format has been added and probably only one or two more will be needed
to fulfill the needs of every commercially-available type of scanner.
> By this I mean there should be a different frame format
> only if the data-flow in the frontend is impacted.
> There typically is no different data-flow for a
> RGB-Infrared image or a RGB_Ultraviolet image so it
> is acceptable to have the same SANE_FRAME format.
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...
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
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)
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com