[sane-devel] ICC support for SANE

[Kai-Uwe Behrmann]

Am 28.05.09, 12:13 +0200 schrieb Julien BLACHE:
> Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>
> Hi,
>
>>> I'm pretty sure the frontend knows all there is to know about the
>>> scanner and its settings to retrieve the corresponding ICC profile.
>>
>> We possibly where holding our breath for something appearing like
>> arbitrary per backend settings ;-) It helps to know that backend
>> settings are well known and their relevance to colour can be
>> understood on the application level.
>
> There is no standard for scanner settings. Each model has different
> settings available, with the most common settings somewhat
> standardised and dubbed "well-known options" in SANE. That's all
> you've got to work with.

Ah, so arbitrary settings are possible. This will make some instance 
necessary to decide, which setting is colour related and which not in 
order to automatically honour only related settings for ICC profile 
selection. E.g. a profile for each scan area makes less sense. As well 
the selection of colour settings for inclusion into a profile by users is 
error proune.

> All settings should be available to the frontend. If there is
> something set/computed behind the scene by the backend that is not
> reflected in the options or scan parameters available to the frontend,
> I'd tend to consider that a bug. Such a parameter should probably be
> exposed to the frontend in the form of a read-only (non settable)
> option.

Good.

>>> Just as in your DigiKam example, where gphoto2 is not involved
>>> whatsoever with the ICC stuff.
>>
>> Well, gphoto2 appears as a local transportation layer without any
>> colour influence. We just learned that. Sane influences the colour and
>> transports remotely. So, there are more variables to consider.
>
> I don't think we have backends messing around with colours directly,

Lots of settings hold gamma, saturation and so on in their names. 
So I assume eigther the device or the driver does manipulations.

> except:
> - the v4l backend which does image conversion through libv4l, and
>   conversion means losses in any case. Nobody cares about v4l,
>   though.
> - backends for machines that send the image as a JPEG. I think we
>   have one or two cases of that, and the JPEG is decompressed to
>   RGB. Someone will correct me if I'm wrong here.
>
> And more importantly, but I'm not sure we have a case of that:
> - machines that send data with samples > 8 bits

> So in the end we should be pretty much transparent, sending out
> parameters and getting back image data. There's little to no image
> processing done in the backends, except line distance correction.

Ideally the profile selection should be dependent on any colour 
processing, be the processing in hardware or software. Burdening the 
guesswork of selecting the right profile to users is too complicated 
und non relyable.

> I don't know all the backends and what they do, so hopefully backend
> maintainers will comment about their backend if needed :)
>
>> Yiannis, suggests to handle transportation of ICC profiles over the
>> network at a later stage. This approach will be less sprinkling than
>> to work on each backend individualy.
>
> I don't think it brings anything. If you are scanning via the network
> and you care about ICC profiles, I'd say your Oyranos
> repository/server is available on the same network anyway. AKA you're
> not scanning on an unknown machine at an unknown location anyway.

A user obtains not necessarily a login on a machine, where (s)he scanns 
or prints. A second transport path is overhead to administrators.
Duplicating and maintaining lots of resources on each machine is not
fortune.

> But if you want to do that, it'll have to be out-of-band anyway. Using

Why not inside the normal Sane network traffic? All what is needed is to 
forward a request to the remote location to obtain some data.

> a read-only option is going to be a gigantic waste of bandwidth. Look

Well I dont know why something has to be a read-only option. A one 
time request would be all which is needed. Ok when colour options change 
then more.

> at how many times the options get reloaded, and you'll understand why.
>
>
> I've recently talked ICC profiles with people in the imaging/printing
> business, and I've got told (not an accurate quote) "nobody cares
> about ICC profiles; it doesn't work out, it's near impossible to get
> right, it's a waste of time, it doesn't really make a difference in
> the end anyway".

Beside many problems waiting to be solved, for people who want or have to 
care about colour there are not many alternatives to ICC profiles. Setting 
up one local machine for work with end to end colour management is 
certaily possible on linux. With some work it might even scale to some 
extent. Obviously the remains some work to make the scaling of ICC style 
colour management easy on linux/bsd.


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