I think we should reduce the amount of distinction of the
frame formats to the most limited number that is able
to incorporate all the functionality.
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.
Don't forget that the design choices for SANE were made
so that the frontend does not need to know exactly
what the scanner is doing, only what data it will receive
so that it can dispatch it (to an image processing software or to a file).
The user selects the scanning options the way he wants
and is thereby responsable of interpreting the results
accordingly, he cannot rely on the frontend to do that for him.
(An exception to this are the RGB values that the frontend
wants to interpret to show the preview)
When the user asks for scanning of infrared, he will get a 4th channel
that is infrared, if he asks for a height field it will be
a hight field. If he prefers to interpret the infrared
channel as a height field - that's his choice.
If we want to transfer the information of the INTERPRETATION
of the frame content to the frontend we may want to create
different fields that explain how the image was obtained.
This may include a detailed description of the scanners
capabilities (lamp spectum, CCD sensibility curves, pixel size,
MTF, noise characteristics, positioning precision, user gamma-LUT used).
Defining all this is a tough subject and will take a while.
This should not prevent us from going ahead and implementing
support for a 4-th channel or compressed data handling.
A first step to incorporate the above into SANE in would be to
add:
SANE_FRAME_RGBA
SANE_FRAME_COMPRESSED
The frontends than can save the first format in to any alpha-channel
aware format and write the second format blindly to disk
in the hope that the user knows how to read them.
If you prefer we can also add different names for different
compression formats like:
SANE_FRAME_JFIF
and the frontend may dump any format it can't understand
blindly into a file.
In order to limit somewhat the number of SANE_FRAME formats I suggest
that anyone who wants to add a format, has to deliver a
precise specification of the format to the SANE project so
that anyone can write a frontend for it.
Andreas
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com