[Openicc] Permissions and user level access to open ICC UI?
Scott Geffert
scottgeffert at gmail.com
Sun Feb 13 10:00:43 PST 2011
I am wondering if the issues related to low end and high end users is better addressed via user permissions. At may sites ICC is already difficult to administer in enterprise sites with remote administration and typical security approaches.
I do not think you can categorize users by price point, nor can you assume that a low end user does not have high color expectations. Case in point: there are so may office color lasers that could easily be better calibrated. As users do more and more online shopping for consumer goods as opposed to printed catalogs, the ability to print accurate color on low-end printers is going to become more important. There are many excellent color laser printers for around 300-400 dollars.
While a default install may enable the "vanilla" sRGB type default, an admin menu may reveal, the custom ICC options that are required for printing charts, changing workflow, selecting custom profiles etc. This waif the user has the desire they can do this themselves, a consultant or IT support person could perform the work and then lock done the settings with a password. If you think about it this is how most home routers come out of the box. There are hundreds of configuration options for advanced security etc, but most will work as DHCP right out of the box. The router manuals all include a URL and login for the administration pages. In fact, most network printers also use this approach.
If the UI of printer color management was to be built in this same manner it seems to me that the level of configuration could be as granular as needed while keeping the average user experience as simple as can be. The added benefit here is that large enterprise sites with IT support can better manage and support high end color. I have always wished that Adobe would adopt a similar strategy for the CS suite products because most color problems are caused by "configuration creep".
I think the idea of removing options and assuming people (users) are incapable or uninterested in configuring tools for optimized performance is flat out wrong. We forget that the end users are the ones funding Adobe, Apple, HP, Microsoft, consultants, retailers, etc. I feel that users DESERVE full and open access to the hardware they purchase.
Scott
On Feb 13, 2011, at 11:43 AM, openicc-request at lists.freedesktop.org wrote:
> Send openicc mailing list submissions to
> openicc at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freedesktop.org/mailman/listinfo/openicc
> or, via email, send a message with subject or body 'help' to
> openicc-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> openicc-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openicc digest..."
>
>
> Today's Topics:
>
> 1. Re: Camera Input Profiling etc. (Anders Brander)
> 2. Re: HP Elitebook 8540W notebook with Dreamcolor display
> (Emil Briggs)
> 3. Re: HP Elitebook 8540W notebook with Dreamcolor display
> (Kai-Uwe Behrmann)
> 4. Re: HP Elitebook 8540W notebook with Dreamcolor display
> (Emil Briggs)
> 5. Re: HP Elitebook 8540W notebook with Dreamcolor display
> (Emil Briggs)
> 6. Re: HP Elitebook 8540W notebook with Dreamcolor display
> (Emil Briggs)
> 7. Re: colord information (Chris Murphy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 13 Feb 2011 10:09:44 +0100
> From: Anders Brander <anders at brander.dk>
> Subject: Re: [Openicc] Camera Input Profiling etc.
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <1297588184.23240.21.camel at trackr>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> On Sun, 2011-02-13 at 07:45 +0100, Kai-Uwe Behrmann wrote:
>>>> Leonard, what are Adobe's plans regarding licensing of DNG SDK? To the
>>>> best of my knowledge the SDK doens't allow redistribution of its parts
>>>> in open source projects. I know of just two open source projects tha
>>>> deal with DCP. The first one, dcptool, does use bits of the SDK
>>>> anyway. Of the second one, Rawstudio, I don't really know.
>>>
>>> Rawstudio uses the default tone curve from the DNG SDK - but no code.
>>
>> It has its code just inside Rawstudio or has a project of its own for DCP?
>
> Everything is in the Rawstudio source tree. The transforms would be easy
> to move outside the tree. It has a few dependencies on librawstudio, but
> nothing that can't be replicated easily.
>
> I doubt it would be worth the trouble thou, implementing the transforms
> in the first place wasn't that hard. I would recommend implementing the
> transforms from scratch and then take a look at Rawstudio's
> SSE-renderers, they are really fast.
>
> For the interested:
> https://rawstudio.org/svn/rawstudio/trunk/plugins/dcp/
>
> /Anders
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 13 Feb 2011 07:55:49 -0500
> From: Emil Briggs <emil at briggspack.com>
> Subject: Re: [Openicc] HP Elitebook 8540W notebook with Dreamcolor
> display
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <201102130755.50033.emil at briggspack.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Sunday 13 February 2011 01:55:52 Kai-Uwe Behrmann wrote:
>> Am 12.02.11, 11:12 -0500 schrieb Emil Briggs:
>>> On Saturday 12 February 2011 10:20:34 Kai-Uwe Behrmann wrote:
>>>> Am 12.02.11, 09:00 -0500 schrieb Emil Briggs:
>>>>> to see what was there and it gave me a "No displays found" message.
>>>>>
>>>>> i2cdetect -l shows 10 separate /dev/i2c-* nvidia entries so the kernel
>>>>> i2c support is there. I ran hpdc_util again with strace and started
>>>>> looking through the code. The devices are opened successfully but
>>>>> writing to them fails. I'm not quite sure how to proceed next. I do
>>>>> have the Quadro graphics card with the proprietary driver. Just for
>>>>> kicks I tried using the opensource nvidia driver but this does not
>>>>> work -- looking in the Xorg.0.log it finds the I2C/ddc interfaces but
>>>>> is unable to read any EDID information from them.
>>>>
>>>> Did you see the forum post on the ookala-mcf page around EDID?
>>>> http://sourceforge.net/projects/ookala-mcf/forums/forum/898199/topic/339
>>>> 741 5
>>>
>>> I had not but it's not a permissions issue since I ran it as root after
>>> the it failed as a non privileged user.
>>
>> Did you try Xcm/libXcm[1] to see the i2c channels?
>> "xcmddc requests EDID from a monitor over the i2c bus."
>> libXcm installs a udev rule for activating the i2c bus.
>>
>
>
> No nodes found and strace shows the same thing I saw with hpdc_util.
>
>
> open("/dev/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> brk(0) = 0x192a000
> brk(0x1953000) = 0x1953000
> getdents64(3, /* 198 entries */, 32768) = 5784
> open("/dev/i2c-9", O_RDWR) = 4
> ioctl(4, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(4, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-8", O_RDWR) = 5
> ioctl(5, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(5, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-7", O_RDWR) = 6
> ioctl(6, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(6, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-6", O_RDWR) = 7
> ioctl(7, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(7, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-5", O_RDWR) = 8
> ioctl(8, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(8, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-4", O_RDWR) = 9
> ioctl(9, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(9, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-3", O_RDWR) = 10
> ioctl(10, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(10, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-2", O_RDWR) = 11
> ioctl(11, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(11, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-1", O_RDWR) = 12
> ioctl(12, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(12, "\0", 1) = -1 EIO (Input/output error)
> open("/dev/i2c-0", O_RDWR) = 13
> ioctl(13, 0x703, 0x50) = 0
> nanosleep({0, 50000000}, NULL) = 0
> write(13, "\0", 1) = -1 EIO (Input/output error)
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 13 Feb 2011 15:17:12 +0100 (MET)
> From: Kai-Uwe Behrmann <ku.b at gmx.de>
> Subject: Re: [Openicc] HP Elitebook 8540W notebook with Dreamcolor
> display
> To: OpenICC Liste <openicc at lists.freedesktop.org>
> Message-ID: <alpine.LNX.2.00.1102131514441.3721 at roma.rasena>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> Am 13.02.11, 07:55 -0500 schrieb Emil Briggs:
>> On Sunday 13 February 2011 01:55:52 Kai-Uwe Behrmann wrote:
>>> Am 12.02.11, 11:12 -0500 schrieb Emil Briggs:
>>>> On Saturday 12 February 2011 10:20:34 Kai-Uwe Behrmann wrote:
>>>>> Am 12.02.11, 09:00 -0500 schrieb Emil Briggs:
>>>>>> to see what was there and it gave me a "No displays found" message.
>>>>>>
>>>>>> i2cdetect -l shows 10 separate /dev/i2c-* nvidia entries so the kernel
>>>>>> i2c support is there. I ran hpdc_util again with strace and started
>>>>>> looking through the code. The devices are opened successfully but
>>>>>> writing to them fails. I'm not quite sure how to proceed next. I do
>>>>>> have the Quadro graphics card with the proprietary driver. Just for
>>>>>> kicks I tried using the opensource nvidia driver but this does not
>>>>>> work -- looking in the Xorg.0.log it finds the I2C/ddc interfaces but
>>>>>> is unable to read any EDID information from them.
>>>>>
>>>>> Did you see the forum post on the ookala-mcf page around EDID?
>>>>> http://sourceforge.net/projects/ookala-mcf/forums/forum/898199/topic/339
>>>>> 741 5
>>>>
>>>> I had not but it's not a permissions issue since I ran it as root after
>>>> the it failed as a non privileged user.
>>>
>>> Did you try Xcm/libXcm[1] to see the i2c channels?
>>> "xcmddc requests EDID from a monitor over the i2c bus."
>>> libXcm installs a udev rule for activating the i2c bus.
>>>
>>
>>
>> No nodes found and strace shows the same thing I saw with hpdc_util.
>>
>>
>> open("/dev/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>> fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
>> brk(0) = 0x192a000
>> brk(0x1953000) = 0x1953000
>> getdents64(3, /* 198 entries */, 32768) = 5784
>> open("/dev/i2c-9", O_RDWR) = 4
>> ioctl(4, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(4, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-8", O_RDWR) = 5
>> ioctl(5, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(5, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-7", O_RDWR) = 6
>> ioctl(6, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(6, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-6", O_RDWR) = 7
>> ioctl(7, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(7, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-5", O_RDWR) = 8
>> ioctl(8, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(8, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-4", O_RDWR) = 9
>> ioctl(9, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(9, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-3", O_RDWR) = 10
>> ioctl(10, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(10, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-2", O_RDWR) = 11
>> ioctl(11, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(11, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-1", O_RDWR) = 12
>> ioctl(12, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(12, "\0", 1) = -1 EIO (Input/output error)
>> open("/dev/i2c-0", O_RDWR) = 13
>> ioctl(13, 0x703, 0x50) = 0
>> nanosleep({0, 50000000}, NULL) = 0
>> write(13, "\0", 1) = -1 EIO (Input/output error)
>
>
> Then, its best to contact HP for support.
>
> kind regards
> Kai-Uwe Behrmann
> --
> developing for colour management
> www.behrmann.name + www.oyranos.org
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 13 Feb 2011 09:13:17 -0500
> From: Emil Briggs <emil at briggspack.com>
> Subject: Re: [Openicc] HP Elitebook 8540W notebook with Dreamcolor
> display
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <201102130913.17925.emil at briggspack.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Sunday 13 February 2011 07:55:49 Emil Briggs wrote:
>> On Sunday 13 February 2011 01:55:52 Kai-Uwe Behrmann wrote:
>>> Am 12.02.11, 11:12 -0500 schrieb Emil Briggs:
>>>> On Saturday 12 February 2011 10:20:34 Kai-Uwe Behrmann wrote:
>>>>> Am 12.02.11, 09:00 -0500 schrieb Emil Briggs:
>>>>>> to see what was there and it gave me a "No displays found" message.
>>>>>>
>>>>>> i2cdetect -l shows 10 separate /dev/i2c-* nvidia entries so the
>>>>>> kernel i2c support is there. I ran hpdc_util again with strace and
>>>>>> started looking through the code. The devices are opened
>>>>>> successfully but writing to them fails. I'm not quite sure how to
>>>>>> proceed next. I do have the Quadro graphics card with the
>>>>>> proprietary driver. Just for kicks I tried using the opensource
>>>>>> nvidia driver but this does not work -- looking in the Xorg.0.log it
>>>>>> finds the I2C/ddc interfaces but is unable to read any EDID
>>>>>> information from them.
>>>>>
>>>>> Did you see the forum post on the ookala-mcf page around EDID?
>>>>> http://sourceforge.net/projects/ookala-mcf/forums/forum/898199/topic/3
>>>>> 39 741 5
>>>>
>>>> I had not but it's not a permissions issue since I ran it as root after
>>>> the it failed as a non privileged user.
>>>
>>> Did you try Xcm/libXcm[1] to see the i2c channels?
>>> "xcmddc requests EDID from a monitor over the i2c bus."
>>> libXcm installs a udev rule for activating the i2c bus.
>>
>> No nodes found and strace shows the same thing I saw with hpdc_util.
>>
>>
>
> Made some progress. I unloaded the Nvidia proprietary driver and loaded the
> nouveau kernel module with the framebuffer X driver. The i2c bus appears
> functional now and hpdc_util read the EDID information from the panel. It does
> not recognize it as a Dreamcolor though which is not surprising since it's
> looking for the standalone monitor. If I feel brave I might be able to work
> around this by adding in the ID of the laptop panel. I'm not sure if thats a
> good idea though. Does anyone know if it's possible to damage the hardware
> with an incorrect setting?
>
> For whatever reason the i2c bus is not usable when the Nvidia proprietary
> module is in use. I don't know if that is specific to this card/display
> combination or is more general. Since most people using the proprietary driver
> would be using nvidia-settings to control the displays it might not have been
> noticed.
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 13 Feb 2011 09:42:41 -0500
> From: Emil Briggs <emil at briggspack.com>
> Subject: Re: [Openicc] HP Elitebook 8540W notebook with Dreamcolor
> display
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <201102130942.41224.emil at briggspack.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
>>
>> Made some progress. I unloaded the Nvidia proprietary driver and loaded the
>> nouveau kernel module with the framebuffer X driver. The i2c bus appears
>> functional now and hpdc_util read the EDID information from the panel. It
>> does not recognize it as a Dreamcolor though which is not surprising since
>> it's looking for the standalone monitor. If I feel brave I might be able
>> to work around this by adding in the ID of the laptop panel. I'm not sure
>> if thats a good idea though. Does anyone know if it's possible to damage
>> the hardware with an incorrect setting?
>>
>> For whatever reason the i2c bus is not usable when the Nvidia proprietary
>> module is in use. I don't know if that is specific to this card/display
>> combination or is more general. Since most people using the proprietary
>> driver would be using nvidia-settings to control the displays it might not
>> have been noticed.
>> _______________________________________________
>
> I felt brave so I added support for the panel ID and tried changing the
> presets with hpdc_util. It works. Not a great solution since the nouveau
> driver is not all that stable yet particularly for 3D stuff but it does work.
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 13 Feb 2011 09:44:04 -0500
> From: Emil Briggs <emil at briggspack.com>
> Subject: Re: [Openicc] HP Elitebook 8540W notebook with Dreamcolor
> display
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <201102130944.04761.emil at briggspack.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Sunday 13 February 2011 09:17:12 Kai-Uwe Behrmann wrote:
>> Am 13.02.11, 07:55 -0500 schrieb Emil Briggs:
>>> On Sunday 13 February 2011 01:55:52 Kai-Uwe Behrmann wrote:
>>>> Am 12.02.11, 11:12 -0500 schrieb Emil Briggs:
>>>>> On Saturday 12 February 2011 10:20:34 Kai-Uwe Behrmann wrote:
>>>>>> Am 12.02.11, 09:00 -0500 schrieb Emil Briggs:
>>>>>>> to see what was there and it gave me a "No displays found" message.
>>>>>>>
>>>>>>> i2cdetect -l shows 10 separate /dev/i2c-* nvidia entries so the
>>>>>>> kernel i2c support is there. I ran hpdc_util again with strace and
>>>>>>> started looking through the code. The devices are opened
>>>>>>> successfully but writing to them fails. I'm not quite sure how to
>>>>>>> proceed next. I do have the Quadro graphics card with the
>>>>>>> proprietary driver. Just for kicks I tried using the opensource
>>>>>>> nvidia driver but this does not work -- looking in the Xorg.0.log it
>>>>>>> finds the I2C/ddc interfaces but is unable to read any EDID
>>>>>>> information from them.
>>>>>>
>>>>>> Did you see the forum post on the ookala-mcf page around EDID?
>>>>>> http://sourceforge.net/projects/ookala-mcf/forums/forum/898199/topic/3
>>>>>> 39 741 5
>>>>>
>>>>> I had not but it's not a permissions issue since I ran it as root after
>>>>> the it failed as a non privileged user.
>>>>
>>>> Did you try Xcm/libXcm[1] to see the i2c channels?
>>>> "xcmddc requests EDID from a monitor over the i2c bus."
>>>> libXcm installs a udev rule for activating the i2c bus.
>>>
>>> No nodes found and strace shows the same thing I saw with hpdc_util.
>>>
>>>
>>> open("/dev/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>>> fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
>>> brk(0) = 0x192a000
>>> brk(0x1953000) = 0x1953000
>>> getdents64(3, /* 198 entries */, 32768) = 5784
>>> open("/dev/i2c-9", O_RDWR) = 4
>>> ioctl(4, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(4, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-8", O_RDWR) = 5
>>> ioctl(5, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(5, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-7", O_RDWR) = 6
>>> ioctl(6, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(6, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-6", O_RDWR) = 7
>>> ioctl(7, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(7, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-5", O_RDWR) = 8
>>> ioctl(8, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(8, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-4", O_RDWR) = 9
>>> ioctl(9, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(9, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-3", O_RDWR) = 10
>>> ioctl(10, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(10, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-2", O_RDWR) = 11
>>> ioctl(11, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(11, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-1", O_RDWR) = 12
>>> ioctl(12, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(12, "\0", 1) = -1 EIO (Input/output error)
>>> open("/dev/i2c-0", O_RDWR) = 13
>>> ioctl(13, 0x703, 0x50) = 0
>>> nanosleep({0, 50000000}, NULL) = 0
>>> write(13, "\0", 1) = -1 EIO (Input/output error)
>>
>> Then, its best to contact HP for support.
>>
>
> See my other message -- I think it's a problem with the i2c implementation in
> the Nvidia binary driver.
>
>> kind regards
>> Kai-Uwe Behrmann
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 13 Feb 2011 09:43:28 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] colord information
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <1D413566-D9F4-49C6-9370-9CB1CCA1927C at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Feb 13, 2011, at 12:13 AM, Kai-Uwe Behrmann wrote:
>> Am 13.02.11, 04:24 +0100 schrieb edmund ronald:
>>
>>> Hehe, paradoxically the canned-profile color-managed settings are
>>> actually the ones which would be locked down most strongly -or else
>>> the profile is useless.
>>
>> It reads like polarising between naive/inexperienced users and experienced/expert users. Exactly that is strongly criticised on other platforms, but seems to meet deaf ears right now.
>
> Also we should consider that even experienced/expert users get worn down with options also.
>
> While it can be a really tedious rabbit hole to have to go looking at the stuff in SampleICC or sips (command line "scriptable image processing system" on OS X) to get things done, the functionality is available and can be scripted by those who want or need something out of the ordinary. But in the GUI, I have a lot of reluctance subjecting myself, let alone other users, to excessive exposure. Especially daily.
>
> So there may be other locations for some functionality: command line, scripting, a separate application not part of a built-in GUI that every user would see, advanced panels that are hidden by default, etc. Command line stuff, like sips, is actually really basic. Not complex at all. Complex comes from building basic components together. A GUI presentation can actually be highly complex not only to build, but to decipher. GUI presentation is not automatically intuitive at all. They can actually be quite harmful.
>
> Chris
>
> ------------------------------
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
> End of openicc Digest, Vol 59, Issue 60
> ***************************************
>
More information about the openicc
mailing list