On Sun, 29 Aug 1999, abel deuring wrote:
> Another somewhat exotic example are some old drum scanners:
> At least the combination of a Crosfield Magnascan scanner
> and a Sun IPC box with special control software for this
> scanner produces TIFF files with CMYK data. I don't know, if
> the RGB -> CMYK transformation is done in the IPC box or in
> the scanner, but since these scanners were some years ago
> directly connected to imagesetters, I assume that the RGB ->
> CMYK transformation is done by the scanner. While it is
> mathematically quite easy to make again a CMYK -> RGB
> transformation, this means a loss of information. A good
> CMYK representation knows about specific details of the
> printing technology: CMYK data for an ink jet printer can be
> quite different from CMYK data for an offset printing press.
CMYK was discussed before, the main thing I remember was - What
the hell is in the black channel? In print processes it makes
sense to have K vs CMY but in scanning it's far from obvious...
TIFF is just nasty. Don't believe me? Read libtiff and/or my
Gimp plug-in :)
> A more common situation might be a scanner / backend
> combination which delivers colour calibrated data, generally
> represented in the XYZ colour space or colour spaces derived
> from XYZ, like CIELab. While up to now nobody in the Sane
> community has cared about colour calibration, this could
> become an issue, if Sane is implemented for Mac OS X: Since
> Mac OS X is basically a Unix, it should be not too difficult
> to get Sane running. On the other hand, the prepress
> industry, the stronghold of Mac computers, is increasingly
> using colour calibration, so that Sane would be not that
> useful for many Mac users, if an integration of colour
> calibration into Sane turns out to be quite difficult. More
> informations on colour calibration can be found at
> http:://www.color.org (especially about the ICC standard),
> and at http://www.fogra.org (unfortunately, the latter site
> contains much of its informations only in German).
Interesting... do we have anyone who has such a beast and can
describe what's really coming out of the hardware? Of course in
the normal case calibration is outside of SANE's remit (though
it needn't always remain that way I suppose) but if some hardware
can send us sRGB, CIE or whatever pre-calibrated that is cool.
> So far about requirements on new or additional data
> representations and contents. Now, what is the attraction of
> the Sane standard and of the Sane software package? For me,
> as a person working on a backend for an "ordinary" flatbed
> scanner, there are three points:
>
> - The "OS abstraction layer" sanei_scsi.[ch] enables the
> backend to run on a number of different Unixes.
>
> - The API defined by the Sane standard is simple in the
> sense the I do not have to deal with a user interface (with
> the exception of declaring a bunch of options);
>
> - but it is nevertheless quite powerful in that a backend
> can declare a wide variety of options, so that the
> capabilities of a scanner can be easily presented to a
> frontend and a user.
>
> n interesting detail about the last point is that the
> frontendA generally does not know anything about the meaning
> of the options. (The "well known options" like tl-x are of
> course an exception.)
Yes, but there are some assumptions which tend to made above and
beyond the well-known options. Some of these should be formalised
and some might need to be deprecated.
> A similar viewpoint could be taken on the scan data: At
> least a generic frontend like xscanimage or scanimage does
> not need to know anything about the data content: It's task
> is mainly to control the scanner and to feed the scan data
> to another program or into a file. (Oliver's xsane is
> somewhat different, since it is able to perform
> manipulations on the scan data, like gamma correction.)
We should expect MORE power in frontends in the future, so XSane
will be _typical_ in the future. I think stuff for film scanning
and for high-speed document scanners is planned. OCR should
happen one of these long days. It's not just the user who cares
what's in the datastream -- the application cares just as much.
> Regarding scanner control, a preview should of course be
> possible, if this makes sense for the particular device, and
> in this case a backend should be able to deliver preview
> data in a "well known format" like SANE_FRAME_RGB or
> SANE_FRAME_GRAY. 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.
>
> - 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. In the latter
> case, the backend must support the frontend by giving hints
> how to handle the data. At present, I don't know if these
> hints should have the form of MIME types, as Andy suggested,
> or if there might be better ways. Probably the most complex
> question is how to handle several sets of different data for
> one scan, like the additional bar code data produced by
> these high speed scanners: Should all these data be
> considered as one data stream by the backend / frontend API,
> or should there be provisions to allow multiple data
> streams? I am sure that Tom Martone and other people working
> with this class of scanners have already thought about it,
> so I would like hear comments from them.
There is a provision for multiple data frames, so the question
is: Should we use it for this in SANE 2.0, and I think the
answer has to be "Yes", unless there's a better idea.
(SANE 1.0 doesn't use multiple data frames for this purpose,
but it does provide them for several other reasons anyway)
> Finally, I think that a major revision of Sane should
> include language support. I know some users who would really
> appreciate it, if it would be possible to display e.g. the
> resolution option as "Auflösung".
Yes, this would be very nice.
> A very rough, incomplete and perhaps too simple suggestion
> for two library functions:
>
> Instead of simply displaying a variable of the type
> SANE_String, a frontend should call a function
>
> SANE_String* sane_translate_from_english(const SANE_String* text,
> const SANE_String* language)
I think this is just gettext, but someone else will no doubt explain
why gettext doesn't buy much for SANE. Alternatively maybe you mean
to pass this function through to the backend?
> When handing a SANE_String value to the backend, a frontend
> should call
>
> SANE_String* sane_translate_into_english(const SANE_String* text,
> const SANE_String* language)
Not sure what this is for. Hopefully someone else can address it.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com