# Re: SANE V2 - again...

Milon Firikis (milonf@ariadne-t.gr)
Mon, 30 Aug 1999 13:31:29 +0300

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Oliver Rauch: "Re: SANE V2 - again..."
- Previous message: Nick Lamb: "Re: SANE V2 - again..."
- Maybe in reply to: abel deuring: "SANE V2 - again..."
- Next in thread: Oliver Rauch: "Re: SANE V2 - again..."

abel deuring wrote:
>
> Hi all!
>
> During the last weeks, some really interesting
> discussions have started in this mailing list, especially
> the one about interoperability of SANE and TWAIN, and the
> one about the future of the SANE standard.
>
> The latter became unfortunately quite personal, and some
> mails were not very fair, in my opinion. The debate about
> mime types versus more frame types has thereby reached a
> dead end, and I don't want to make an immediate contribution
> to this discussion. Instead, I'll try to go a step back to
> discuss, which new demands appeared, and to outline how
> these demands might be approached with Sane.

You are the voice of reason in person :-)

[snip a lot of background info]

> Therefore, my suggestion is to split the
> requirements for the scan data format and scan data content
> into two parts:
>
> - The preview data may be only in SANE_FRAME_GRAY,
> SANE_FRAME_RGB, SANE_FRAME_RED, ...GREEN, ...BLUE. If
> necessary, the backend must transform some other internal
> data content or data representation into one of these
> formats. (For "better known" data representations like
> xyz-compression and "better known" data contents like RGB +
> "infrared for dust removal" library functions might be
> developed which transform the scan data into RGB or gray
> scale.

YES!!!!. I agree though I do not volunteer to write the above libraries
:-)

The point is:

Why a frontend needs to know what is the content of data?

PREVIEW is the one reason, but I can't find anything else. I you have a
specialized application which does OCR for example it should be able to
read from a file anyway. If, let's say, the OCR application wants to be
a SANE frontend, then let it be, but it should read in a standard
compliant way, anyway. A frontend needs to know how to read the data
only to preview them. If I am wrong please raise hands.

>
> - The "real" scan data may be either in the same format as
> the preview data (if this is reasonable for the particular
> device), or in a format chosen by the backend.

[snip]

Yes, TRUE, SANE_TRUE, I agree.

[snip]

>
> Finally, I think that a major revision of Sane should
> include language support.

I won't comment on the language support. But since we are talking about
new documented capabilities (SANE standard revision) I would like to see
some means for:

-reading files with array of numbers as information. This would be
useful to read/save/store
-Gamma Tables
-Calibration vectors (3x256)
-Color Correction tables (3x3 integer matrix)
-Halftone patterns (4x4, or 8x8 PGM images)

Some of them may be "well known options" like the Gamma tables.
Currently SANE provides some way of downloading GAMMA tables but the
procedure is not well documented IIRC.

Apple backend needs all of them for the later models of apple.
Unfortunately I don't have access to any of them.

MF

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Oliver Rauch: "Re: SANE V2 - again..."
- Previous message: Nick Lamb: "Re: SANE V2 - again..."
- Maybe in reply to: abel deuring: "SANE V2 - again..."
- Next in thread: Oliver Rauch: "Re: SANE V2 - again..."