[sane-devel] ICC support for SANE

[Julien BLACHE]

Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

Hi,

> 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

Yes. Someone will have to determine this for each (model, backend)
combination (and maybe more, depending on options being active only
for some scan mode or source or ...). Probably the backend version or
SANE release (or both) will be needed too.

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

Device. I don't think we have backends that go out of their way and do
post-processing on the image data.

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

My understanding is that there is a central repository of ICC
profiles; did I get that wrong?

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

The SANE network protocol mimics the SANE API. If something goes over
the network, it is part of the API on both sides. It has to fit in the
API. There is no way around that with the current code.

The diagrams with the Oyranos integration are somewhat wrong in this
respect; the SANE API is not something over the dll backend and the
actual backend like they imply. Each backend implements the API, no
less, no more.

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

I wrote read-only because I thought you were only interested in
retrieving the ICC profile this way.

> time request would be all which is needed. Ok when colour options
> change then more.

There is no one-time request as far as options are concerned. Options
are reloaded as soon as the backend adjusts an option value or state
as a side effect of an option being modified by the user. A typical
frontend startup (XSane) can cause dozens of reloads while it sets the
options to what was last used.

You don't want to throw in several kB (is that a good estimate? looks
like it can be even more than that, up to several MB?) of ICC profile
data that will get transmitted again with each reload (and will also
generate a request to the repository, AIUI).

Maybe the best thing would be to add the ICC profile to the scan
parameters; but even then, the scan parameters are usually queried
several times during normal operations too.

JB.

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