Not now - but I'm sure this is about to come ;-|
5% on internet use is already under evaluation :-(
> Maybe I'm being REALLY REALLY STUPID here, but I can't see any down side
> to knowing what the **** was in the data stream before someone like
> Oliver decides to turn it into a JPEG and save it in a file.
I don't think that "knowing" anything about the image hurts.
I just don't want the frontend get confused about so many
formats and say "I can't handle this format" because I tell
it about the same data in 20 different ways.
I just want to tell it: Here come 4 channels, the first 3 are
RGB (which you may use for preview or other stuff)
and the last one is something I want to be able to save
as alpha channel to png or to gimp.
I have no objections to add
SANE_FRAME_G3
SANE_FRAME_G4
SANE_FRAME_JFIF
SANE_FRAME_RGBI
SANE_FRAME_TEXT
and anything you want , but I would like to see at least:
SANE_FRAME_RAW
SANE_FRAME_RGBA
too.
The next version of the coolscan LS-30/2000 backend will probably use
SANE_FRAME_RGBA for the 4 channel images, just because there
is are backends that can handle it the way I want (xsane / (x)scanimage).
I think all this confusion comes from the fact that we
are mixing up two thing in SANE_FRAME_???, the first one is
-- the handeling of the data and the second one is
-- the interpretation of the data (or its origin).
Right now the only link of the 4th channel of a Coolscan scanned
image to "infrared" is that it has been scanned with an infrared LED as light
source. After that I'm doing all kinds of transformation on it
which mix R,G,B and I (and I will do even more in the future)
to make it show only the dust in the image, and not the
color information. That is to say: when you get the 4th channel
out of the backend it is no longer an "infrared" image but a
"dust" image, so we might as well define SANE_FRAME_RGBD(ust).
> If you have some genuinely unexplained data, which can't be classified,
> what makes you think anyone wants to process it anyway?
You forget about the fact that there might be a user of
a SANE system who knows more about the Scanner than the frontend.
SANE was designed with this in mind, as the frontend can
propose options of the backend to the user without knowing what
they do.
The user might want to tell the frontend to go ahead and save the data
the frontend has no interpretation for (just save it, don't mess with it)
After that he uses his knowledge (and his favoured programs)
to do marvelous things whith the data.
Andreas
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com