Hello, Thanks everyone for participating on the discussing, your input is very valuable. Unfortunately I was not able to follow up, so I'll make some points here.
In general color management is really important to be implemented and everyone needs it - more or less. The working industry standard right now is based on ICC profiles. If things do not work as expected in Linux, then this should be considered a bug :) For the Oyranos SANE backend it is essential to be able to tell which options have an effect on the color output and which not, so that a color profile can be reliably selected. What if some backend also makes a color transformation on software? This will not affect the profile selection, as long as this same transformation always happens with the same kind of options. Also, notifying that this happens would be a nice thing to have as of a read-only option. There should also be a change in the backend version number whenever the transform changes its color ouput. In general, consecutive color transformations should be best kept to a minimum. So, the first proposal for inclusion on the next version of the api would be a flag to mark an option as color related. The next part is getting the profile over the network. It would be ideal to transfer the profile through the normal sane transport mechanism, since it's already there. So is it possible to add an extra call to a function like get_icc_profile() ? Then saned would contact the local Oyranos database and send the profile to the client machine. Julien noted that the network api is a 1:1 map of the sane api, but I'm not sure why an addition like this is can be a problem. Any help appreciated, I started looking at the saned code, but this may take a while... Thank's in advance, Yiannis Yiannis Belias <jonnyb at hol.gr> ` Homepage [http://users.hol.gr/~jonnyb/video] ' . GNU+LINUX: ' ' IN A WORLD WITHOUT FENCES WHO NEEDS GATES? . *
