[sane-devel] Color profiles with SANE?

abel deuring a.deuring@satzbau-gmbh.de
Wed, 21 Aug 2002 00:35:15 +0200


Major A wrote:
>>I'm afraid that you will not have much luck with the current Sane 
>>version. But I think that ICC profiles should be supported in Sane 2. 
>>(With littlecms (http://www.littlecms.com) we have a good LGPL-ed ICC 
>>library available, so we _can_ actually support ICC. And with Scarse - 
>>Scanner CAlibration ReaSonably Easy - http://www.scarse.org/ - there 
>>even a calibration tool under development.)
> 
> 
> Also, never forget gcms, which is under GPL...

Seems that I have to learn auite much about free CMS implementations 
(and CMS in general) ;)

> 
> 
>>While most of the calibration stuff should be done in the frontend, I 
>>think that the backends should be able to provide the ICC profiles. The 
>>profiles are closely tied to a certain device, and, as Rene mentioned, 
>>it is not very convenient to configure a number of workstations in a 
>>network for the same scanner. And a backend could automatically select 
>>the right profile, when for example a transparency adapter is switched 
>>on or off. Film scanners might provide special profiles for different 
>>film types.
> 
> 
> I agree. It should be possible to extract the profile from the
> backend. Once this is done, it should be pretty easy to incorporate an
> ICC library into a frontend like xsane. The harder part will of course
> be having part of the colour conversion done by the scanner, with the
> LUTs. On scanners with >8bit output, this shouldn't make much of a
> difference in quality, though.

Well, that's a problem of how much quality you can a expect from a 
scanner with an 8 bit ADC. And as far as I understand the ICC concept 
(which isn't much), you simply stuff the ICC profile into the TIF file 
that contains the image. If you want to print the image, you convert 
this file from the input color space to the color space of the printer. 
So you need, at least in this simple situation, only one color 
conversion (well, actually two: from the imput color space to XYZ or Lab 
or whatever, and from that space to the printer's color space -- but 
LCMS/GCMS probably don't use internally 8 bit integer for this purpose), 
so that you don't lose that much information even with 8/24 bit scan images.

> 
> 
>>I don't think that we need some additional functions in the Sane API for 
>>this purpose -- it would probably be enough to define an additonal frame 
>>type, or even only to add something like a "well known mime type" for 
>>SANE_FRAME_MIME.
> 
> 
> Or we could simply add a standard option that gives the frontend the
> name of the file. This, of course, would mean that the computer with
> the frontend has to have the profiles in a known place, but it also
> relieves the backend from doing it's own file i/o.

File pointers might become a bit problematic if you use network 
scanning. Imagine to set up a network with, say, 20 Windows and 10 
Unix/Linux clients to access the ICC file in a consistent way: You'll 
need to provide NFS/Samba shares (and if somebody considers to implement 
a Sane frontend for MacOS <= version 9, also Netatalk shares) and you 
have to configure all clients to get access to this share. OTOH, using a 
file pointer might be more convenient for most ordinary Sane users. In 
such a case, I tend to avoid a definitive design decision and to propose 
a configure (autoconf or run time configuration) option...

Abel