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
