[sane-devel] API addition request

[Kai-Uwe Behrmann]

Am 21.06.09, 12:33 +0200 schrieb Alessandro Zummo:

> On Sun, 21 Jun 2009 09:50:33 +0200 (CEST)
> Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>
>>> even when it is off. If we make it part of a sane 2 standard, then we can
>>> require that backends set the bit properly.
>>
>> Agreed for sane 2 to official support the SANE_CAP_COLOR flag.
>
> Should the default behaviour of a backend not to alter the color
> output as much as possible?

This is a difficult question for the transistion period. Currently Xsane 
and scanimage can apply colour profiles on the frontend side. They do not 
know if a image is prematched or in some more native device space? I could 
imagine one backend option like:
"colour-convert"
    - "system, not in backend [0]"             (default)
    - "backend to sRGB, not in system [1]"

The first value would allow the frontend to take over profile selection, 
while the later works as last rescue for colour management unaware 
frontends. This option should remain non mandatory and almost not used 
or implemented. Colour management in backends is regarding user 
interaction a complex thing. It will confuse users easily and increase 
support requirements. If something does not work, it can not even called a 
bug, it will be called quickly bad design.

If the system cares for this stuff or there is a relyable path to 
communicate a ICC device profile, its all easier - even though still not 
simple. Of course we need to define a path for vendors to deliver their 
device profile along with a driver and correctly install them. This is 
work to do.

> I recently noticed, while working on the epson2 color
> correction profiles, that the default option told the scanner to
> "adapt for CRT monitors".

... for preview pourpose?

> I'm planning to introduce profiles shortly and to revert this default
> to "no correction".

Yes, fine.

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