[Openicc] Helping with colord

[Chris Murphy]

On Mar 9, 2011, at 2:34 AM, Richard Hughes wrote:
> 
> I'm a great believer of "code talks". Words are cheap.

There's got to be an intermediate position that's workable. I've seen plenty of written code that talks like a drunk when it comes to color.

>  For example:
> 
> To map a device to a profile, we need to have a unique ID for the
> device and a unique ID for the profile:
> 
> * The profile ICC MD5 can be used as a unique ID
>  * There may be duplicate profiles installed
>  * Profiles from CUPS don't have to have an ICC profile
> 
> * The xrandr name can be used as a device ID
>  * This doesn't work with xinerama
> 
> * The EDID data can be used as a device ID
>  * Some monitors do not report sane EDID data
>  * Some monitors report sane EDID data, but the serial numbers are all the same
>  * Some monitors change the EDID data when the hardware gamut is changed

EDID primaries should change if gamut changes, otherwise it's a problem to know how the device is behaving. For the devices that report bogus EDID, the code that's building the profile needs to do some checking for rational primaries with some tolerance. A yellow x,y value for green isn't sensible. Negative values aren't sensible. Etc.





> 
> * The SANE id can be used for the scanner ID
>  * libsane can't honestly be securely used in system daemons without SELinux
>  * The sane ID can represent non-local devices
> 
> * The vendor ID and product ID can be used to identify cameras
>  * Does not take into account having more than one device of the same
> type plugged in

When plugged in, don't all cameras behave like mass storage devices? The camera isn't a device of concern I don't think. Its data, however, quite certainly is. And a major missing link persistently with camera JPEG is ignorance of EXIF color space. It's not just an ICC world. For Raw, there's an implied color space but this is the area of Raw processors.

In any event, those files should contain reliable serial numbers from the camera that produced them. At least this is the case with DSLRs, maybe there's an issue on the consumer end, I'm not sure but I'd be slightly surprised.


> 
> * Can devices have more than one profile
>  * How do we signify the default?
>  * How do we choose appropriate profiles for each environment, e.g.
> using a qualifier

A conversation entirely of it's own for sure.

> 
> * Can we have virtual devices
>  * Are they stores over reboots?
>  * Can they be used for printing?

It's a good question. I'd say the virtual device needs to be predicated on some parent - and inherent certain traits like color space. That parent could be a device attached to my computer, or it could be chosen from a list of profiles. RGB display virtual devices probably initially should default to display RGB (inherit currently attached display profile) with options for other spaces.


> 
> * Do we allow the user to remove profiles from system devices
>  * No everybody agrees on PolicyKit
>  * What about multihead?
>  * What about USB redirected devices on systems like LTSP?

/DeviceRGB lives on. Until there's a way to get a display profile from a remote display...or tag the data going to the remote display and expect it to be converted at the other end.  Some contingencies for fall back probably are in order in some cases.


> 
> So actually, whether we store a simple mapping from device id to
> profile id is really rather simple, and arguing about json, xml or
> sqlite is really a *huge* waste of time unless we can get the
> specifics about how to define a device ID.

This cannot be the first time this has been thought of. There must be other specs or projects elsewhere that are dealing with this same issues and we should simply adopt what's common.

Also, for printers, we have a "device condition ID" as really its not a device that we profile. It's a device + a particular driver + that driver's settings + the media actually loaded in the printer + the inkset in that printer (which conceivably can be changed out). So a physical device in a sense has derivative virtual devices with real physical consequences in reality. In some cases profile overlap is possible, in other cases not.


> 
> And then we come to how to define a device. Is a calibration device a
> device? Is a remote scanner configured using SANE a device? Is a USB
> webcam a device? Is that same webcam also detected by SANE also the
> same device?

What does it mean to consider a colorimeter a device or not a device? I don't understand the context or the consequence of either a yes or no to "is it a device?"

Remote scanners I think need source space defined for their modes. Sure. Just as if they were local. I don't know how this functions in the real world: dial phone/send email, ask someone to put a particular picture on the scanner, and then I initiate a scan? Another problem for another forum I suppose.

A web cam is an interesting issue. Video is interesting. Complex. Separate conversation entirely on how to handle this simply in the short term, and then maybe move to cleaning some things up for the medium and long term. But an important area.


> So until we spend the months arguing what a device is, and the months
> arguing what a device ID should be, and then how to map it to a
> profile, then we've spent over a year getting no actual features out
> of the door we didn't already have. Users really don't care how it
> works.

This is my argument. Users don't care how it gets coded (how it works) but they only care that it works (sensibly, intuitively, etc.)

But still there needs to be a mechanism for competing proposals to be formally presented, debated and then something decided upon. We do not have this right now. There's energy available that's not being channeled efficiently.


Chris Murphy