[sane-devel] ICC support for SANE

[Kai-Uwe Behrmann]

replying to digest

Date: Mon, 11 May 2009 09:40:43 -0400
From: "m. allan noah" <kitno455 at gmail.com>

> On your blog posts, I think your list of how to get device
> identification is good except for a few points-

> 3. there is a version number exposed by the backend, but only as a
> param of sane_init()
>
> 4. You should not make assumptions about which driver options might
> change the output of the machine. Brightness/contrast/gamma are
> common, but others might include exposure, or black level, or even
> some sort of dynamic algo done by the scanner itself.
>
> 5. you might also want to adjust your work-flow drawing to show the
> SANE backend between the scanner and the SANE API.

How can we see what the backend does? I mean it is quite essential 
regarding colour apeparance to know, with which settings a scanner runs, 
e.g. gamma, gain ...  Is this exposed in the Sane API?

As initial interesst for Sane related colour management is very old, I got 
some first steps from here, some the following notions might be already 
know.

Anyway, let me elaborate:
when one calibrates and profiles a scanner, hopefully good 
settings are used and the colour related part should be extracted 
and remembered somewhere. Ideally these setting are stored later in the 
final ICC device profile. A hardware driver knows possibly best which 
settings are colour related and which not. Therefore I plan to add a 
backend type to Oyranos, which links to a device driver, e.g. the Sane 
API, and serialises the colour related device settings ideally to a list 
of key/value text pairs. The Oyranos device backend of Yiannis will 
then recieve a Sane context from the frontend application and extract all 
colour related informations. The resulting information from the 
Sane scanner can then be stored in the Oyranos device profile DB and 
embedded into a ICC profile on request. [1]
What this approach would be in need of, is some means to obtain colour 
relevance from a backend. Can all colour relevant settings be marked and 
transported to the front end? Would this be an extension or already 
available in Sane?
The calibration part is done by a application, like 
for monitors and often or printers. This can be automatic or manual. 
After this phase the device is ready for measuring. The settings, used 
during the calibration, must be stored or at least not altered. It is 
always a good idea to have control over that settings, as a change of them 
will change any later output and invalidate the ICC profile. The 
calibration can be imagined like a reference for the ICC profile. [2]

The test scan, typical of a colour patches chart, will then show 
the result of that colours scanned under these calibration.
The obtained picture can then be feed to a profiling application, like 
ArgyllCMS or Lprof in the open source world. It will extract the resulting 
colours as device colours and create a ICC profile, which is able to 
correct these colours to a reference colour space.

Applications using following combination of:
* a defined or, regarding colour, similiar behaving device
* a defined driver (backend?) settings and
* a related ICC profile
can then reach much more agreement about colours for the same scanned 
picture with different devices. Ideally the tint of the device will 
disappear after that process. The application part is already implemented 
in XSane. [3]

Now related to Oyranos, the idea is to move that
   device, driver, ICC profile 
combination out of a single application to a shared library, to offer 
every application using colour devices the same comfort of obtaining ICC 
colour management support from the Oyranos library. This includes a GUI to 
set profiles to each device and other options. The GUI part is called 
kolor-manager, a KDE system settings panel, which is currently part of the 
KDE playground [4].

> There has been some discussion of making a modified version of the
> SANE API, perhaps if you can outline the benefits of ICC support, you
> might get some buy-in to adjust it to your needs...


Date: Mon, 11 May 2009 16:22:53 +0200
From: Julien BLACHE <jb at jblache.org>

> To put it in a nutshell: uniquely identifying a scanner, don't count
> on it. If it was doable, we would have done so loooooong ago already.

What a pitty.

> Fact is, USB scanners reporting a serial number at the USB level are
> the exception. And as Allan wrote already, even otherwise, not a lot
> of machines expose a serial number. Manufacturers just don't care,
> except on high-end machines.

Then these machines will probably see less troubles during colour 
critical work.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management
www.behrmann.name + www.oyranos.org

[1] http://www.oyranos.org/wiki/index.php?title=Device_Settings#Driver
[2] http://www.oyranos.org/wiki/index.php?title=Device_Settings#Profiling
[3] http://www.oyranos.org/wiki/index.php?title=Device_Settings#Scenario
[4] http://www.oyranos.org/wiki/index.php?title=Kolor-manager