[sane-devel] ICC support for SANE

[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.

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.

>> 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,
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.

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.

But if you want to do that, it'll have to be out-of-band anyway. Using
a read-only option is going to be a gigantic waste of bandwidth. Look
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".

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org>                                  GPG KeyID 0xF5D65169