> > 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 :)
I know that CMYK data is not that easy to handle. But as I said, the
example of CMYK data from a scanner is somewhat exotic. I tried to
mention it only as just _one_ example of a data format not yet discussed
regarding further development of the Sane standard. If anybody is really
interested in a more detailed discussion about CMYK, its importance in
the [pre]press industry, things like undercolour removal, black
generation, algorithms for CMYK -> RGB conversion or whatever, please
let me know. But I think that this leads away from the issue "Sane
Version 2".
> > 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.
I did not claim that there are any devices delivering data in XYZ or any
other device independent colour space on their output connector. But
considering Mac OS X, it is worth to discuss, if Sane can and/or should
be _prepared_ for colour calibration, or if this completely unnecessary.
Of course, a complete system to handle colour calibration is far beyond
the scope of Sane -- but scanning software can be integrated into a
colour management system.
> > 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.
Maybe that an OCR program will include its own interface to Sane
backends -- but right now I don't why an OCR developer should do this
works, since xscanimage and xsane already can do the job.
> 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)
If I saw only an already (or mainly) solved problem, the better.
> > 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?
If I saw only an already solved problem, the better.
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com