From hughsient at gmail.com Thu Jul 1 08:37:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 09:37:32 +0100 Subject: GNOME Color Manager 2.31.4 Message-ID: gnome-color-manager is a session program that makes it easy to manage, install and generate color profiles in the GNOME desktop. Version 2.31.4 ~~~~~~~~~~~~~~ Released: 2010-07-01 * Translations - Updated Galician translations (Fran Di?guez) - Updated Spanish translation (Jorge Gonz?lez) - Updated Estonian translation (Mattias P?ldaru) - Updated Hebrew translation (Yaron Shahrabani) - Updated Simplified Chinese translation (?? Gan Lu) * New Features: - Port from lcms to lcms2 (Richard Hughes) - Split gcm-prefs into a control center module and a profile viewer (Richard Hughes) - Add gcm_image_set_abstract_profile() so we can set LAB abstract profiles (Richard Hughes) - Add GcmProfileSearchFlags so we can control what kind of profiles are loaded (Richard Hughes) - Allow passing profile and device types to GetProfilesForType() (Richard Hughes) * Bugfix: - Do not try to convert if the input and output profiles are not RGB (Richard Hughes) - Refuse to import a local profile if it already exists system-wide (Richard Hughes) - Make GcmImage take a GcmProfile, not a base64 string (Richard Hughes) - Depend on gnome-control-center 2.31.4 for GTK 3.0 fixes (Richard Hughes) - Ensure we load the profile store in the DBus service (Richard Hughes) Richard. From gysvanzyl at gmail.com Thu Jul 1 15:31:58 2010 From: gysvanzyl at gmail.com (Gys van Zyl) Date: Thu, 1 Jul 2010 18:31:58 +0300 Subject: Color management in ubuntu Message-ID: Hi all, I have a couple of questions that may be a bit silly due to my beginner level knowledge of color management. I'm an amateur/hobby photographer and I've been using ubuntu for a while (currently using 10.04). For a while now I've realized the importance of having a color managed workflow, but have put off getting the hardware as I thought getting everything installed, set up and configured would be tough in linux. I recently purchased a Pantone Huey monitor calibration device and you could imagine my pleasant surprise when I found how extremely easy everything was to use with gnome color manager. In no time, with almost zero effort I had everything up and running. Kudos to the developer(s) - this is excellent software! So, to test how color management works in a browser, I found this web site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. Using google chrome (a non color managed browser) this page is a mess of incorrectly rendered photo's - I expected this. Using Firefox, things are a lot better - imbedded color profiles are now honored and the photos display fine. However, about half-way down the page at the heading "sRGB / Standard RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged sRGB rollover." In my Firefox window, the change is not minor, and I'm trying to figure out why this is. In my workflow all exif data is stripped from my photo's before I upload to the web. I thought that this wouldn't matter, as long as my final image was created in an sRGB colorspace. However, I have now found that my photo's look subtly but definitely different in the software I use (gimp, digikam) and my browsers. My limited understanding of color management led me to believe that un-tagged sRGB images should look the same in a browser on a color-managed system. However, on my system they don't and its causing a problem for me - my photo's don't display the way I intended. How can I resolve this? Is my understanding wrong, should I educate myself a bit more? Did I do something wrong when I calibrated my monitor? Gys -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmjdebruijn at pcode.nl Thu Jul 1 15:58:07 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 17:58:07 +0200 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 5:31 PM, Gys van Zyl wrote: > Hi all, > I have a couple of questions that may be a bit silly due to my beginner > level knowledge of color management. > I'm an?amateur/hobby photographer and?I've been using ubuntu for a while > (currently using 10.04). ?For a while now I've realized the importance of > having a color managed workflow, but have put off getting the hardware as I > thought getting everything installed, set up and configured would be tough > in linux. ?I recently purchased a Pantone Huey monitor calibration device > and you could imagine my pleasant surprise when I found how extremely easy > everything was to use with gnome color manager. ?In no time, with almost > zero effort I had everything up and running. ?Kudos?to the developer(s) - > this is excellent software! GCM + Argyll is a powerful combination indeed :) > So, to test how color management works in a browser, I found this web > site:?http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > ?Using google chrome (a non color managed browser) this page is a mess of > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a > lot better - imbedded color profiles are now honored and the photos display > fine. However, about half-way down the page at the heading "sRGB / Standard > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm > trying to figure out why this is. > In my workflow all exif data is stripped from my photo's before I upload to > the web. ?I thought that this wouldn't matter, as long as my final image was > created in an sRGB colorspace. ?However, I have now found that my photo's > look subtly but definitely different in the software I use (gimp, digikam) > and my browsers. > My limited understanding of color management led me to believe that > un-tagged sRGB images should look the same in a browser on a color-managed > system. ?However, on my system they don't and its causing a problem for me - > my photo's don't display the way I intended. ?How can I resolve this? ?Is my > understanding wrong, should I educate myself a bit more? ?Did I do something > wrong when I calibrated my monitor? The problem is that being color managed, and being properly configured is not always the same... All color managed applications checked for an embedded profile when loading images and will for example convert an Adobe RGB image to sRGB on request. If an image is untagged sRGB will be assumed. However, if you do not properly configure the application to use your display profile it will be displayed as plain srgb without your display profile applied, hence wrong colors (since only the videolut will have effect). I think GIMP doesn't use the system display profile by default. Firefox also requires the display profile to be configured through "about:config" search for "display_profile". Same goes for lots of other applications. So you will still need to check each an every applications configuration. Since they might use poor defaults. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 16:03:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:03:47 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On 1 July 2010 16:58, Pascal de Bruijn wrote: > I think GIMP doesn't use the system display profile by default. > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. Could you start to make to a list of applications and the fixes here please: http://live.gnome.org/GnomeColorManager/FAQ -- I think a list would be really useful for users. Then we can file bugs against the programs to use the GCM DBus interface or the ICCPROFILESINX specification and get things just working by default. As for everything else, I normally tag my "web-safe" with sRGB (it's a tiny increase in size, and probably a good idea) and ensure the display profile has been set correctly. Richard. From marek.matulka at gmail.com Thu Jul 1 16:18:57 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:18:57 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <1278001137.2552.11.camel@localhost> Hello, This is my first post on the group, but I've been following a group for some time. Well done guys for a rocking bit of software giving us a great colour management tool! On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: > > So, to test how color management works in a browser, I found this web > > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > > Using google chrome (a non color managed browser) this page is a mess of > > incorrectly rendered photo's - I expected this. Using Firefox, things are a > > lot better - imbedded color profiles are now honored and the photos display > > fine. However, about half-way down the page at the heading "sRGB / Standard > > RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged > > rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 > > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > > sRGB rollover." In my Firefox window, the change is not minor, and I'm > > trying to figure out why this is. > > In my workflow all exif data is stripped from my photo's before I upload to > > the web. I thought that this wouldn't matter, as long as my final image was > > created in an sRGB colorspace. However, I have now found that my photo's > > look subtly but definitely different in the software I use (gimp, digikam) > > and my browsers. > > My limited understanding of color management led me to believe that > > un-tagged sRGB images should look the same in a browser on a color-managed > > system. However, on my system they don't and its causing a problem for me - > > my photo's don't display the way I intended. How can I resolve this? Is my > > understanding wrong, should I educate myself a bit more? Did I do something > > wrong when I calibrated my monitor? > > The problem is that being color managed, and being properly configured > is not always the same... > > All color managed applications checked for an embedded profile when > loading images and will for example convert an Adobe RGB image to sRGB > on request. If an image is untagged sRGB will be assumed. > > However, if you do not properly configure the application to use your > display profile it will be displayed as plain srgb without your > display profile applied, hence wrong colors (since only the videolut > will have effect). > > I think GIMP doesn't use the system display profile by default. > > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. I had similar issue - when I created three images: 1. tagged with Adobe RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly displayed in GIMP, but not in any desktop viewer. I think the problem lies in assumption, that for untagged images viewer should not apply monitor profile, while it should assume sRGB and convert it accordingly. It seems GIMP is working that way hence all three images are correctly displayed. I have filled a bug report against Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=606996 this bug report includes example screenshots of gimp and eog. Although, I am not sure if my assumptions are right, so please correct me, if I am wrong. Greetings, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 16:27:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:27:39 +0100 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On 1 July 2010 17:18, Marek Matulka wrote: > Although, I am not sure if my assumptions are right, so please correct > me, if I am wrong. I think this functionality needs to live in the toolkit (e.g. GTK) and done automatically, as the harder applications have to work to do the right thing, the fewer that will actually do it. Richard. From marek.matulka at gmail.com Thu Jul 1 16:42:44 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:42:44 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: <1278002564.2552.12.camel@localhost> On Thu, 2010-07-01 at 17:27 +0100, Richard Hughes wrote: > On 1 July 2010 17:18, Marek Matulka wrote: > > Although, I am not sure if my assumptions are right, so please correct > > me, if I am wrong. > > I think this functionality needs to live in the toolkit (e.g. GTK) and > done automatically, as the harder applications have to work to do the > right thing, the fewer that will actually do it. That would be awesome! Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 17:25:52 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:25:52 +0100 Subject: Color management in ubuntu In-Reply-To: <1278002564.2552.12.camel@localhost> References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 17:42, Marek Matulka wrote: > That would be awesome! I've been experimenting with GLSL shaders, and doing the color conversion in hardware on the GPU. We've hit a few stumbing blocks in clutter, but I'm adding API to clutter where required. Using the hardware allows us to do lots of clever interpolation in 3D to make things super sweet. Without using GPU hardware it's quite hard to process high-def video at normal frame rates. Long term this means we can attach a ClutterShader object to different mutter windows and color correct whole windows / subwindows on the GPU. Thatis, unless the application opts out of color managed mode. Or opts in. I'm not sure. There's a net-color-spec that we could use, although this seems very difficult to implement without working on a post-composited display like compiz provides. Either way, unless the ClutterTexture patches get written none of it will work :) Richard. From pmjdebruijn at pcode.nl Thu Jul 1 17:29:17 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:29:17 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: > Hello, > > This is my first post on the group, but I've been following a group for > some time. Well done guys for a rocking bit of software giving us a > great colour management tool! > > On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >> > So, to test how color management works in a browser, I found this web >> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >> > ?Using google chrome (a non color managed browser) this page is a mess of >> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >> > lot better - imbedded color profiles are now honored and the photos display >> > fine. However, about half-way down the page at the heading "sRGB / Standard >> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >> > trying to figure out why this is. >> > In my workflow all exif data is stripped from my photo's before I upload to >> > the web. ?I thought that this wouldn't matter, as long as my final image was >> > created in an sRGB colorspace. ?However, I have now found that my photo's >> > look subtly but definitely different in the software I use (gimp, digikam) >> > and my browsers. >> > My limited understanding of color management led me to believe that >> > un-tagged sRGB images should look the same in a browser on a color-managed >> > system. ?However, on my system they don't and its causing a problem for me - >> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >> > understanding wrong, should I educate myself a bit more? ?Did I do something >> > wrong when I calibrated my monitor? >> >> The problem is that being color managed, and being properly configured >> is not always the same... >> >> All color managed applications checked for an embedded profile when >> loading images and will for example convert an Adobe RGB image to sRGB >> on request. If an image is untagged sRGB will be assumed. >> >> However, if you do not properly configure the application to use your >> display profile it will be displayed as plain srgb without your >> display profile applied, hence wrong colors (since only the videolut >> will have effect). >> >> I think GIMP doesn't use the system display profile by default. >> >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". >> >> Same goes for lots of other applications. So you will still need to >> check each an every applications configuration. Since they might use >> poor defaults. > > I had similar issue - when I created three images: 1. tagged with Adobe > RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly > displayed in GIMP, but not in any desktop viewer. > > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. The tagging of an image has _NOTHING_ to do with applying a display profile or not... If this really is the case, then someone should really be shot for that (not dead... the knees will do just fine :). The application of the display profile (should) only depend on the application settings not on the input image... All programs assume untagged images are sRGB, (even though tagging images with an sRGB profile _is_ a good idea, this will prevent future ambiguity). Programs which aren't color managed (or where color management is disabled) are just RGBin (from file) == RGBout (to display) That said... Please also note that not all forms of sRGB are equal, there are several version of the sRGB profile that might differ a bit... I think at one time there even was a simplified sRGB with a real 2.2 gamma curve... which is wrong, since sRGB is gamma 2.4 with a small dead area in the blacks. Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Thu Jul 1 17:31:02 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:31:02 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:25 PM, Richard Hughes wrote: > On 1 July 2010 17:42, Marek Matulka wrote: >> That would be awesome! > > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. And you need to make the applications aware that they do not need to do their own color management... Otherwise apps like the GIMP might apply an output profile themselves, having the display rgb processed again by the GLSL shaders. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 17:34:17 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:34:17 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:31, Pascal de Bruijn wrote: > And you need to make the applications aware that they do not need to > do their own color management... Otherwise apps like the GIMP might > apply an output profile themselves, having the display rgb processed > again by the GLSL shaders. Right. This is why I think it's going to have to be opt-in. In reality, I think we're a long way from pushing this into a distro. Richard From pmjdebruijn at pcode.nl Thu Jul 1 17:38:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:38:37 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:29 PM, Pascal de Bruijn wrote: > On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: >> Hello, >> >> This is my first post on the group, but I've been following a group for >> some time. Well done guys for a rocking bit of software giving us a >> great colour management tool! >> >> On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >>> > So, to test how color management works in a browser, I found this web >>> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >>> > ?Using google chrome (a non color managed browser) this page is a mess of >>> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >>> > lot better - imbedded color profiles are now honored and the photos display >>> > fine. However, about half-way down the page at the heading "sRGB / Standard >>> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >>> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >>> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >>> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >>> > trying to figure out why this is. >>> > In my workflow all exif data is stripped from my photo's before I upload to >>> > the web. ?I thought that this wouldn't matter, as long as my final image was >>> > created in an sRGB colorspace. ?However, I have now found that my photo's >>> > look subtly but definitely different in the software I use (gimp, digikam) >>> > and my browsers. >>> > My limited understanding of color management led me to believe that >>> > un-tagged sRGB images should look the same in a browser on a color-managed >>> > system. ?However, on my system they don't and its causing a problem for me - >>> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >>> > understanding wrong, should I educate myself a bit more? ?Did I do something >>> > wrong when I calibrated my monitor? >>> >>> The problem is that being color managed, and being properly configured >>> is not always the same... >>> >>> All color managed applications checked for an embedded profile when >>> loading images and will for example convert an Adobe RGB image to sRGB >>> on request. If an image is untagged sRGB will be assumed. >>> >>> However, if you do not properly configure the application to use your >>> display profile it will be displayed as plain srgb without your >>> display profile applied, hence wrong colors (since only the videolut >>> will have effect). >>> >>> I think GIMP doesn't use the system display profile by default. >>> >>> Firefox also requires the display profile to be configured through >>> "about:config" search for "display_profile". >>> >>> Same goes for lots of other applications. So you will still need to >>> check each an every applications configuration. Since they might use >>> poor defaults. >> >> I had similar issue - when I created three images: 1. tagged with Adobe >> RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly >> displayed in GIMP, but not in any desktop viewer. >> >> I think the problem lies in assumption, that for untagged images viewer >> should not apply monitor profile, while it should assume sRGB and >> convert it accordingly. It seems GIMP is working that way hence all >> three images are correctly displayed. > > The tagging of an image has _NOTHING_ to do with applying a display > profile or not... If this really is the case, then someone should > really be shot for that (not dead... the knees will do just fine :). Cutting my own rant short... It's easy for forget (I often do), that color management as a concept is non-obvious for pretty much everybody (including normal coders) who aren't into this stuff... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Thu Jul 1 18:00:09 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 20:00:09 +0200 Subject: Conceptual questions Message-ID: <4C2CD7A9.90409@hoech.org> Hi, I have a few conceptual questions. Currently GCM has preferences for RGB and CMYK working space, and "display" and "softproof" rendering intent. But what I think is missing for softproofing is a checkbox "Simulate media (paper) color" which when checked (which would be a good default), means absolute colorimetric intent should be used, otherwise relative colorimetric (_without_ black point compensation). Is my current understanding of the GCM UI intentions correct as follows: Image -> "display" intent in GCM -> device (for non-softproofing) Image -> "softproof" intent in GCM -> softproof colorspace (is there a way in GCM to choose a default for this?) -> relative without bpc or abscol (it is not clear to me which is used/assumed by GCM by default, I'd think abscol?) -> device Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jul 1 18:23:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 19:23:19 +0100 Subject: Conceptual questions In-Reply-To: <4C2CD7A9.90409@hoech.org> References: <4C2CD7A9.90409@hoech.org> Message-ID: On 1 July 2010 19:00, Florian H?ch wrote: > I think is missing for softproofing is a checkbox "Simulate media (paper) > color" which when checked (which would be a good default), means absolute > colorimetric intent should be used, otherwise relative colorimetric Isn't that a per-application thing, rather than a per-session thing? By "softproof" GCM indicates the proofing mode to use when doing things like print preview. In a print preview aka "softproof" you already know the device you are targeting and the ICC profiles available. I also think it's useful to talk in terms of use-cases, rather than presenting lots of tickyboxes in preferences panels. I've got enough feedback (of the negative kind :-) from my boss about the number of UI elements we expose already. Maybe if we all refer to the three people here http://live.gnome.org/GnomeColorManager#Typical_Users we can all work towards further use-cases and application notes. I do think this is a really important discussion and am really pleased you're onboard. Thanks. Richard. From knizek.confy at volny.cz Thu Jul 1 18:58:16 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 01 Jul 2010 20:58:16 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: <1278010696.9901.3.camel@athlon> Marek Matulka p??e v ?t 01. 07. 2010 v 17:18 +0100: > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. > > I have filled a bug report against Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=606996 > > this bug report includes example screenshots of gimp and eog. > It seems to be a bug like the one reported by me upstream some time ago: https://bugzilla.gnome.org/show_bug.cgi?id=554498 regards, -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From lists+gnome-color-manager at hoech.org Thu Jul 1 19:22:28 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 21:22:28 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> Message-ID: <4C2CEAF4.9030006@hoech.org> Am 01.07.2010 20:23, schrieb Richard Hughes: > On 1 July 2010 19:00, Florian H?ch wrote: >> I think is missing for softproofing is a checkbox "Simulate media (paper) >> color" which when checked (which would be a good default), means absolute >> colorimetric intent should be used, otherwise relative colorimetric > > Isn't that a per-application thing, rather than a per-session thing? > By "softproof" GCM indicates the proofing mode to use when doing > things like print preview. In a print preview aka "softproof" you > already know the device you are targeting and the ICC profiles > available. Ok, sounds reasonable. If the device/profile being simulated is chosen in the application, there's probably no need for GCM to provide settings for a default "softproofing" colorspace. > I also think it's useful to talk in terms of use-cases, rather than > presenting lots of tickyboxes in preferences panels. I've got enough > feedback (of the negative kind :-) from my boss about the number of UI > elements we expose already. Maybe if we all refer to the three people > here http://live.gnome.org/GnomeColorManager#Typical_Users we can all > work towards further use-cases and application notes. :) don't worry, I'm not keen on having a GCM plastered with checkboxes either. Re use cases: My original inquiry would fit in no. #4 ("An application wants to softproof for a printer device to show the user how the colors are going to be clipped when the file is printed"). Now you already said thats probably a per-application thing. I'm just trying to wrap my head around where the current GCM "softproof" intent setting comes into play, what users are choosing with it exactly (like I said, my assuption was it is the image -> device being simulated transform, in which case it makes sense to expose all four intents), and how it interacts/relates to the "display" intent setting (which should then actually be ignored for softproofing by an application). > I do think this is a really important discussion and am really pleased > you're onboard. Thanks. > > Richard. -- Florian H?ch http://hoech.net From jorge.fabregas at gmail.com Fri Jul 2 12:36:50 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Fri, 2 Jul 2010 08:36:50 -0400 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <201007020836.50739.jorge.fabregas@gmail.com> On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". Hello guys, I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary options (gfx.color_management...), restarted Firefox and I still can't see this picture correctly: http://www.color.org/version4html.xalter I see it as if my system only supports "ICC version 2" as the examples shown. I load my ICC profile with "dispwin -L" when my system starts but I'm not sure if its "version 4"? How can I know this? (sorry newbie here when it comes to color management). Thanks, Jorge From pmjdebruijn at pcode.nl Fri Jul 2 12:39:52 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 2 Jul 2010 14:39:52 +0200 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Jorge F?bregas : > On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". > > Hello guys, > > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary > options (gfx.color_management...), restarted Firefox and I still can't see > this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples shown. > I load my ICC profile with "dispwin -L" when my system starts but I'm not sure > if its "version 4"? ?How can I know this? ?(sorry newbie here when it comes to > color management). Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. Firefox 3.5+ uses it's own internal CMS which only processes v2 profiles, but it's faster. Regards, Pascal de Bruijn From marek.matulka at gmail.com Fri Jul 2 12:41:38 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Fri, 02 Jul 2010 13:41:38 +0100 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <1278074498.3005.14.camel@localhost> On Fri, 2010-07-02 at 08:36 -0400, Jorge F?bregas wrote: > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the > necessary options (gfx.color_management...), restarted Firefox and I > still can't see this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples > shown. I load my ICC profile with "dispwin -L" when my system starts > but I'm not sure if its "version 4"? How can I know this? (sorry > newbie here when it comes to color management). AFAIK Firefox does not support version 4 yet. Greetings, Marek From hughsient at gmail.com Fri Jul 2 12:49:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:49:55 +0100 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Pascal de Bruijn : > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? Richard. From hughsient at gmail.com Fri Jul 2 12:58:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:58:55 +0100 Subject: Conceptual questions In-Reply-To: <4C2CEAF4.9030006@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: On 1 July 2010 20:22, Florian H?ch wrote: > Ok, sounds reasonable. If the device/profile being simulated is chosen in > the application, there's probably no need for GCM to provide settings for a > default "softproofing" colorspace. Right. I don't think a "default softproofing device" makes much sense when you're aiming the feature at things like print preview. A "default softproofing device" might make sense as a per-application option if you're proofing to a PDF or something, although that sounds all very application specific. > Now you already said thats probably a per-application thing. I'm just trying > to wrap my head around where the current GCM "softproof" intent setting > comes into play, what users are choosing with it exactly (like I said, my > assuption was it is the image -> device being simulated transform, in which > case it makes sense to expose all four intents), and how it > interacts/relates to the "display" intent setting (which should then > actually be ignored for softproofing by an application). I'm guessing it's just choosing where to put the line. I would argue that asking the user what rendering mode they want to use for a print preview is overboard, as you could just choose a good default and use that. Similarly for rendering random RGB spaces to the desktop, perceptual is probably the best plan. You could argue, the rendering intents should be hardcoded in the application, or just in GSettings/DBus and not in the UI, and I might agree with you. GCM is just trying to find the sweet pot between options-city and not-enough-control-to-be-useful. I still don't mind drastically changing the UI or DBus interface if we need to. If you've got any better ideas about what should be in the UI (BPC?) as a sensible per-session default then I'm interested. You could also argue that dispcalGUI and GCM should be working closer together in this respect, and I'm open for suggestions. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 14:21:29 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 16:21:29 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: <4C2DF5E9.6060203@hoech.org> Am 02.07.2010 14:58, schrieb Richard Hughes: > Right. I don't think a "default softproofing device" makes much sense > when you're aiming the feature at things like print preview. A > "default softproofing device" might make sense as a per-application > option if you're proofing to a PDF or something, although that sounds > all very application specific. I think I agree on this. > I'm guessing it's just choosing where to put the line. I would argue > that asking the user what rendering mode they want to use for a print > preview is overboard, as you could just choose a good default and use > that. Similarly for rendering random RGB spaces to the desktop, > perceptual is probably the best plan. Right. My concern is more if applications (or rather developers) then know to do the "right thing" when they query GCM for the current "softproof" setting to do a print preview, which would be, "convert image with user selected GCM 'softproof' intent to device space, then absolute colorimetrically to the display" - we don't want gamut mapping to happen twice, that would invalidate the print preview. Of course matrix profiles only support colorimetric either way. Still, it's something to keep in mind. > If you've got any better ideas about what should be in the UI (BPC?) > as a sensible per-session default then I'm interested. You could also > argue that dispcalGUI and GCM should be working closer together in > this respect, and I'm open for suggestions. Personally I'd probably label the current "softproof" intent setting as "print preview" or something along the line. And I think adding an option for BPC would indeed be a nice touch. Rather than adding a checkbox or other additional control, just another intent "Relative with black point compensation" could be added to the dropdown lists. Re making dispcalGUI and GCM work closer together: Sure, it's an option. I wouldn't limit it to dispcalGUI though as other screen calibration/profiling solutions may exist in future (I hear LProf was/is planning to have a measurement capability, but I have to admit I'm not really well informed in that regard). Some wild thinking: Users can already choose their preferred applications for different filetypes/tasks. Maybe in the future, users can choose the preferred calibration solution in a similar way? Although right now, it's probably over the top, as only dispcalGUI and GCM exist as viable options afaik :) (and of course, directly using the Argyll tools on the commandline) Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 14:56:18 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 15:56:18 +0100 Subject: Conceptual questions In-Reply-To: <4C2DF5E9.6060203@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: On 2 July 2010 15:21, Florian H?ch wrote: > Personally I'd probably label the current "softproof" intent setting as > "print preview" or something along the line. Yes, good idea, I've done this in git master. > And I think adding an option for BPC would indeed be a nice touch. Rather > than adding a checkbox or other additional control, just another intent > "Relative with black point compensation" could be added to the dropdown > lists. Do we every want to do relative /without/ BPC? > Some wild thinking: Users can already choose their preferred > applications for different filetypes/tasks. Maybe in the future, users can > choose the preferred calibration solution in a similar way? Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and GcmCalibrateManual, and it would be pretty easy to make that pluggable using GIO extension points. One for the future perhaps. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 15:07:33 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 17:07:33 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: <4C2E00B5.80403@hoech.org> Am 02.07.2010 16:56, schrieb Richard Hughes: > On 2 July 2010 15:21, Florian H?ch wrote: >> Personally I'd probably label the current "softproof" intent setting as >> "print preview" or something along the line. > > Yes, good idea, I've done this in git master. Nice! >> And I think adding an option for BPC would indeed be a nice touch. Rather >> than adding a checkbox or other additional control, just another intent >> "Relative with black point compensation" could be added to the dropdown >> lists. > > Do we every want to do relative /without/ BPC? For proofing, without BPC is a must of course. But for image -> arbitrary display/output space, defaulting to BPC "on" for relative colorimetric seems to be the right choice (and will surely avoid some "why are my blacks crushed" cries from users :)). >> Some wild thinking: Users can already choose their preferred >> applications for different filetypes/tasks. Maybe in the future, users can >> choose the preferred calibration solution in a similar way? > > Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and > GcmCalibrateManual, and it would be pretty easy to make that pluggable > using GIO extension points. One for the future perhaps. Cool. I agree it's still a bit early. > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 15:26:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 16:26:11 +0100 Subject: Conceptual questions In-Reply-To: <4C2E00B5.80403@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: On 2 July 2010 16:07, Florian H?ch wrote: > For proofing, without BPC is a must of course. But for image -> arbitrary > display/output space, defaulting to BPC "on" for relative colorimetric seems > to be the right choice (and will surely avoid some "why are my blacks > crushed" cries from users :)). So, for 'Print Preview' these make sense: perceptual relative-colormetric relative-colormetric-bpc saturation absolute-colormetric and for 'Display': perceptual relative-colormetric saturation absolute-colormetric I'm not completely sure of all the nuances of BPC myself, so I would certainly appreciate any pointers and corrections. Thanks. Richard From lists+gnome-color-manager at hoech.org Fri Jul 2 16:10:36 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 18:10:36 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: <4C2E0F7C.4010202@hoech.org> Am 02.07.2010 17:26, schrieb Richard Hughes: > On 2 July 2010 16:07, Florian H?ch wrote: >> For proofing, without BPC is a must of course. But for image -> arbitrary >> display/output space, defaulting to BPC "on" for relative colorimetric seems >> to be the right choice (and will surely avoid some "why are my blacks >> crushed" cries from users :)). > > So, for 'Print Preview' these make sense: > > perceptual > relative-colormetric > relative-colormetric-bpc > saturation > absolute-colormetric > > and for 'Display': > > perceptual > relative-colormetric > saturation > absolute-colormetric > > I'm not completely sure of all the nuances of BPC myself, so I would > certainly appreciate any pointers and corrections. Thanks. Actually, for both print preview and display BPC can make sense, it all depends on the combinations involved (always assuming the print preview intent is for the image -> simulated device transform, not the simulated device -> display transform). The key is when print preview is used, the transform to the display must not use BPC (or perceptual/saturation). But when print preview is not used, then BPC makes a lot of sense for display imho, to avoid crushed blacks (e.g. conversion from a working space like AdobeRGB with 'zero' blackpoint to a display profile with 'lighter' blackpoint). I hope I'm making sense. -- Florian H?ch http://hoech.net From graeme2 at argyllcms.com Sat Jul 3 02:11:43 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Sat, 03 Jul 2010 12:11:43 +1000 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <4C2E9C5F.3080208@argyllcms.com> Richard Hughes wrote: > Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? You can always try and talk sense into them, but it seemed a wild decision to begin with, and therefore much harder to back down from.. [I doubt that the Firefox CMM is faster than a GPU. It may not even be faster than Argyll's cctiff/imdi, in spite of them using assembler.] Graeme Gill. From jorge.fabregas at gmail.com Sat Jul 3 13:59:42 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Sat, 3 Jul 2010 09:59:42 -0400 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <201007030959.43042.jorge.fabregas@gmail.com> On Friday 02 July 2010 08:39:52 Pascal de Bruijn wrote: > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. I see. Thanks Pascal! All the best, Jorge From hughsient at gmail.com Mon Jul 5 16:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 5 Jul 2010 17:44:10 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:25, Richard Hughes wrote: > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. Thanks to Neil Roberts who has added the required 3D texture support to clutter, I've got a mutter tree on my system that does full screen color management with a simple shader on the GPU. I've also added some demo code to GCM, although it's a standalone program and needs the cogl-texture-3d branch of clutter installed to even compile. Now, I have to fix the remaining bugs in mutter to enable this stuff, and then we have to work out how to mask bits of windows that are already color managed. Net color spec already exists, but isn't very friendly to a composited desktop that isn't compiz, i.e. not rendering to a flat rectangle of pixels. It's also not very toolkit friendly. Richard. From jorge.fabregas at gmail.com Tue Jul 6 12:58:56 2010 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Tue, 6 Jul 2010 08:58:56 -0400 Subject: Wallpaper & Icons on GNOME Desktop Message-ID: <201007060858.56709.jorge.fabregas@gmail.com> Hello everyone, I'm just curious: If you use Gnome Color Manager to create/use/load your ICC monitor profile... Will the GNOME desktop itself take into consideration the monitor profile so that I can render the icons & wallpaper accordingly? Thanks, Jorge From pmjdebruijn at pcode.nl Tue Jul 6 15:26:15 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 6 Jul 2010 17:26:15 +0200 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: <201007060858.56709.jorge.fabregas@gmail.com> References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: 2010/7/6 Jorge F?bregas : > Hello everyone, > > I'm just curious: If you use Gnome Color Manager to create/use/load your ICC > monitor profile... Will the GNOME ?desktop itself ?take into consideration the > monitor profile so that I can render the icons & wallpaper accordingly? Nope... Only specific applications are fully color managed (GIMP, Inkscape, F-Spot, Darktable, UFRaw)... Though a good display profile consist of two part: - VideoLUT which is mostly white point correction and gamma correction - XYZ Matrix which is color correction The VideoLUT is applied by the video driver, so everything benefits from this... The XYZ Matrix is only used by color managed applications which are properly configured... For example GIMP has this disabled by default, it can easily be enabled from it's Preferences. Regards, Pascal de Bruijn From jorge.fabregas at gmail.com Thu Jul 8 02:30:11 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Wed, 7 Jul 2010 22:30:11 -0400 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: <201007072230.12136.jorge.fabregas@gmail.com> On Tuesday 06 July 2010 11:26:15 Pascal de Bruijn wrote: > Nope... Only specific applications are fully color managed (GIMP, > Inkscape, F-Spot, Darktable, UFRaw)... Ok. > Though a good display profile consist of two part: > > - VideoLUT which is mostly white point correction and gamma correction > - XYZ Matrix which is color correction Yes, I had to read many articles about the difference between monitor calibration and profiling (and how many people new to CMS confuse both). > The VideoLUT is applied by the video driver, so everything benefits from > this... I see. I get it now. And indeed I notice a BIG difference on my overall desktop when I load the ICC profile. The change on visual appearance of my screen - when the calibration-part gets loaded (gamma & white-point correction) - is considerably higher than the changes made when a color-managed app takes into consideration the profile part (color correction). > The XYZ Matrix is only used by color managed applications which are > properly configured... I see, so the GNOME desktop (and practically anything X-related) takes advantage of the information stored on the VideoLUT but I won't see anything color-corrected (from the profiling part of the ICC) until a capable app is configured to do so. Thank you very much Pascal ! I really appreciate your help. All the best, Jorge From alexandre.prokoudine at gmail.com Thu Jul 15 23:46:59 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Fri, 16 Jul 2010 03:46:59 +0400 Subject: gcm not working for second logged in user Message-ID: Hi, It was reported earlier on IRC that g-c-m doesn't work for the second logged in user -- the applet starts and then closes itself. The user who reported that moved from 2.31.1 back to 2.30.0(-0ubuntu3) and still experiences the issue. Here is the current log, for 2.30: http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 11:34:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 12:34:24 +0100 Subject: libcolor-glib Message-ID: I've just merged a pretty big branch into GCM git master. libcolor-glib is a new library to be used pretty much exclusively by GCM. It's not designed to be used by end-user-applications like gimp and darktable, but instead just by gnome-color-manager and any additional tools that ISV's want to build. End user applications should continue to use the DBus interface which has not changed. libcolor-glib is starting to grow in functionality, and some of the core new pieces are: * Userspace DDC control, so we can control things like the HP DreamColor monitors and upload custom color spaces. * In-process colorimeter reading. The last point is interesting. I wanted to put the calibration routines in process, so we can get rid of that crappy VTE window, output scraping and all the popups from that. It would also allow us to do ambient lighting control like the windows tools do. This would however mean using argyll as a library (which it isn't) and also using argyll "headless", i.e. without a VTE. Argyll doesn't work very well without a console attached to it. Argyll is also AGPLv3, so can't be run in process with a GPLv2+ program. So, I've spent a couple of evenings reverse engineering the HUEY device. I needed a MIT licensed version of this code for another project I'm working on, and so including it in GCM as LGPLv2+ seemed obvious. The GcmSensorHuey object kinda works now, although I've made some very large guesses and approximations, and the XYZ color only *just* bears some resemblance to reality. The ambient light sensor does however work reliably, although I had to work out a fudge factor using my ColorMunki, so isn't exactly precise. If you know anything technical about the hardware, I'm all ears. So, for the next release if you're using a Huey and gcm-picker, you get the GCM in-process native driver. Anything else (including the ColorMunki) you get to use argyll like normal. Calibration is still always done with argyll, as generating a ICC profile is a little more involved that just getting a few XYZ values. So, a few Q&A's: Q: Do I intend on making other native drivers for other hardware A: No, as I don't have the hardware. I might make bits of the ColorMunki work like the ambient light sensor, although I'm having problems getting traces from the windows driver. Q: Are the GcmSensorHuey values accurate? A: No. If we know a bit more about the hardware we can reduce the amount of futzing and bodging we do. When my head recovers (reverse engineering is hard...) I'll take a look and see if we're doing anything batshit insane. Q: Can we help by copying the logic out of the decompiled windows driver or from Argyll. A: No. Don't even look at other source code if you want to contribute code as LGPLv2+. Note: it's okay to strace argyll commands, or to record the windows driver usb traffic, and this is what I've been doing. Q: Are you working on a sekret project? A: No. I'm putting a few technical demos together, but nothing sekret. Q: Are you aiming to replace Argyll. A: No. Argyll is a mature project that works really well and is a complete calibration workflow. GCM is a new project that does very limited things. Questions ahoy! :-) Richard. From alexandre.prokoudine at gmail.com Mon Jul 19 11:48:11 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 19 Jul 2010 15:48:11 +0400 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 7/19/10, Richard Hughes wrote: > libcolor-glib is starting to grow in functionality, and some of the > core new pieces are: > > * Userspace DDC control, so we can control things like the HP > DreamColor monitors and upload custom color spaces. > * In-process colorimeter reading. Tell me, are you up to Nobel prize this year? :) That sounds awesome! But I demand details about DDC :) Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 12:33:08 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:33:08 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 12:48, Alexandre Prokoudine wrote: > Tell me, are you up to Nobel prize this year? :) No, but I'm doing a talk at GUADEC and want to show some impressive demos. > That sounds awesome! But I demand details about DDC :) Right. Most of the core DDC logic belongs in the kernel, but a few of the device specific controls probably belong in userspace. The DreamColor display (which I'm hoping will arrive really soon now) will allow us to test and use a 30bit LUT in Xorg, and display wide gamut images. We need to use DDC controls to talk to the engine in the display, and I'm also waiting for more detailed specs to come out of HP. For what it's worth, HP have been very helpful indeed. A lot of the stuff I've been working on recently (GLSL hardware shaders, libcolor-glib) allows us to build a framework that's acceptable to the big-name studios, and keeping to the "just works" GNOME mantra. There's still a lot of work to do, but it's coming on fast now. I would really appreciate any help with the hardware parts, as a color sensor giving "kinda approximate" XYZ values isn't particularly useful. Richard. From pmjdebruijn at pcode.nl Mon Jul 19 12:41:51 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 19 Jul 2010 14:41:51 +0200 Subject: libcolor-glib In-Reply-To: References: Message-ID: On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: > On 19 July 2010 12:48, Alexandre Prokoudine > wrote: >> Tell me, are you up to Nobel prize this year? :) > > No, but I'm doing a talk at GUADEC and want to show some impressive demos. Well it all sounds pretty kick ass... But uh... so you'll be in the Netherlands? 26-30th? Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jul 19 12:53:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:53:21 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 13:41, Pascal de Bruijn wrote: > On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: >> On 19 July 2010 12:48, Alexandre Prokoudine >> wrote: >>> Tell me, are you up to Nobel prize this year? :) >> >> No, but I'm doing a talk at GUADEC and want to show some impressive demos. > > Well it all sounds pretty kick ass... > But uh... so you'll be in the Netherlands? 26-30th? I'll be in the Hague from 24th to the 31st. It would be good to grab a beer or seven. Richard. From hughsient at gmail.com Tue Jul 20 09:00:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 10:00:10 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 16 July 2010 00:46, Alexandre Prokoudine wrote: > http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 I've just fixed this, you want to apply dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Thanks, Richard. From alexandre.prokoudine at gmail.com Tue Jul 20 09:42:52 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Tue, 20 Jul 2010 13:42:52 +0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 7/20/10, Richard Hughes wrote: > On 16 July 2010 00:46, Alexandre Prokoudine > wrote: >> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 > > I've just fixed this, you want to apply > dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Many thanks! Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Tue Jul 20 12:03:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 13:03:56 +0100 Subject: GUADEC Message-ID: I've just finished writing my slides[1] for GUADEC. I'm presenting on the Friday afternoon, see http://www.guadec.org/index.php/guadec/2010/schedConf/program for details. I'm going to be there for the full week. If you grab me at GUADEC, be sure to introduce yourself as I'm really bad with names and faces. :-) Hopefully see some of you there! Richard. [1] I say "writing", but it's mostly all pictures and diagrams... From luto at mit.edu Tue Jul 20 19:06:51 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 20 Jul 2010 15:06:51 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: I have a Dell U2711, which has 10 bits per channel over DisplayPort (although I'm not sure that anything other than i915 can drive 10 bits right now, and even i915 needs bleeding-edge drivers). Can GCM program a 10-bit video card LUT? Also, the U2711 has an internal LUT, although no one seems to know how to program it (even on Windows) or even whether it can be programmed with anything other than a (not-very-good) factory calibration. Richard, did your libcolor-glib work give you any ideas for how to test for DDC control of a LUT on an unknown monitor? I'd be happy to test and fiddle. --Andy From pmjdebruijn at pcode.nl Tue Jul 20 21:58:32 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 20 Jul 2010 23:58:32 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 11:42 AM, Alexandre Prokoudine wrote: > On 7/20/10, Richard Hughes wrote: >> On 16 July 2010 00:46, Alexandre Prokoudine >> wrote: >>> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 >> >> I've just fixed this, you want to apply >> dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x I applied that patch to my 2.31.1 package too... However, I'm still curious then... User 1 logs in: gcm-prefs loads videolut gcm-prefs sets profile atom for user 1 User 2 logs in gcm-prefs loads videolut (from a different profile) gcm-prefs sets profile atom for user 2 User 1 switches back... Won't user 1 now end up the the video lut of the profile of user 2, but still have his own profile's atom set? This obviously won't be a problem if both users use the same profile... Regards, Pascal de Bruijn From hughsient at gmail.com Wed Jul 21 08:26:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:26:38 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 20 July 2010 22:58, Pascal de Bruijn wrote: > User 2 logs in > gcm-prefs loads videolut (from a different profile) > gcm-prefs sets profile atom for user 2 Yes, this is a valid bug. We probably should get our GSD plugin to watch for ConsoleKit changes (the ACTIVE attribute) but really this needs some proper session support. I really don't want to add yet another session process just watching for a session active state change. Better ideas welcome. Richard. From hughsient at gmail.com Wed Jul 21 08:32:50 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:32:50 +0100 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). ?Can GCM > program a 10-bit video card LUT? In theory, yes. I've made the GcmClut object generate the amount of data for each LUT size, but I admit I've never tested it on anything other than 8 bpp. > Also, the U2711 has an internal LUT, although no one seems to know how > to program it (even on Windows) or even whether it can be programmed > with anything other than a (not-very-good) factory calibration. > Richard, did your libcolor-glib work give you any ideas for how to > test for DDC control of a LUT on an unknown monitor? ?I'd be happy to > test and fiddle. Yes. I'm still waiting for me DreamColor monitor to arrive, and that allows a custom colorspace to be uploaded. For your monitor, you probably need to convince the manufacturer to give you the specs, or find a windows tool that calibrates the monitor and then trace that. You always have to be a little but careful sending hardware random data to reverse engineer it. First, the output of "gcm-ddc-util --enumerate" should give us something to work on. Richard. From luto at mit.edu Wed Jul 21 21:09:39 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Wed, 21 Jul 2010 17:09:39 -0400 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 4:32 AM, Richard Hughes wrote: > On 20 July 2010 20:06, Andrew Lutomirski wrote: >> I have a Dell U2711, which has 10 bits per channel over DisplayPort >> (although I'm not sure that anything other than i915 can drive 10 bits >> right now, and even i915 needs bleeding-edge drivers). ?Can GCM >> program a 10-bit video card LUT? > > In theory, yes. I've made the GcmClut object generate the amount of > data for each LUT size, but I admit I've never tested it on anything > other than 8 bpp. > >> Also, the U2711 has an internal LUT, although no one seems to know how >> to program it (even on Windows) or even whether it can be programmed >> with anything other than a (not-very-good) factory calibration. >> Richard, did your libcolor-glib work give you any ideas for how to >> test for DDC control of a LUT on an unknown monitor? ?I'd be happy to >> test and fiddle. > > Yes. I'm still waiting for me DreamColor monitor to arrive, and that > allows a custom colorspace to be uploaded. For your monitor, you > probably need to convince the manufacturer to give you the specs, or > find a windows tool that calibrates the monitor and then trace that. > > You always have to be a little but careful sending hardware random > data to reverse engineer it. First, the output of "gcm-ddc-util > --enumerate" should give us something to work on. gcm-dump-edid says: Monitor name: DELL U2711 Vendor name: Dell Serial number: D971T0471EFL PNP identifier: DEL Size: 60x34 Gamma: 2.200000 gcm-ddc-util --enumerate says: $ sudo ./gcm-ddc-util --enumerate EDID: f3b71e4fd0bf14ac3db509cbc4ba48ba PNPID: DELA055 Model: U2711 0x02 [secondary-degauss] 0x04 [reset-factory-defaults] 0x05 [reset-brightness-and-contrast] 0x06 [reset-factory-geometry] 0x08 [reset-factory-default-color] 0x10 [brightness] 0x12 [contrast] 0x14 [select-color-preset] ( 1 5 8 0 0 ) 0x16 [red-video-gain] 0x18 [green-video-gain] 0x1a [blue-video-gain] 0x52 [saturation] 0x60 [input-source-select] ( 1 3 4 5 0 0 11 ) 0xac [horizontal-frequency] 0xae [vertical-frequency] 0xb2 [unknown] 0xb6 [unknown] 0xc6 [unknown] 0xc8 [unknown] 0xc9 [firmware-version] 0xd6 [dpms-control-(1---on/4---stby)] ( 1 4 5 ) 0xdc [magicbright-(1---text/2---internet/3---entertain/4---custom)] ( 0 2 3 4 5 ) 0xdf [vcp-version] 0xfd [power-led] --control 0xb2 --get doesn't seem to work. This is also suspicious: $ sudo ./gcm-ddc-util --display f3b71e4fd0bf14ac3db509cbc4ba48ba --control vcp-version --get vcp-version is 513, max is 255 I'm not really sure what I'm looking for, though, and I haven't spotted the DreamColor code. (Is it there?) --Andy > > Richard. > From alexdeucher at gmail.com Thu Jul 22 04:12:46 2010 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 22 Jul 2010 00:12:46 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). Can GCM > program a 10-bit video card LUT? FWIW, all radeons (even the original r100) support 10 bit LUTs. Alex From graeme2 at argyllcms.com Thu Jul 22 04:59:52 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 22 Jul 2010 14:59:52 +1000 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: <4C47D048.70702@argyllcms.com> Alex Deucher wrote: > FWIW, all radeons (even the original r100) support 10 bit LUTs. My Nvidia 8600GT has 10 bit LUTs & D/A converters to VGA. I'd imagine that the digital path to the display is only 8 bit though.. Graeme Gill. From hughsient at gmail.com Thu Jul 22 09:16:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 10:16:40 +0100 Subject: Anyone got a huey? Message-ID: Have any of you got a huey and a few minutes? I want to do some comparisons between two dumps to try to find differences and to help reverse engineer it. Yell if you can help. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 10:00:11 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 12:00:11 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: > Have any of you got a huey and a few minutes? I want to do some > comparisons between two dumps to try to find differences and to help > reverse engineer it. Yell if you can help. Got One... What do I need to do? I can get back to you tonight... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 11:45:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 12:45:10 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 11:00, Pascal de Bruijn wrote: > On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >> Have any of you got a huey and a few minutes? I want to do some >> comparisons between two dumps to try to find differences and to help >> reverse engineer it. Yell if you can help. > > Got One... > > What do I need to do? * Build GCM git master from today * Insert the HUEY * ./tools/gcm-dump-sensor * Send me offlist the sensor-dump.txt file it produces. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 13:02:30 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 15:02:30 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:45 PM, Richard Hughes wrote: > On 22 July 2010 11:00, Pascal de Bruijn wrote: >> On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >>> Have any of you got a huey and a few minutes? I want to do some >>> comparisons between two dumps to try to find differences and to help >>> reverse engineer it. Yell if you can help. >> >> Got One... >> >> What do I need to do? > > * Build GCM git master from today > * Insert the HUEY > * ./tools/gcm-dump-sensor > * Send me offlist the sensor-dump.txt file it produces. Would that build on GNOME 2.30.x? Maybe I could try an alpha live cd of sorts, I'll try to work something out... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 13:15:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 14:15:54 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 14:02, Pascal de Bruijn wrote: > Would that build on GNOME 2.30.x? No way. Although, you could probably hack up configure to lower the deps and then _only_ build libcolor-glib and the tools. That might work. > Maybe I could try an alpha live cd of sorts, I'll try to work something out... Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds and then installing http://people.freedesktop.org/~hughsient/fedora/13/i386/ should probably work. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 16:30:47 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 18:30:47 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 3:15 PM, Richard Hughes wrote: > On 22 July 2010 14:02, Pascal de Bruijn wrote: >> Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > >> Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds > and then installing > http://people.freedesktop.org/~hughsient/fedora/13/i386/ should > probably work. Well, I got a whole lot of won't boot :) I could bring the Huey with me next Friday to GUADEC so you can check it out yourself? Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 16:53:46 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 17:53:46 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 17:30, Pascal de Bruijn wrote: > I got a whole lot of won't boot :) Hah! Welcome to rawhide ;-) > I could bring the Huey with me next Friday to GUADEC so you can check > it out yourself? That would be good, thanks. It only takes about 2 seconds to dump all the registers. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 17:11:55 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 19:11:55 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: > On 20 July 2010 22:58, Pascal de Bruijn wrote: >> User 2 logs in >> gcm-prefs loads videolut (from a different profile) >> gcm-prefs sets profile atom for user 2 > > Yes, this is a valid bug. We probably should get our GSD plugin to > watch for ConsoleKit changes (the ACTIVE attribute) but really this > needs some proper session support. I really don't want to add yet > another session process just watching for a session active state > change. Well it's a very rare use case tho... Since screen calibration is inherently a system properly and not really a user thing... It could become a user thing when two users disagree on what gamma/white point should be profiled against... But then again, there isn't that much debate about this, and even so, a single shop will standardize to a single setting... Though technically it's a bug that could be hit and produce some really funky shit :) Regards, Pascal de Bruijn From andy at luto.us Thu Jul 22 17:40:11 2010 From: andy at luto.us (Andrew Lutomirski) Date: Thu, 22 Jul 2010 13:40:11 -0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: > On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>> User 2 logs in >>> gcm-prefs loads videolut (from a different profile) >>> gcm-prefs sets profile atom for user 2 >> >> Yes, this is a valid bug. We probably should get our GSD plugin to >> watch for ConsoleKit changes (the ACTIVE attribute) but really this >> needs some proper session support. I really don't want to add yet >> another session process just watching for a session active state >> change. > > Well it's a very rare use case tho... > > Since screen calibration is inherently a system properly and not > really a user thing... I disagree. Profiling the monitor is inherently a system thing (presumably it's the *same* monitor for all users). The LUT setting is a different story. One user might want 6500K, another might want 7000K, and a third might want no correction at all for maximum 3D gamut because they know that whatever program they care about is already using a CLUT profile. A fourth user might run dispwin -c themselves and the first user might want their calibration back when they switch back. (Of course, the profile to use depends on the LUT, but that's "just" an implementation detail.) > > It could become a user thing when two users disagree on what > gamma/white point should be profiled against... But then again, there > isn't that much debate about this, and even so, a single shop will > standardize to a single setting... You should get a Lenovo X series laptop. I had to calibrate mine to 6000K because the screen is *so* bad that I lose an annoying amount of brightness and get rather crappy results if I calibrate to anything else. (Last I checked, the calibration GUI doesn't have that setting, so I just did it manually with dispcal.) But I'm not sure there's a problem at all. Don't the two users have their own X servers, and shouldn't the X server restore the LUT on its own? (I *think* that drv-intel 2.9.0 or newer with recent xserver is smart enough.) --Andy From len at math.northwestern.edu Fri Jul 23 15:58:21 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Fri, 23 Jul 2010 10:58:21 -0500 Subject: Fedora version Message-ID: <1279900701.7721.14.camel@localhost> I would liked to try out gnome color management. I am currently using Fedora 12, but I can if necessary upgrade to Fedora 13. I understand that it will be available as a Fedora 14 package, but I wonder if a package is available I could try before that. I can if necessary compile it from source, but that is usually time consuming and requires searching for additional packages. I have used Argyllcms with an Eye One Pro to calibrate/profile my monitor and my printer. Gimp, firefox, and inkscape can use the monitor profile, but there are some difficulties with other applications such as eye of gnome. I've been printing by a complicated method using argyllcms and photoprint. I was hoping an integrated gnome package might allow me to deal with such matters in a straightforward manner. Can you suggest anything to help? P.S. I do have Ubuntu on a laptop, but working from there would be a bit awkward. -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Fri Jul 23 16:12:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Jul 2010 17:12:16 +0100 Subject: Fedora version In-Reply-To: <1279900701.7721.14.camel@localhost> References: <1279900701.7721.14.camel@localhost> Message-ID: On 23 July 2010 16:58, Leonard Evens wrote: > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > 13. ?I understand that it will be available as a Fedora 14 package, but > I wonder if a package is available I could try before that. Just update to fedora 13. It's included by default. Richard. From marek at matulka.net Fri Jul 23 16:22:23 2010 From: marek at matulka.net (Marek Matulka) Date: Fri, 23 Jul 2010 17:22:23 +0100 Subject: Fedora version In-Reply-To: References: <1279900701.7721.14.camel@localhost> Message-ID: <1279902143.2667.32.camel@localhost> On Fri, 2010-07-23 at 17:12 +0100, Richard Hughes wrote: > On 23 July 2010 16:58, Leonard Evens wrote: > > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > > 13. I understand that it will be available as a Fedora 14 package, but > > I wonder if a package is available I could try before that. > > Just update to fedora 13. It's included by default. how do I get a ?calibrate? functionality? I have a Fedora 13 installed, with argyllcms and all required packages, I can do calibration manually from the command line, but not through gnome-color-management package... I use Spyder 2. Thanks, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From knizek.confy at volny.cz Sun Jul 25 06:29:02 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sun, 25 Jul 2010 08:29:02 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: <1280039342.4370.22.camel@localhost> Richard Hughes p??e v ?t 22. 07. 2010 v 14:15 +0100: > On 22 July 2010 14:02, Pascal de Bruijn wrote: > > Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > > > Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds It does not boot for me either (cannot mount /dev/mapper/live-rw filesystem), I may try in a week time again. BTW, I have got a huey, which was delivered with wide-gamut Samsung XL20. There was a discussion on argyllcms list whether it is somehow modified or not compared to a standard huey. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Sun Jul 25 13:21:15 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 25 Jul 2010 14:21:15 +0100 Subject: Anyone got a huey? In-Reply-To: <1280039342.4370.22.camel@localhost> References: <1280039342.4370.22.camel@localhost> Message-ID: On 25 July 2010 07:29, Milan Kn??ek wrote: > There was a discussion on argyllcms list whether it is somehow > modified or not compared to a standard huey. I would be very interested in the dump, although I know GCM is kinda hard to install at the moment. Richard. From amluto at gmail.com Sun Jul 25 13:35:50 2010 From: amluto at gmail.com (Andy Lutomirski) Date: Sun, 25 Jul 2010 09:35:50 -0400 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: I'll send the patch I used later on. It's enough to build libcolor-glib (sans gcm-brightness) and the tools. --Andy On Jul 25, 2010, at 9:21 AM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list From knizek.confy at volny.cz Mon Jul 26 07:55:12 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 09:55:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: <1280130912.5411.3.camel@localhost> Richard Hughes p??e v Ne 25. 07. 2010 v 14:21 +0100: > On 25 July 2010 07:29, Milan Kn??ek wrote: > > There was a discussion on argyllcms list whether it is somehow > > modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Would it help to install Fedora 13 and compile on it? Or install Fedora 13 and upgrade to current development version ("rawhide" - is there a howto?)? P.S. I am used to Archlinux and Ubuntu, hence sorry for beginner's questions. regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at MIT.EDU Mon Jul 26 14:41:36 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:41:36 -0400 Subject: [PATCH] Make -Werror command-line configurable Message-ID: <1280155296-1270-1-git-send-email-luto@mit.edu> -Werror is already enabled by --enable-strict (default) and GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do that and don't hardcode it. --- Hi all- This is my first of two patches for building libcolor-glib on F13. This one is probable suitable for the real tree. The second one is way too hackish. --Andy configure.ac | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d34767d..7572ee1 100644 --- a/configure.ac +++ b/configure.ac @@ -51,7 +51,7 @@ LT_INIT AM_PROG_CC_C_O IT_PROG_INTLTOOL([0.35.0]) -GNOME_COMPILE_WARNINGS +GNOME_COMPILE_WARNINGS(error) GNOME_DOC_INIT # set up gtk-doc @@ -91,7 +91,6 @@ CPPFLAGS="$CPPFLAGS -DGSEAL_ENABLE" if test "$GCC" = "yes"; then WARNINGFLAGS_C="$WARNINGFLAGS_C -Wall" - WARNINGFLAGS_C="$WARNINGFLAGS_C -Werror" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wcast-align -Wno-uninitialized" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wmissing-declarations" # WARNINGFLAGS_C="$WARNINGFLAGS_C -Wredundant-decls" -- 1.7.1.1 From luto at MIT.EDU Mon Jul 26 14:45:02 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:45:02 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 Message-ID: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> This patch, if configured with ./configure --enable-compile-warnings=yes --disable-sane --disable-strict is enough to build libcolor-glib and most of tools. (You'll have to cd explicitly -- 'make libcolor-glib' doesn't do anything.) --- configure.ac | 16 ++++---- libcolor-glib/gcm-brightness.c | 80 +------------------------------------- libcolor-glib/gcm-sensor-huey.c | 4 +- libcolor-glib/gcm-usb.c | 11 ++--- 4 files changed, 18 insertions(+), 93 deletions(-) diff --git a/configure.ac b/configure.ac index 7572ee1..8a5c64b 100644 --- a/configure.ac +++ b/configure.ac @@ -134,20 +134,20 @@ GLIB_GSETTINGS dnl --------------------------------------------------------------------------- dnl - Check library dependencies dnl --------------------------------------------------------------------------- -PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.9) +PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.24) PKG_CHECK_MODULES(XORG, xxf86vm xrandr) -PKG_CHECK_MODULES(GTK, gtk+-3.0 >= 2.90.3) -PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) +PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.20) +#PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) PKG_CHECK_MODULES(GUDEV, gudev-1.0) PKG_CHECK_MODULES(LCMS, lcms2) PKG_CHECK_MODULES(X11, x11) PKG_CHECK_MODULES(USB, [libusb-1.0 >= 1.0.0]) dnl Required for the properties window -PKG_CHECK_MODULES(CONTROL_CENTER, [ - libgnome-control-center >= 2.31.4]) -PANELS_DIR="${libdir}/control-center-1/panels" -AC_SUBST(PANELS_DIR) +#PKG_CHECK_MODULES(CONTROL_CENTER, [ + #libgnome-control-center >= 2.31.4]) +#PANELS_DIR="${libdir}/control-center-1/panels" +#AC_SUBST(PANELS_DIR) dnl **** Check for VTE **** PKG_CHECK_MODULES(VTE, vte3 >= 0.25.1, has_vte=yes, has_vte=no) @@ -195,7 +195,7 @@ if test x$enable_exiv = xyes; then AC_DEFINE(HAVE_EXIV,1,[Use EXIV support for detecting scanners]) fi -PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) +#PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) PKG_CHECK_MODULES(EXIF, libexif) AC_CHECK_LIB(tiff, TIFFReadRGBAImageOriented, diff --git a/libcolor-glib/gcm-brightness.c b/libcolor-glib/gcm-brightness.c index 3785e50..251810a 100644 --- a/libcolor-glib/gcm-brightness.c +++ b/libcolor-glib/gcm-brightness.c @@ -47,7 +47,7 @@ static void gcm_brightness_finalize (GObject *object); struct _GcmBrightnessPrivate { guint percentage; - GDBusConnection *connection; + void *connection; }; enum { @@ -68,43 +68,7 @@ G_DEFINE_TYPE (GcmBrightness, gcm_brightness, G_TYPE_OBJECT) gboolean gcm_brightness_set_percentage (GcmBrightness *brightness, guint percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *args = NULL; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - g_return_val_if_fail (percentage <= 100, FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - args = g_variant_new ("(u)", percentage), - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "SetBrightness", - args, - NULL, - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* success */ - ret = TRUE; -out: - if (args != NULL) - g_variant_unref (args); - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** @@ -113,45 +77,7 @@ out: gboolean gcm_brightness_get_percentage (GcmBrightness *brightness, guint *percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "GetBrightness", - NULL, - G_VARIANT_TYPE ("(u)"), - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* get the brightness */ - g_variant_get (response, "(u)", &priv->percentage); - - /* copy if set */ - if (percentage != NULL) - *percentage = priv->percentage; - - /* success */ - ret = TRUE; -out: - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** diff --git a/libcolor-glib/gcm-sensor-huey.c b/libcolor-glib/gcm-sensor-huey.c index 63ede01..3778266 100644 --- a/libcolor-glib/gcm-sensor-huey.c +++ b/libcolor-glib/gcm-sensor-huey.c @@ -363,7 +363,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to send request: %s", libusb_strerror (retval)); + "failed to send request"); goto out; } @@ -377,7 +377,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to get reply: %s", libusb_strerror (retval)); + "failed to get reply"); goto out; } diff --git a/libcolor-glib/gcm-usb.c b/libcolor-glib/gcm-usb.c index 891ff0f..85a5c87 100644 --- a/libcolor-glib/gcm-usb.c +++ b/libcolor-glib/gcm-usb.c @@ -301,8 +301,7 @@ gcm_usb_load (GcmUsb *usb, GError **error) if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to init libusb: %s", - libusb_strerror (retval)); + "failed to init libusb"); goto out; } @@ -375,8 +374,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to set configuration 0x%02x: %s", - configuration, libusb_strerror (retval)); + "failed to set configuration 0x%02x", + configuration); ret = FALSE; goto out; } @@ -384,8 +383,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to claim interface 0x%02x: %s", - interface, libusb_strerror (retval)); + "failed to claim interface 0x%02x", + interface); ret = FALSE; goto out; } -- 1.7.1.1 From hughsient at gmail.com Mon Jul 26 15:17:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:17:21 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 22 July 2010 18:40, Andrew Lutomirski wrote: > On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: >> On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >>> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>>> User 2 logs in >>>> gcm-prefs loads videolut (from a different profile) >>>> gcm-prefs sets profile atom for user 2 >>> >>> Yes, this is a valid bug. We probably should get our GSD plugin to >>> watch for ConsoleKit changes (the ACTIVE attribute) but really this >>> needs some proper session support. I really don't want to add yet >>> another session process just watching for a session active state >>> change. >> >> Well it's a very rare use case tho... commit dbebdeaeda3e9d48d5fa61bd9a2cd334fb61a4ce Author: Richard Hughes Date: Mon Jul 26 16:49:50 2010 +0100 Add a gnome-settings-daemon module to fix some hard to fix bugs This allows us to: 1) set gcm-apply when we switch users, so the correct VCGT is used 2) open the calibration window when a colorimeter is plugged in :100644 100644 0121d84... 3dcc91b... M Makefile.am :100644 100644 aa540d6... b030aba... M configure.ac :100644 100644 efdf3d4... c6cee42... M contrib/gnome-color-manager.spec.in :000000 100644 0000000... 0c620eb... A session/.gitignore :000000 100644 0000000... cba7279... A session/Makefile.am :000000 100644 0000000... fb6ec82... A session/color.gnome-settings-plugin :000000 100644 0000000... 312188e... A session/egg-console-kit.c :000000 100644 0000000... 2d897f1... A session/egg-console-kit.h :000000 100644 0000000... cc86414... A session/gsd-color-manager.c :000000 100644 0000000... 0c70ef5... A session/gsd-color-manager.h :000000 100644 0000000... 3883953... A session/gsd-color-plugin.c :000000 100644 0000000... d72b4bd... A session/gsd-color-plugin.h :100644 100644 a8848e8... 844c0b8... M src/Makefile.am :100644 100644 9b53705... 99aa7f2... M src/gcm-apply.c Richard. From hughsient at gmail.com Mon Jul 26 15:48:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:48:43 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: On 26 July 2010 15:45, Andy Lutomirski wrote: > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. ?(You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) Yup. Gross. :-) but thanks for posting. Richard. From hughsient at gmail.com Mon Jul 26 15:50:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:50:23 +0100 Subject: [PATCH] Make -Werror command-line configurable In-Reply-To: <1280155296-1270-1-git-send-email-luto@mit.edu> References: <1280155296-1270-1-git-send-email-luto@mit.edu> Message-ID: On 26 July 2010 15:41, Andy Lutomirski wrote: > -Werror is already enabled by --enable-strict (default) and > GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do > that and don't hardcode it. Applied, thanks. Richard. From pmjdebruijn at pcode.nl Mon Jul 26 18:31:12 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 26 Jul 2010 20:31:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On Sun, Jul 25, 2010 at 3:21 PM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Kinda is a bit of an understatement :p Anyhow, there's another easy and nasty way to solve this... Can't you provide fully statically built versions of the utils? I can get you a DDC dump of my display as well... Regards, Pascal de Bruijn From knizek.confy at volny.cz Mon Jul 26 19:32:35 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 21:32:35 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: <1280172755.4389.13.camel@localhost> Andy Lutomirski p??e v Po 26. 07. 2010 v 10:45 -0400: > This patch, if configured with > > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. (You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) The patch applied with errors on configure.ac, I updated it manually accordingly. However, there are still missing lcms2 and libusb-1.0 packages in Fedora 13 repositories. I have removed the version requirements for the two, but compilation afterwards failed on some libusb matters. As Pascal suggested, could someone skilled provide the necessary binaries compiled statically so that we can send the sensor data? Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Mon Jul 26 23:22:31 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:22:31 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280172755.4389.13.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: On 26 July 2010 20:32, Milan Kn??ek wrote: > As Pascal suggested, could someone skilled provide the necessary > binaries compiled statically so that we can send the sensor data? Grab the packages from http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/ and rebuild them. They should work okay on F12/13. Richard. From hughsient at gmail.com Mon Jul 26 23:25:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:25:02 +0100 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On 26 July 2010 19:31, Pascal de Bruijn wrote: > Can't you provide fully statically built versions of the utils? Ick. I'll give this a try, but I think it is made deliberately hard on Fedora. Richard. From len at math.northwestern.edu Mon Jul 26 23:45:28 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Mon, 26 Jul 2010 18:45:28 -0500 Subject: Possible interaction between the Color manager and Argyllcms Message-ID: <1280187928.2019.36.camel@localhost> 1. I am running Fedora 13. dispwin used directly doesn't seem to do what it did previously. I can use dispwin -I Profile_path to install a profile, but it doesn't persist as it did under previous versions of Fedora (including Fedora 12). But, I can use the gnome color manager to set the display profile, and that does seem topersist. I wonder if the gnome color management is somehow interfering with way argyllcms ordinarily works. 2. In using the color manager to profile a laptop (running Ubuntu 10.4) screen, and using my Eye One Pro, I encountered some problems. The Eye-One Pro has to be calibrated on its base, but the color manager doesn't ask me to do that. In order to get it done, I have to press Details, which brings up the usual argyllcms command line interface. But it is not clear exactly what I am supposed to do using that interface and what using the color manager. If I understood the intended sequence of events, it might be clearer to me how to proceed. Also, the color manager didn't allow me to do any hardware calibration. Of course, for my laptop screen that is somewhat restricted---the only control is screen brightness. I don't know what will happen when I try this an external monitor with lots of controls. Perhaps I am just supposed to continue in the Details window with argyllcms commands? -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Tue Jul 27 08:55:41 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 09:55:41 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280187928.2019.36.camel@localhost> References: <1280187928.2019.36.camel@localhost> Message-ID: On 27 July 2010 00:45, Leonard Evens wrote: > 1. ?I am running Fedora 13. ?dispwin used directly doesn't seem to do > what it did previously. ? I can use dispwin -I Profile_path ?to install > a profile, but it doesn't persist as it did under previous versions of > Fedora (including Fedora 12). ?But, I can use the gnome color manager to > set the display profile, and that does seem topersist. How do you mean persist? dispwin is probably trying to set the gamma tables in xorg, which GPM is also trying to do. If you want to make GCM just leave everything to argyll, just untick the color tickbox in the GNOME session preferences. > I wonder if the gnome color management is somehow interfering with way > argyllcms ordinarily works. As I understand it, dispwin runs, sets some values and then exits. GCM runs gcm-apply at session start, and then also exits. If you run gcm-prefs, the settings probably get re-applied. I think it's probably a good idea to let GCM actually apply the profile, and use argyll to create the profile. If you dump the generated icc profile somewhere GCM knows about, that should work pretty well. > 2. ?In using the color manager to profile a laptop (running Ubuntu 10.4) > screen, and using my Eye One Pro, I encountered some problems. ?The > Eye-One Pro has to be calibrated on its base, but the color manager > doesn't ask me to do that. ?In order to get it done, I have to press > Details, which brings up the usual argyllcms command line interface. > But it is not clear exactly what I am supposed to do using that > interface and what using the color manager. Ideally we can control the hardware using something other than a VTE window. Using a VTE widget sucks as we always have to try and convert the standard output to something localized and sane. Newer, unreleased, versions of argyll allow us to set an environment variable and get some easier to parse values, but there's no support in GCM for that just yet, as we're waiting for a release. It's likely we just have to add another screenscrape section to deal with the "Please insert the device into the dock" type of thing. Screenscaping sucks, but there's not a lot more we can do. If you supply a "gcm-prefs --verbose" trace whilst you're calibrating I can add the required screenscrape bits. I don't have the hardware myself, although donations are always very welcome. > Also, ?the color manager didn't allow me to do any hardware calibration. > Of course, for my laptop screen that is somewhat restricted---the only > control is screen brightness. ?I don't know what will happen when I try > this an external monitor with lots of controls. ?Perhaps I am just > supposed ?to continue in the Details window with argyllcms commands? Do you mean monitors with a programmable LUT? We're aiming to support these kind of things in the next few months. Monitors that allow custom gamma ramps via DDC/CI are also interesting to me, although specs on those are kinda hard to get. Richard. From knizek.confy at volny.cz Tue Jul 27 12:22:14 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Tue, 27 Jul 2010 14:22:14 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: <1280233334.4390.8.camel@localhost> Thanks both Andrew and Richard for trying to help a Fedora newbie :-) Due to dependency hell with GTK+3 on Fedora 13 (trying to build Richard's SRPM), I finally found a way to upgrade to rawhide and did so. Dependencies are not a problem anymore, but compilation of the current GIT fails (I used Andrew's configure options, since strict checking fails much sooner during the compilation): $ ./configure --enable-compile-warnings=yes --disable-sane --disable-strict ...bla bla ... $ make ... bla bla ... Making all in tools make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' CC gcm_dump_profile-gcm-dump-profile.o CCLD gcm-dump-profile ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to `libusb_strerror' collect2: ld returned 1 exit status make[2]: *** [gcm-dump-profile] Error 1 make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' make: *** [all] Error 2 If I recall correctly, something similar appeared with the sources patched by Andrew to compile on Fedora 13. (Even with libusb1.) Any help? P.S. If I do not get further, I may install Fedora 13 x86_64 and try the Andres's binary instead. -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at mit.edu Tue Jul 27 12:35:03 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 27 Jul 2010 08:35:03 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280233334.4390.8.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > Dependencies are not a problem anymore, but compilation of the current > GIT fails (I used Andrew's configure options, since strict checking > fails much sooner during the compilation): > > $ ./configure --enable-compile-warnings=yes --disable-sane > --disable-strict > ...bla bla ... > $ make > ... bla bla ... > > Making all in tools > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > ?CC ? ? gcm_dump_profile-gcm-dump-profile.o > ?CCLD ? gcm-dump-profile > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > `libusb_strerror' > collect2: ld returned 1 exit status > make[2]: *** [gcm-dump-profile] Error 1 > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > make: *** [all] Error 2 > > > If I recall correctly, something similar appeared with the sources > patched by Andrew to compile on Fedora 13. (Even with libusb1.) Yes. One of my patches removed a few calls to libusb_strerror. That function doesn't exist in Fedora's libusb-1.0. --Andy > > Any help? > > P.S. If I do not get further, I may install Fedora 13 x86_64 and try the > Andres's binary instead. > > -- > Milan Knizek > knizek (dot) confy (at) volny (dot) cz > http://www.milan-knizek.net - About linux and photography (Czech > language only) > > From hughsient at gmail.com Wed Jul 28 06:28:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 07:28:38 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280244947.2019.71.camel@localhost> References: <1280187928.2019.36.camel@localhost> <1280244947.2019.71.camel@localhost> Message-ID: On 27 July 2010 16:35, Leonard Evens wrote: > Under argyllcms, dispwin -I ?xxx.icc is supposed to load the table in > xorg, and create a file .config/olor.jcnf which tells where xxx.icc is located. > ... > But, according to Martin at the argyllcms mailing list, if you compile > argyllcms from source, it works as expected. Right, this makes sense. We don't compile the jncf bits in Fedora as it didn't compile with the system version of yajl, which we need to use in Fedora. It might be fairly easy to make argyll use the system version, in which case I think it's okay to turn on the jncf bits. > The way Argyllcms (and the Xrite software under Windows) works, you make > a series of adjustments to the monitor by using "hardware" controls for > Contrast, Brightness, and RGB values. You use them to set white point, > black point, etc. Argyllcms tells you how far off you are from your > target value in either direction. ?If you get these right, then the > calibration LUT loaded into Xorg is minimal and doesn't really change > screen appearance much. ?Is that what you mean by programmable LUT? No, programmable LUT is where you can send a 3D matrix to the monitor and it does most of the color calibration in hardware. You need a pretty nice monitor like an HP DreamColor to be able ot make use of this feature. GCM doesn't ask the user to set contrast and brightness manually, as ideally we can do this automatically using DDC/CI. That's one of the nice features that's on the TODO. Richard. From hughsient at gmail.com Wed Jul 28 09:02:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 10:02:54 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On 27 July 2010 13:35, Andrew Lutomirski wrote: > Yes. ?One of my patches removed a few calls to libusb_strerror. ?That > function doesn't exist in Fedora's libusb-1.0. Can you give master a go please: commit a4dbe5e6ddf6e96f59826537dbbcc542e7fd5fa1 Author: Richard Hughes Date: Wed Jul 28 11:00:22 2010 +0200 Add gcm-compat.h to deal with unreleased versions of libusb :100644 100644 584ca05... de5cc4b... M configure.ac :100644 100644 71b8c89... 4c6c70d... M libcolor-glib/Makefile.am :000000 100644 0000000... 3e30993... A libcolor-glib/gcm-compat.h :100644 100644 c54a0cc... a5991dc... M libcolor-glib/gcm-sensor-huey.c :100644 100644 b5a628f... 043f832... M libcolor-glib/gcm-usb.c :100644 100644 39ab6b2... a96b102... M libcolor-glib/libcolor-glib.h Thanks, Richard. From jyqvklioo at googlemail.com Wed Jul 28 16:28:23 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 18:28:23 +0200 Subject: color managing libraries Message-ID: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Testing LCMS with photo editing showed noticeable color degradation on operations which should show none. I think I discovered why when I read LCMS documentation. LCMS is madness. It puts everything through the so called "sRGB" color space. For those who are not familiar with this color spare, it is designed to represent what CRT monitors show by default with no color management. It has a tiny color gamut and a discontinuity in gamma correction. (2 segments) LCMS needlessly truncates the gamut of any operation (which is not already in the sRGB color space) by converting colors to that color space unconditionally. Please, stop the madness. Do not use LCMS. Indications I saw in writing from the author (not addressed to me) indicate he is not receptive to acknowledging the poor handling his software does. I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? From hughsient at gmail.com Wed Jul 28 16:37:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 18:37:02 +0200 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 28 July 2010 18:28, wrote: > LCMS is madness. Nahh, I think lcms is actually pretty cool. > It puts everything through the so called "sRGB" color space. I don't think that's true at all, can you point to the docs (or code) that says that? > I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? gnome-color-manager already uses argyll for its calibration needs, and lcms for it's internal pixel conversion stuff. Richard. From jyqvklioo at googlemail.com Wed Jul 28 19:23:50 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 21:23:50 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > > I don't think that's true at all, can you point to the docs (or code) > that says that? I sought the text that gave me this impression and did not find it. It has been years since I read whatever it was. Possibly it was related to an image editing application which used LCMS rather than LCMS itself. The application which I saw the impressively bad results in was Krita. I tested where the source and all settable color spaces were not sRGB. From graeme2 at argyllcms.com Wed Jul 28 23:57:05 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 29 Jul 2010 09:57:05 +1000 Subject: color managing libraries In-Reply-To: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> <20100728212350.0cf065e9@jyqvklioo.googlemail.com> Message-ID: <4C50C3D1.6040804@argyllcms.com> jyqvklioo at googlemail.com wrote: > The application which I saw the impressively bad results in was Krita. > I tested where the source and all settable color spaces were not sRGB. Why jump to the conclusion that it's LCMS ? Color management is complicated. Just like the situation when programming, if it doesn't work the way you expect, the most likely explanation is that you've done something wrong. [From my observations on the lcms mailing list, Marti is very responsive to reports of problems.] Graeme Gill. From alexandre.prokoudine at gmail.com Thu Jul 29 00:17:58 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Thu, 29 Jul 2010 04:17:58 +0400 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 7/28/10, jyqvklioo com> wrote: > Testing LCMS with photo editing showed noticeable color degradation on > operations which should show none. > I think I discovered why when I read LCMS documentation. > > LCMS is madness. > > It puts everything through the so called "sRGB" color space. > For those who are not familiar with this color spare, it is designed to > represent what CRT monitors show by default with no color management. > It has a tiny color gamut and a discontinuity in gamma correction. (2 > segments) > LCMS needlessly truncates the gamut of any operation (which is not already > in the sRGB color space) by converting colors to that color space > unconditionally. My dear jyqvklioo (do you work for a throat sweets manufacturer btw? :-)), I have a suspicion that you are confusing back-end with implementation. If Krita passes everything through sRGB, then it is because either it doesn't allow specifying a different working color space or it does allow that, but you didn't do it. LittleCMS has nothing to do with that. However feel free to prove me wrong and quote the bit from LittleCMS's docs that explicitly confirms your opinion. Alexandre Prokoudine http://libregraphicsworld.org From jyqvklioo at googlemail.com Thu Jul 29 06:47:07 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Thu, 29 Jul 2010 08:47:07 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100729084707.2f47845a@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > I don't think that's true at all, ... You do have experience with LCMS so I consider that in my estimation of odds. That combined with the notes I saw about increased accuracy in LCMS 2 and it being largely new code, I am optimistic and looking forward to trying out applications using LCMS, especially LCMS 2. From knizek.confy at volny.cz Sat Jul 31 07:26:25 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sat, 31 Jul 2010 09:26:25 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: <1280561185.4362.6.camel@localhost> Andrew Lutomirski p??e v ?t 27. 07. 2010 v 08:35 -0400: > On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > > > Dependencies are not a problem anymore, but compilation of the current > > GIT fails (I used Andrew's configure options, since strict checking > > fails much sooner during the compilation): > > > > $ ./configure --enable-compile-warnings=yes --disable-sane > > --disable-strict > > ...bla bla ... > > $ make > > ... bla bla ... > > > > Making all in tools > > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > > CC gcm_dump_profile-gcm-dump-profile.o > > CCLD gcm-dump-profile > > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > > `libusb_strerror' > > collect2: ld returned 1 exit status > > make[2]: *** [gcm-dump-profile] Error 1 > > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > > make: *** [all] Error 2 > > > > > > If I recall correctly, something similar appeared with the sources > > patched by Andrew to compile on Fedora 13. (Even with libusb1.) > > Yes. One of my patches removed a few calls to libusb_strerror. That > function doesn't exist in Fedora's libusb-1.0. Hm, I have not noticed that earlier. After applying those referring to libusb_strerror, the compilation failed in a yet later stage, luckily after ./tools/gcm-dump-sensor. Attached is the dump file from Huey sold together with Samsung SyncMaster XL20. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) -------------- next part -------------- // AUTOMATICALLY GENERATED -- DO NOT EDIT generic-dump-version:1 kind:huey vendor:Gretag-Macbeth AG model:Huey serial-number:75951 device:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.1 huey-dump-version:1 unlock-string:GrMb register[0x00]:0x00 register[0x01]:0x01 register[0x02]:0x28 register[0x03]:0xaf register[0x04]:0x3d register[0x05]:0x3a register[0x06]:0x67 register[0x07]:0x67 register[0x08]:0xba register[0x09]:0xc3 register[0x0a]:0x91 register[0x0b]:0x35 register[0x0c]:0x3c register[0x0d]:0x3b register[0x0e]:0x38 register[0x0f]:0x92 register[0x10]:0x3a register[0x11]:0x86 register[0x12]:0x6c register[0x13]:0x57 register[0x14]:0x3c register[0x15]:0xe1 register[0x16]:0xb3 register[0x17]:0x52 register[0x18]:0x39 register[0x19]:0xd0 register[0x1a]:0x39 register[0x1b]:0xd5 register[0x1c]:0xba register[0x1d]:0x68 register[0x1e]:0x40 register[0x1f]:0xbe register[0x20]:0x3a register[0x21]:0xae register[0x22]:0x52 register[0x23]:0x53 register[0x24]:0x3d register[0x25]:0x8f register[0x26]:0x3c register[0x27]:0x20 register[0x28]:0xff register[0x29]:0xff register[0x2a]:0xff register[0x2b]:0xff register[0x2c]:0xff register[0x2d]:0xff register[0x2e]:0xff register[0x2f]:0xff register[0x30]:0xff register[0x31]:0xff register[0x32]:0x45 register[0x33]:0x2b register[0x34]:0xe7 register[0x35]:0x9f register[0x36]:0x3d register[0x37]:0x39 register[0x38]:0x16 register[0x39]:0x8b register[0x3a]:0xbb register[0x3b]:0x12 register[0x3c]:0xed register[0x3d]:0xef register[0x3e]:0x3c register[0x3f]:0x23 register[0x40]:0xe3 register[0x41]:0x36 register[0x42]:0x3a register[0x43]:0x9e register[0x44]:0xef register[0x45]:0x06 register[0x46]:0x3c register[0x47]:0xd6 register[0x48]:0xfa register[0x49]:0x9f register[0x4a]:0x39 register[0x4b]:0xc1 register[0x4c]:0x79 register[0x4d]:0x37 register[0x4e]:0xba register[0x4f]:0x8d register[0x50]:0x39 register[0x51]:0x53 register[0x52]:0x3a register[0x53]:0x81 register[0x54]:0xf4 register[0x55]:0x46 register[0x56]:0x3d register[0x57]:0x8c register[0x58]:0x5c register[0x59]:0xa7 register[0x5a]:0x45 register[0x5b]:0x18 register[0x5c]:0xa5 register[0x5d]:0x90 register[0x5e]:0xff register[0x5f]:0xff register[0x60]:0xff register[0x61]:0xff register[0x62]:0xff register[0x63]:0xff register[0x64]:0xff register[0x65]:0xff register[0x66]:0xff register[0x67]:0x3c register[0x68]:0x98 register[0x69]:0xa8 register[0x6a]:0x9d register[0x6b]:0x3c register[0x6c]:0x65 register[0x6d]:0x60 register[0x6e]:0x41 register[0x6f]:0x3c register[0x70]:0x65 register[0x71]:0x60 register[0x72]:0x41 register[0x73]:0xff register[0x74]:0x09 register[0x75]:0x71 register[0x76]:0x20 register[0x77]:0x05 register[0x78]:0xff register[0x79]:0xff register[0x7a]:0x47 register[0x7b]:0x72 register[0x7c]:0x4d register[0x7d]:0x62 register[0x7e]:0x00 register[0x7f]:0x0e register[0x80]:0x01 register[0x81]:0x99 register[0x82]:0x69 register[0x83]:0x00 register[0x84]:0x02 register[0x85]:0x20 register[0x86]:0xf4 register[0x87]:0xee register[0x88]:0x02 register[0x89]:0x20 register[0x8a]:0xf4 register[0x8b]:0xee register[0x8c]:0x16 register[0x8d]:0xe4 register[0x8e]:0x00 register[0x8f]:0xff register[0x90]:0xff register[0x91]:0xff register[0x92]:0xff register[0x93]:0xff register[0x94]:0x3a register[0x95]:0x99 register[0x96]:0xc8 register[0x97]:0x02 register[0x98]:0xff register[0x99]:0xff register[0x9a]:0xff register[0x9b]:0xff register[0x9c]:0xff register[0x9d]:0xff register[0x9e]:0xff register[0x9f]:0xff register[0xa0]:0xff register[0xa1]:0xff register[0xa2]:0xff register[0xa3]:0xff register[0xa4]:0xff register[0xa5]:0xff register[0xa6]:0xff register[0xa7]:0xff register[0xa8]:0xff register[0xa9]:0xff register[0xaa]:0xff register[0xab]:0xff register[0xac]:0xff register[0xad]:0xff register[0xae]:0xff register[0xaf]:0xff register[0xb0]:0xff register[0xb1]:0xff register[0xb2]:0xff register[0xb3]:0xff register[0xb4]:0xff register[0xb5]:0xff register[0xb6]:0xff register[0xb7]:0xff register[0xb8]:0xff register[0xb9]:0xff register[0xba]:0xff register[0xbb]:0xff register[0xbc]:0xff register[0xbd]:0xff register[0xbe]:0xff register[0xbf]:0xff register[0xc0]:0xff register[0xc1]:0xff register[0xc2]:0xff register[0xc3]:0xff register[0xc4]:0xff register[0xc5]:0xff register[0xc6]:0xff register[0xc7]:0xff register[0xc8]:0xff register[0xc9]:0xff register[0xca]:0xff register[0xcb]:0xff register[0xcc]:0xff register[0xcd]:0xff register[0xce]:0xff register[0xcf]:0xff register[0xd0]:0xff register[0xd1]:0xff register[0xd2]:0xff register[0xd3]:0xff register[0xd4]:0xff register[0xd5]:0xff register[0xd6]:0xff register[0xd7]:0xff register[0xd8]:0xff register[0xd9]:0xff register[0xda]:0xff register[0xdb]:0xff register[0xdc]:0xff register[0xdd]:0xff register[0xde]:0xff register[0xdf]:0xff register[0xe0]:0xff register[0xe1]:0xff register[0xe2]:0xff register[0xe3]:0xff register[0xe4]:0xff register[0xe5]:0xff register[0xe6]:0xff register[0xe7]:0xff register[0xe8]:0xff register[0xe9]:0xff register[0xea]:0xff register[0xeb]:0xff register[0xec]:0xff register[0xed]:0xff register[0xee]:0xff register[0xef]:0xff register[0xf0]:0xff register[0xf1]:0xff register[0xf2]:0xff register[0xf3]:0xff register[0xf4]:0xff register[0xf5]:0xff register[0xf6]:0xff register[0xf7]:0xff register[0xf8]:0xff register[0xf9]:0xff register[0xfa]:0xff register[0xfb]:0xff register[0xfc]:0xff register[0xfd]:0xff register[0xfe]:0xff From hughsient at gmail.com Sat Jul 31 07:52:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 31 Jul 2010 09:52:45 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280561185.4362.6.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> <1280561185.4362.6.camel@localhost> Message-ID: On 31 July 2010 09:26, Milan Kn??ek wrote: > Attached is the dump file from Huey sold together with Samsung > SyncMaster XL20. Great, thanks. I'll analyze your dump and Pascals after I return from GUADEC. Richard. From hughsient at gmail.com Thu Jul 1 08:37:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 09:37:32 +0100 Subject: GNOME Color Manager 2.31.4 Message-ID: gnome-color-manager is a session program that makes it easy to manage, install and generate color profiles in the GNOME desktop. Version 2.31.4 ~~~~~~~~~~~~~~ Released: 2010-07-01 * Translations - Updated Galician translations (Fran Di?guez) - Updated Spanish translation (Jorge Gonz?lez) - Updated Estonian translation (Mattias P?ldaru) - Updated Hebrew translation (Yaron Shahrabani) - Updated Simplified Chinese translation (?? Gan Lu) * New Features: - Port from lcms to lcms2 (Richard Hughes) - Split gcm-prefs into a control center module and a profile viewer (Richard Hughes) - Add gcm_image_set_abstract_profile() so we can set LAB abstract profiles (Richard Hughes) - Add GcmProfileSearchFlags so we can control what kind of profiles are loaded (Richard Hughes) - Allow passing profile and device types to GetProfilesForType() (Richard Hughes) * Bugfix: - Do not try to convert if the input and output profiles are not RGB (Richard Hughes) - Refuse to import a local profile if it already exists system-wide (Richard Hughes) - Make GcmImage take a GcmProfile, not a base64 string (Richard Hughes) - Depend on gnome-control-center 2.31.4 for GTK 3.0 fixes (Richard Hughes) - Ensure we load the profile store in the DBus service (Richard Hughes) Richard. From gysvanzyl at gmail.com Thu Jul 1 15:31:58 2010 From: gysvanzyl at gmail.com (Gys van Zyl) Date: Thu, 1 Jul 2010 18:31:58 +0300 Subject: Color management in ubuntu Message-ID: Hi all, I have a couple of questions that may be a bit silly due to my beginner level knowledge of color management. I'm an amateur/hobby photographer and I've been using ubuntu for a while (currently using 10.04). For a while now I've realized the importance of having a color managed workflow, but have put off getting the hardware as I thought getting everything installed, set up and configured would be tough in linux. I recently purchased a Pantone Huey monitor calibration device and you could imagine my pleasant surprise when I found how extremely easy everything was to use with gnome color manager. In no time, with almost zero effort I had everything up and running. Kudos to the developer(s) - this is excellent software! So, to test how color management works in a browser, I found this web site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. Using google chrome (a non color managed browser) this page is a mess of incorrectly rendered photo's - I expected this. Using Firefox, things are a lot better - imbedded color profiles are now honored and the photos display fine. However, about half-way down the page at the heading "sRGB / Standard RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged sRGB rollover." In my Firefox window, the change is not minor, and I'm trying to figure out why this is. In my workflow all exif data is stripped from my photo's before I upload to the web. I thought that this wouldn't matter, as long as my final image was created in an sRGB colorspace. However, I have now found that my photo's look subtly but definitely different in the software I use (gimp, digikam) and my browsers. My limited understanding of color management led me to believe that un-tagged sRGB images should look the same in a browser on a color-managed system. However, on my system they don't and its causing a problem for me - my photo's don't display the way I intended. How can I resolve this? Is my understanding wrong, should I educate myself a bit more? Did I do something wrong when I calibrated my monitor? Gys -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmjdebruijn at pcode.nl Thu Jul 1 15:58:07 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 17:58:07 +0200 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 5:31 PM, Gys van Zyl wrote: > Hi all, > I have a couple of questions that may be a bit silly due to my beginner > level knowledge of color management. > I'm an?amateur/hobby photographer and?I've been using ubuntu for a while > (currently using 10.04). ?For a while now I've realized the importance of > having a color managed workflow, but have put off getting the hardware as I > thought getting everything installed, set up and configured would be tough > in linux. ?I recently purchased a Pantone Huey monitor calibration device > and you could imagine my pleasant surprise when I found how extremely easy > everything was to use with gnome color manager. ?In no time, with almost > zero effort I had everything up and running. ?Kudos?to the developer(s) - > this is excellent software! GCM + Argyll is a powerful combination indeed :) > So, to test how color management works in a browser, I found this web > site:?http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > ?Using google chrome (a non color managed browser) this page is a mess of > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a > lot better - imbedded color profiles are now honored and the photos display > fine. However, about half-way down the page at the heading "sRGB / Standard > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm > trying to figure out why this is. > In my workflow all exif data is stripped from my photo's before I upload to > the web. ?I thought that this wouldn't matter, as long as my final image was > created in an sRGB colorspace. ?However, I have now found that my photo's > look subtly but definitely different in the software I use (gimp, digikam) > and my browsers. > My limited understanding of color management led me to believe that > un-tagged sRGB images should look the same in a browser on a color-managed > system. ?However, on my system they don't and its causing a problem for me - > my photo's don't display the way I intended. ?How can I resolve this? ?Is my > understanding wrong, should I educate myself a bit more? ?Did I do something > wrong when I calibrated my monitor? The problem is that being color managed, and being properly configured is not always the same... All color managed applications checked for an embedded profile when loading images and will for example convert an Adobe RGB image to sRGB on request. If an image is untagged sRGB will be assumed. However, if you do not properly configure the application to use your display profile it will be displayed as plain srgb without your display profile applied, hence wrong colors (since only the videolut will have effect). I think GIMP doesn't use the system display profile by default. Firefox also requires the display profile to be configured through "about:config" search for "display_profile". Same goes for lots of other applications. So you will still need to check each an every applications configuration. Since they might use poor defaults. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 16:03:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:03:47 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On 1 July 2010 16:58, Pascal de Bruijn wrote: > I think GIMP doesn't use the system display profile by default. > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. Could you start to make to a list of applications and the fixes here please: http://live.gnome.org/GnomeColorManager/FAQ -- I think a list would be really useful for users. Then we can file bugs against the programs to use the GCM DBus interface or the ICCPROFILESINX specification and get things just working by default. As for everything else, I normally tag my "web-safe" with sRGB (it's a tiny increase in size, and probably a good idea) and ensure the display profile has been set correctly. Richard. From marek.matulka at gmail.com Thu Jul 1 16:18:57 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:18:57 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <1278001137.2552.11.camel@localhost> Hello, This is my first post on the group, but I've been following a group for some time. Well done guys for a rocking bit of software giving us a great colour management tool! On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: > > So, to test how color management works in a browser, I found this web > > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > > Using google chrome (a non color managed browser) this page is a mess of > > incorrectly rendered photo's - I expected this. Using Firefox, things are a > > lot better - imbedded color profiles are now honored and the photos display > > fine. However, about half-way down the page at the heading "sRGB / Standard > > RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged > > rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 > > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > > sRGB rollover." In my Firefox window, the change is not minor, and I'm > > trying to figure out why this is. > > In my workflow all exif data is stripped from my photo's before I upload to > > the web. I thought that this wouldn't matter, as long as my final image was > > created in an sRGB colorspace. However, I have now found that my photo's > > look subtly but definitely different in the software I use (gimp, digikam) > > and my browsers. > > My limited understanding of color management led me to believe that > > un-tagged sRGB images should look the same in a browser on a color-managed > > system. However, on my system they don't and its causing a problem for me - > > my photo's don't display the way I intended. How can I resolve this? Is my > > understanding wrong, should I educate myself a bit more? Did I do something > > wrong when I calibrated my monitor? > > The problem is that being color managed, and being properly configured > is not always the same... > > All color managed applications checked for an embedded profile when > loading images and will for example convert an Adobe RGB image to sRGB > on request. If an image is untagged sRGB will be assumed. > > However, if you do not properly configure the application to use your > display profile it will be displayed as plain srgb without your > display profile applied, hence wrong colors (since only the videolut > will have effect). > > I think GIMP doesn't use the system display profile by default. > > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. I had similar issue - when I created three images: 1. tagged with Adobe RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly displayed in GIMP, but not in any desktop viewer. I think the problem lies in assumption, that for untagged images viewer should not apply monitor profile, while it should assume sRGB and convert it accordingly. It seems GIMP is working that way hence all three images are correctly displayed. I have filled a bug report against Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=606996 this bug report includes example screenshots of gimp and eog. Although, I am not sure if my assumptions are right, so please correct me, if I am wrong. Greetings, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 16:27:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:27:39 +0100 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On 1 July 2010 17:18, Marek Matulka wrote: > Although, I am not sure if my assumptions are right, so please correct > me, if I am wrong. I think this functionality needs to live in the toolkit (e.g. GTK) and done automatically, as the harder applications have to work to do the right thing, the fewer that will actually do it. Richard. From marek.matulka at gmail.com Thu Jul 1 16:42:44 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:42:44 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: <1278002564.2552.12.camel@localhost> On Thu, 2010-07-01 at 17:27 +0100, Richard Hughes wrote: > On 1 July 2010 17:18, Marek Matulka wrote: > > Although, I am not sure if my assumptions are right, so please correct > > me, if I am wrong. > > I think this functionality needs to live in the toolkit (e.g. GTK) and > done automatically, as the harder applications have to work to do the > right thing, the fewer that will actually do it. That would be awesome! Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 17:25:52 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:25:52 +0100 Subject: Color management in ubuntu In-Reply-To: <1278002564.2552.12.camel@localhost> References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 17:42, Marek Matulka wrote: > That would be awesome! I've been experimenting with GLSL shaders, and doing the color conversion in hardware on the GPU. We've hit a few stumbing blocks in clutter, but I'm adding API to clutter where required. Using the hardware allows us to do lots of clever interpolation in 3D to make things super sweet. Without using GPU hardware it's quite hard to process high-def video at normal frame rates. Long term this means we can attach a ClutterShader object to different mutter windows and color correct whole windows / subwindows on the GPU. Thatis, unless the application opts out of color managed mode. Or opts in. I'm not sure. There's a net-color-spec that we could use, although this seems very difficult to implement without working on a post-composited display like compiz provides. Either way, unless the ClutterTexture patches get written none of it will work :) Richard. From pmjdebruijn at pcode.nl Thu Jul 1 17:29:17 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:29:17 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: > Hello, > > This is my first post on the group, but I've been following a group for > some time. Well done guys for a rocking bit of software giving us a > great colour management tool! > > On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >> > So, to test how color management works in a browser, I found this web >> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >> > ?Using google chrome (a non color managed browser) this page is a mess of >> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >> > lot better - imbedded color profiles are now honored and the photos display >> > fine. However, about half-way down the page at the heading "sRGB / Standard >> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >> > trying to figure out why this is. >> > In my workflow all exif data is stripped from my photo's before I upload to >> > the web. ?I thought that this wouldn't matter, as long as my final image was >> > created in an sRGB colorspace. ?However, I have now found that my photo's >> > look subtly but definitely different in the software I use (gimp, digikam) >> > and my browsers. >> > My limited understanding of color management led me to believe that >> > un-tagged sRGB images should look the same in a browser on a color-managed >> > system. ?However, on my system they don't and its causing a problem for me - >> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >> > understanding wrong, should I educate myself a bit more? ?Did I do something >> > wrong when I calibrated my monitor? >> >> The problem is that being color managed, and being properly configured >> is not always the same... >> >> All color managed applications checked for an embedded profile when >> loading images and will for example convert an Adobe RGB image to sRGB >> on request. If an image is untagged sRGB will be assumed. >> >> However, if you do not properly configure the application to use your >> display profile it will be displayed as plain srgb without your >> display profile applied, hence wrong colors (since only the videolut >> will have effect). >> >> I think GIMP doesn't use the system display profile by default. >> >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". >> >> Same goes for lots of other applications. So you will still need to >> check each an every applications configuration. Since they might use >> poor defaults. > > I had similar issue - when I created three images: 1. tagged with Adobe > RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly > displayed in GIMP, but not in any desktop viewer. > > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. The tagging of an image has _NOTHING_ to do with applying a display profile or not... If this really is the case, then someone should really be shot for that (not dead... the knees will do just fine :). The application of the display profile (should) only depend on the application settings not on the input image... All programs assume untagged images are sRGB, (even though tagging images with an sRGB profile _is_ a good idea, this will prevent future ambiguity). Programs which aren't color managed (or where color management is disabled) are just RGBin (from file) == RGBout (to display) That said... Please also note that not all forms of sRGB are equal, there are several version of the sRGB profile that might differ a bit... I think at one time there even was a simplified sRGB with a real 2.2 gamma curve... which is wrong, since sRGB is gamma 2.4 with a small dead area in the blacks. Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Thu Jul 1 17:31:02 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:31:02 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:25 PM, Richard Hughes wrote: > On 1 July 2010 17:42, Marek Matulka wrote: >> That would be awesome! > > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. And you need to make the applications aware that they do not need to do their own color management... Otherwise apps like the GIMP might apply an output profile themselves, having the display rgb processed again by the GLSL shaders. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 17:34:17 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:34:17 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:31, Pascal de Bruijn wrote: > And you need to make the applications aware that they do not need to > do their own color management... Otherwise apps like the GIMP might > apply an output profile themselves, having the display rgb processed > again by the GLSL shaders. Right. This is why I think it's going to have to be opt-in. In reality, I think we're a long way from pushing this into a distro. Richard From pmjdebruijn at pcode.nl Thu Jul 1 17:38:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:38:37 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:29 PM, Pascal de Bruijn wrote: > On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: >> Hello, >> >> This is my first post on the group, but I've been following a group for >> some time. Well done guys for a rocking bit of software giving us a >> great colour management tool! >> >> On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >>> > So, to test how color management works in a browser, I found this web >>> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >>> > ?Using google chrome (a non color managed browser) this page is a mess of >>> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >>> > lot better - imbedded color profiles are now honored and the photos display >>> > fine. However, about half-way down the page at the heading "sRGB / Standard >>> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >>> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >>> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >>> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >>> > trying to figure out why this is. >>> > In my workflow all exif data is stripped from my photo's before I upload to >>> > the web. ?I thought that this wouldn't matter, as long as my final image was >>> > created in an sRGB colorspace. ?However, I have now found that my photo's >>> > look subtly but definitely different in the software I use (gimp, digikam) >>> > and my browsers. >>> > My limited understanding of color management led me to believe that >>> > un-tagged sRGB images should look the same in a browser on a color-managed >>> > system. ?However, on my system they don't and its causing a problem for me - >>> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >>> > understanding wrong, should I educate myself a bit more? ?Did I do something >>> > wrong when I calibrated my monitor? >>> >>> The problem is that being color managed, and being properly configured >>> is not always the same... >>> >>> All color managed applications checked for an embedded profile when >>> loading images and will for example convert an Adobe RGB image to sRGB >>> on request. If an image is untagged sRGB will be assumed. >>> >>> However, if you do not properly configure the application to use your >>> display profile it will be displayed as plain srgb without your >>> display profile applied, hence wrong colors (since only the videolut >>> will have effect). >>> >>> I think GIMP doesn't use the system display profile by default. >>> >>> Firefox also requires the display profile to be configured through >>> "about:config" search for "display_profile". >>> >>> Same goes for lots of other applications. So you will still need to >>> check each an every applications configuration. Since they might use >>> poor defaults. >> >> I had similar issue - when I created three images: 1. tagged with Adobe >> RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly >> displayed in GIMP, but not in any desktop viewer. >> >> I think the problem lies in assumption, that for untagged images viewer >> should not apply monitor profile, while it should assume sRGB and >> convert it accordingly. It seems GIMP is working that way hence all >> three images are correctly displayed. > > The tagging of an image has _NOTHING_ to do with applying a display > profile or not... If this really is the case, then someone should > really be shot for that (not dead... the knees will do just fine :). Cutting my own rant short... It's easy for forget (I often do), that color management as a concept is non-obvious for pretty much everybody (including normal coders) who aren't into this stuff... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Thu Jul 1 18:00:09 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 20:00:09 +0200 Subject: Conceptual questions Message-ID: <4C2CD7A9.90409@hoech.org> Hi, I have a few conceptual questions. Currently GCM has preferences for RGB and CMYK working space, and "display" and "softproof" rendering intent. But what I think is missing for softproofing is a checkbox "Simulate media (paper) color" which when checked (which would be a good default), means absolute colorimetric intent should be used, otherwise relative colorimetric (_without_ black point compensation). Is my current understanding of the GCM UI intentions correct as follows: Image -> "display" intent in GCM -> device (for non-softproofing) Image -> "softproof" intent in GCM -> softproof colorspace (is there a way in GCM to choose a default for this?) -> relative without bpc or abscol (it is not clear to me which is used/assumed by GCM by default, I'd think abscol?) -> device Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jul 1 18:23:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 19:23:19 +0100 Subject: Conceptual questions In-Reply-To: <4C2CD7A9.90409@hoech.org> References: <4C2CD7A9.90409@hoech.org> Message-ID: On 1 July 2010 19:00, Florian H?ch wrote: > I think is missing for softproofing is a checkbox "Simulate media (paper) > color" which when checked (which would be a good default), means absolute > colorimetric intent should be used, otherwise relative colorimetric Isn't that a per-application thing, rather than a per-session thing? By "softproof" GCM indicates the proofing mode to use when doing things like print preview. In a print preview aka "softproof" you already know the device you are targeting and the ICC profiles available. I also think it's useful to talk in terms of use-cases, rather than presenting lots of tickyboxes in preferences panels. I've got enough feedback (of the negative kind :-) from my boss about the number of UI elements we expose already. Maybe if we all refer to the three people here http://live.gnome.org/GnomeColorManager#Typical_Users we can all work towards further use-cases and application notes. I do think this is a really important discussion and am really pleased you're onboard. Thanks. Richard. From knizek.confy at volny.cz Thu Jul 1 18:58:16 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 01 Jul 2010 20:58:16 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: <1278010696.9901.3.camel@athlon> Marek Matulka p??e v ?t 01. 07. 2010 v 17:18 +0100: > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. > > I have filled a bug report against Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=606996 > > this bug report includes example screenshots of gimp and eog. > It seems to be a bug like the one reported by me upstream some time ago: https://bugzilla.gnome.org/show_bug.cgi?id=554498 regards, -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From lists+gnome-color-manager at hoech.org Thu Jul 1 19:22:28 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 21:22:28 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> Message-ID: <4C2CEAF4.9030006@hoech.org> Am 01.07.2010 20:23, schrieb Richard Hughes: > On 1 July 2010 19:00, Florian H?ch wrote: >> I think is missing for softproofing is a checkbox "Simulate media (paper) >> color" which when checked (which would be a good default), means absolute >> colorimetric intent should be used, otherwise relative colorimetric > > Isn't that a per-application thing, rather than a per-session thing? > By "softproof" GCM indicates the proofing mode to use when doing > things like print preview. In a print preview aka "softproof" you > already know the device you are targeting and the ICC profiles > available. Ok, sounds reasonable. If the device/profile being simulated is chosen in the application, there's probably no need for GCM to provide settings for a default "softproofing" colorspace. > I also think it's useful to talk in terms of use-cases, rather than > presenting lots of tickyboxes in preferences panels. I've got enough > feedback (of the negative kind :-) from my boss about the number of UI > elements we expose already. Maybe if we all refer to the three people > here http://live.gnome.org/GnomeColorManager#Typical_Users we can all > work towards further use-cases and application notes. :) don't worry, I'm not keen on having a GCM plastered with checkboxes either. Re use cases: My original inquiry would fit in no. #4 ("An application wants to softproof for a printer device to show the user how the colors are going to be clipped when the file is printed"). Now you already said thats probably a per-application thing. I'm just trying to wrap my head around where the current GCM "softproof" intent setting comes into play, what users are choosing with it exactly (like I said, my assuption was it is the image -> device being simulated transform, in which case it makes sense to expose all four intents), and how it interacts/relates to the "display" intent setting (which should then actually be ignored for softproofing by an application). > I do think this is a really important discussion and am really pleased > you're onboard. Thanks. > > Richard. -- Florian H?ch http://hoech.net From jorge.fabregas at gmail.com Fri Jul 2 12:36:50 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Fri, 2 Jul 2010 08:36:50 -0400 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <201007020836.50739.jorge.fabregas@gmail.com> On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". Hello guys, I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary options (gfx.color_management...), restarted Firefox and I still can't see this picture correctly: http://www.color.org/version4html.xalter I see it as if my system only supports "ICC version 2" as the examples shown. I load my ICC profile with "dispwin -L" when my system starts but I'm not sure if its "version 4"? How can I know this? (sorry newbie here when it comes to color management). Thanks, Jorge From pmjdebruijn at pcode.nl Fri Jul 2 12:39:52 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 2 Jul 2010 14:39:52 +0200 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Jorge F?bregas : > On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". > > Hello guys, > > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary > options (gfx.color_management...), restarted Firefox and I still can't see > this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples shown. > I load my ICC profile with "dispwin -L" when my system starts but I'm not sure > if its "version 4"? ?How can I know this? ?(sorry newbie here when it comes to > color management). Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. Firefox 3.5+ uses it's own internal CMS which only processes v2 profiles, but it's faster. Regards, Pascal de Bruijn From marek.matulka at gmail.com Fri Jul 2 12:41:38 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Fri, 02 Jul 2010 13:41:38 +0100 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <1278074498.3005.14.camel@localhost> On Fri, 2010-07-02 at 08:36 -0400, Jorge F?bregas wrote: > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the > necessary options (gfx.color_management...), restarted Firefox and I > still can't see this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples > shown. I load my ICC profile with "dispwin -L" when my system starts > but I'm not sure if its "version 4"? How can I know this? (sorry > newbie here when it comes to color management). AFAIK Firefox does not support version 4 yet. Greetings, Marek From hughsient at gmail.com Fri Jul 2 12:49:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:49:55 +0100 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Pascal de Bruijn : > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? Richard. From hughsient at gmail.com Fri Jul 2 12:58:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:58:55 +0100 Subject: Conceptual questions In-Reply-To: <4C2CEAF4.9030006@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: On 1 July 2010 20:22, Florian H?ch wrote: > Ok, sounds reasonable. If the device/profile being simulated is chosen in > the application, there's probably no need for GCM to provide settings for a > default "softproofing" colorspace. Right. I don't think a "default softproofing device" makes much sense when you're aiming the feature at things like print preview. A "default softproofing device" might make sense as a per-application option if you're proofing to a PDF or something, although that sounds all very application specific. > Now you already said thats probably a per-application thing. I'm just trying > to wrap my head around where the current GCM "softproof" intent setting > comes into play, what users are choosing with it exactly (like I said, my > assuption was it is the image -> device being simulated transform, in which > case it makes sense to expose all four intents), and how it > interacts/relates to the "display" intent setting (which should then > actually be ignored for softproofing by an application). I'm guessing it's just choosing where to put the line. I would argue that asking the user what rendering mode they want to use for a print preview is overboard, as you could just choose a good default and use that. Similarly for rendering random RGB spaces to the desktop, perceptual is probably the best plan. You could argue, the rendering intents should be hardcoded in the application, or just in GSettings/DBus and not in the UI, and I might agree with you. GCM is just trying to find the sweet pot between options-city and not-enough-control-to-be-useful. I still don't mind drastically changing the UI or DBus interface if we need to. If you've got any better ideas about what should be in the UI (BPC?) as a sensible per-session default then I'm interested. You could also argue that dispcalGUI and GCM should be working closer together in this respect, and I'm open for suggestions. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 14:21:29 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 16:21:29 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: <4C2DF5E9.6060203@hoech.org> Am 02.07.2010 14:58, schrieb Richard Hughes: > Right. I don't think a "default softproofing device" makes much sense > when you're aiming the feature at things like print preview. A > "default softproofing device" might make sense as a per-application > option if you're proofing to a PDF or something, although that sounds > all very application specific. I think I agree on this. > I'm guessing it's just choosing where to put the line. I would argue > that asking the user what rendering mode they want to use for a print > preview is overboard, as you could just choose a good default and use > that. Similarly for rendering random RGB spaces to the desktop, > perceptual is probably the best plan. Right. My concern is more if applications (or rather developers) then know to do the "right thing" when they query GCM for the current "softproof" setting to do a print preview, which would be, "convert image with user selected GCM 'softproof' intent to device space, then absolute colorimetrically to the display" - we don't want gamut mapping to happen twice, that would invalidate the print preview. Of course matrix profiles only support colorimetric either way. Still, it's something to keep in mind. > If you've got any better ideas about what should be in the UI (BPC?) > as a sensible per-session default then I'm interested. You could also > argue that dispcalGUI and GCM should be working closer together in > this respect, and I'm open for suggestions. Personally I'd probably label the current "softproof" intent setting as "print preview" or something along the line. And I think adding an option for BPC would indeed be a nice touch. Rather than adding a checkbox or other additional control, just another intent "Relative with black point compensation" could be added to the dropdown lists. Re making dispcalGUI and GCM work closer together: Sure, it's an option. I wouldn't limit it to dispcalGUI though as other screen calibration/profiling solutions may exist in future (I hear LProf was/is planning to have a measurement capability, but I have to admit I'm not really well informed in that regard). Some wild thinking: Users can already choose their preferred applications for different filetypes/tasks. Maybe in the future, users can choose the preferred calibration solution in a similar way? Although right now, it's probably over the top, as only dispcalGUI and GCM exist as viable options afaik :) (and of course, directly using the Argyll tools on the commandline) Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 14:56:18 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 15:56:18 +0100 Subject: Conceptual questions In-Reply-To: <4C2DF5E9.6060203@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: On 2 July 2010 15:21, Florian H?ch wrote: > Personally I'd probably label the current "softproof" intent setting as > "print preview" or something along the line. Yes, good idea, I've done this in git master. > And I think adding an option for BPC would indeed be a nice touch. Rather > than adding a checkbox or other additional control, just another intent > "Relative with black point compensation" could be added to the dropdown > lists. Do we every want to do relative /without/ BPC? > Some wild thinking: Users can already choose their preferred > applications for different filetypes/tasks. Maybe in the future, users can > choose the preferred calibration solution in a similar way? Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and GcmCalibrateManual, and it would be pretty easy to make that pluggable using GIO extension points. One for the future perhaps. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 15:07:33 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 17:07:33 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: <4C2E00B5.80403@hoech.org> Am 02.07.2010 16:56, schrieb Richard Hughes: > On 2 July 2010 15:21, Florian H?ch wrote: >> Personally I'd probably label the current "softproof" intent setting as >> "print preview" or something along the line. > > Yes, good idea, I've done this in git master. Nice! >> And I think adding an option for BPC would indeed be a nice touch. Rather >> than adding a checkbox or other additional control, just another intent >> "Relative with black point compensation" could be added to the dropdown >> lists. > > Do we every want to do relative /without/ BPC? For proofing, without BPC is a must of course. But for image -> arbitrary display/output space, defaulting to BPC "on" for relative colorimetric seems to be the right choice (and will surely avoid some "why are my blacks crushed" cries from users :)). >> Some wild thinking: Users can already choose their preferred >> applications for different filetypes/tasks. Maybe in the future, users can >> choose the preferred calibration solution in a similar way? > > Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and > GcmCalibrateManual, and it would be pretty easy to make that pluggable > using GIO extension points. One for the future perhaps. Cool. I agree it's still a bit early. > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 15:26:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 16:26:11 +0100 Subject: Conceptual questions In-Reply-To: <4C2E00B5.80403@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: On 2 July 2010 16:07, Florian H?ch wrote: > For proofing, without BPC is a must of course. But for image -> arbitrary > display/output space, defaulting to BPC "on" for relative colorimetric seems > to be the right choice (and will surely avoid some "why are my blacks > crushed" cries from users :)). So, for 'Print Preview' these make sense: perceptual relative-colormetric relative-colormetric-bpc saturation absolute-colormetric and for 'Display': perceptual relative-colormetric saturation absolute-colormetric I'm not completely sure of all the nuances of BPC myself, so I would certainly appreciate any pointers and corrections. Thanks. Richard From lists+gnome-color-manager at hoech.org Fri Jul 2 16:10:36 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 18:10:36 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: <4C2E0F7C.4010202@hoech.org> Am 02.07.2010 17:26, schrieb Richard Hughes: > On 2 July 2010 16:07, Florian H?ch wrote: >> For proofing, without BPC is a must of course. But for image -> arbitrary >> display/output space, defaulting to BPC "on" for relative colorimetric seems >> to be the right choice (and will surely avoid some "why are my blacks >> crushed" cries from users :)). > > So, for 'Print Preview' these make sense: > > perceptual > relative-colormetric > relative-colormetric-bpc > saturation > absolute-colormetric > > and for 'Display': > > perceptual > relative-colormetric > saturation > absolute-colormetric > > I'm not completely sure of all the nuances of BPC myself, so I would > certainly appreciate any pointers and corrections. Thanks. Actually, for both print preview and display BPC can make sense, it all depends on the combinations involved (always assuming the print preview intent is for the image -> simulated device transform, not the simulated device -> display transform). The key is when print preview is used, the transform to the display must not use BPC (or perceptual/saturation). But when print preview is not used, then BPC makes a lot of sense for display imho, to avoid crushed blacks (e.g. conversion from a working space like AdobeRGB with 'zero' blackpoint to a display profile with 'lighter' blackpoint). I hope I'm making sense. -- Florian H?ch http://hoech.net From graeme2 at argyllcms.com Sat Jul 3 02:11:43 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Sat, 03 Jul 2010 12:11:43 +1000 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <4C2E9C5F.3080208@argyllcms.com> Richard Hughes wrote: > Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? You can always try and talk sense into them, but it seemed a wild decision to begin with, and therefore much harder to back down from.. [I doubt that the Firefox CMM is faster than a GPU. It may not even be faster than Argyll's cctiff/imdi, in spite of them using assembler.] Graeme Gill. From jorge.fabregas at gmail.com Sat Jul 3 13:59:42 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Sat, 3 Jul 2010 09:59:42 -0400 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <201007030959.43042.jorge.fabregas@gmail.com> On Friday 02 July 2010 08:39:52 Pascal de Bruijn wrote: > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. I see. Thanks Pascal! All the best, Jorge From hughsient at gmail.com Mon Jul 5 16:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 5 Jul 2010 17:44:10 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:25, Richard Hughes wrote: > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. Thanks to Neil Roberts who has added the required 3D texture support to clutter, I've got a mutter tree on my system that does full screen color management with a simple shader on the GPU. I've also added some demo code to GCM, although it's a standalone program and needs the cogl-texture-3d branch of clutter installed to even compile. Now, I have to fix the remaining bugs in mutter to enable this stuff, and then we have to work out how to mask bits of windows that are already color managed. Net color spec already exists, but isn't very friendly to a composited desktop that isn't compiz, i.e. not rendering to a flat rectangle of pixels. It's also not very toolkit friendly. Richard. From jorge.fabregas at gmail.com Tue Jul 6 12:58:56 2010 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Tue, 6 Jul 2010 08:58:56 -0400 Subject: Wallpaper & Icons on GNOME Desktop Message-ID: <201007060858.56709.jorge.fabregas@gmail.com> Hello everyone, I'm just curious: If you use Gnome Color Manager to create/use/load your ICC monitor profile... Will the GNOME desktop itself take into consideration the monitor profile so that I can render the icons & wallpaper accordingly? Thanks, Jorge From pmjdebruijn at pcode.nl Tue Jul 6 15:26:15 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 6 Jul 2010 17:26:15 +0200 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: <201007060858.56709.jorge.fabregas@gmail.com> References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: 2010/7/6 Jorge F?bregas : > Hello everyone, > > I'm just curious: If you use Gnome Color Manager to create/use/load your ICC > monitor profile... Will the GNOME ?desktop itself ?take into consideration the > monitor profile so that I can render the icons & wallpaper accordingly? Nope... Only specific applications are fully color managed (GIMP, Inkscape, F-Spot, Darktable, UFRaw)... Though a good display profile consist of two part: - VideoLUT which is mostly white point correction and gamma correction - XYZ Matrix which is color correction The VideoLUT is applied by the video driver, so everything benefits from this... The XYZ Matrix is only used by color managed applications which are properly configured... For example GIMP has this disabled by default, it can easily be enabled from it's Preferences. Regards, Pascal de Bruijn From jorge.fabregas at gmail.com Thu Jul 8 02:30:11 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Wed, 7 Jul 2010 22:30:11 -0400 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: <201007072230.12136.jorge.fabregas@gmail.com> On Tuesday 06 July 2010 11:26:15 Pascal de Bruijn wrote: > Nope... Only specific applications are fully color managed (GIMP, > Inkscape, F-Spot, Darktable, UFRaw)... Ok. > Though a good display profile consist of two part: > > - VideoLUT which is mostly white point correction and gamma correction > - XYZ Matrix which is color correction Yes, I had to read many articles about the difference between monitor calibration and profiling (and how many people new to CMS confuse both). > The VideoLUT is applied by the video driver, so everything benefits from > this... I see. I get it now. And indeed I notice a BIG difference on my overall desktop when I load the ICC profile. The change on visual appearance of my screen - when the calibration-part gets loaded (gamma & white-point correction) - is considerably higher than the changes made when a color-managed app takes into consideration the profile part (color correction). > The XYZ Matrix is only used by color managed applications which are > properly configured... I see, so the GNOME desktop (and practically anything X-related) takes advantage of the information stored on the VideoLUT but I won't see anything color-corrected (from the profiling part of the ICC) until a capable app is configured to do so. Thank you very much Pascal ! I really appreciate your help. All the best, Jorge From alexandre.prokoudine at gmail.com Thu Jul 15 23:46:59 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Fri, 16 Jul 2010 03:46:59 +0400 Subject: gcm not working for second logged in user Message-ID: Hi, It was reported earlier on IRC that g-c-m doesn't work for the second logged in user -- the applet starts and then closes itself. The user who reported that moved from 2.31.1 back to 2.30.0(-0ubuntu3) and still experiences the issue. Here is the current log, for 2.30: http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 11:34:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 12:34:24 +0100 Subject: libcolor-glib Message-ID: I've just merged a pretty big branch into GCM git master. libcolor-glib is a new library to be used pretty much exclusively by GCM. It's not designed to be used by end-user-applications like gimp and darktable, but instead just by gnome-color-manager and any additional tools that ISV's want to build. End user applications should continue to use the DBus interface which has not changed. libcolor-glib is starting to grow in functionality, and some of the core new pieces are: * Userspace DDC control, so we can control things like the HP DreamColor monitors and upload custom color spaces. * In-process colorimeter reading. The last point is interesting. I wanted to put the calibration routines in process, so we can get rid of that crappy VTE window, output scraping and all the popups from that. It would also allow us to do ambient lighting control like the windows tools do. This would however mean using argyll as a library (which it isn't) and also using argyll "headless", i.e. without a VTE. Argyll doesn't work very well without a console attached to it. Argyll is also AGPLv3, so can't be run in process with a GPLv2+ program. So, I've spent a couple of evenings reverse engineering the HUEY device. I needed a MIT licensed version of this code for another project I'm working on, and so including it in GCM as LGPLv2+ seemed obvious. The GcmSensorHuey object kinda works now, although I've made some very large guesses and approximations, and the XYZ color only *just* bears some resemblance to reality. The ambient light sensor does however work reliably, although I had to work out a fudge factor using my ColorMunki, so isn't exactly precise. If you know anything technical about the hardware, I'm all ears. So, for the next release if you're using a Huey and gcm-picker, you get the GCM in-process native driver. Anything else (including the ColorMunki) you get to use argyll like normal. Calibration is still always done with argyll, as generating a ICC profile is a little more involved that just getting a few XYZ values. So, a few Q&A's: Q: Do I intend on making other native drivers for other hardware A: No, as I don't have the hardware. I might make bits of the ColorMunki work like the ambient light sensor, although I'm having problems getting traces from the windows driver. Q: Are the GcmSensorHuey values accurate? A: No. If we know a bit more about the hardware we can reduce the amount of futzing and bodging we do. When my head recovers (reverse engineering is hard...) I'll take a look and see if we're doing anything batshit insane. Q: Can we help by copying the logic out of the decompiled windows driver or from Argyll. A: No. Don't even look at other source code if you want to contribute code as LGPLv2+. Note: it's okay to strace argyll commands, or to record the windows driver usb traffic, and this is what I've been doing. Q: Are you working on a sekret project? A: No. I'm putting a few technical demos together, but nothing sekret. Q: Are you aiming to replace Argyll. A: No. Argyll is a mature project that works really well and is a complete calibration workflow. GCM is a new project that does very limited things. Questions ahoy! :-) Richard. From alexandre.prokoudine at gmail.com Mon Jul 19 11:48:11 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 19 Jul 2010 15:48:11 +0400 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 7/19/10, Richard Hughes wrote: > libcolor-glib is starting to grow in functionality, and some of the > core new pieces are: > > * Userspace DDC control, so we can control things like the HP > DreamColor monitors and upload custom color spaces. > * In-process colorimeter reading. Tell me, are you up to Nobel prize this year? :) That sounds awesome! But I demand details about DDC :) Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 12:33:08 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:33:08 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 12:48, Alexandre Prokoudine wrote: > Tell me, are you up to Nobel prize this year? :) No, but I'm doing a talk at GUADEC and want to show some impressive demos. > That sounds awesome! But I demand details about DDC :) Right. Most of the core DDC logic belongs in the kernel, but a few of the device specific controls probably belong in userspace. The DreamColor display (which I'm hoping will arrive really soon now) will allow us to test and use a 30bit LUT in Xorg, and display wide gamut images. We need to use DDC controls to talk to the engine in the display, and I'm also waiting for more detailed specs to come out of HP. For what it's worth, HP have been very helpful indeed. A lot of the stuff I've been working on recently (GLSL hardware shaders, libcolor-glib) allows us to build a framework that's acceptable to the big-name studios, and keeping to the "just works" GNOME mantra. There's still a lot of work to do, but it's coming on fast now. I would really appreciate any help with the hardware parts, as a color sensor giving "kinda approximate" XYZ values isn't particularly useful. Richard. From pmjdebruijn at pcode.nl Mon Jul 19 12:41:51 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 19 Jul 2010 14:41:51 +0200 Subject: libcolor-glib In-Reply-To: References: Message-ID: On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: > On 19 July 2010 12:48, Alexandre Prokoudine > wrote: >> Tell me, are you up to Nobel prize this year? :) > > No, but I'm doing a talk at GUADEC and want to show some impressive demos. Well it all sounds pretty kick ass... But uh... so you'll be in the Netherlands? 26-30th? Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jul 19 12:53:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:53:21 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 13:41, Pascal de Bruijn wrote: > On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: >> On 19 July 2010 12:48, Alexandre Prokoudine >> wrote: >>> Tell me, are you up to Nobel prize this year? :) >> >> No, but I'm doing a talk at GUADEC and want to show some impressive demos. > > Well it all sounds pretty kick ass... > But uh... so you'll be in the Netherlands? 26-30th? I'll be in the Hague from 24th to the 31st. It would be good to grab a beer or seven. Richard. From hughsient at gmail.com Tue Jul 20 09:00:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 10:00:10 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 16 July 2010 00:46, Alexandre Prokoudine wrote: > http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 I've just fixed this, you want to apply dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Thanks, Richard. From alexandre.prokoudine at gmail.com Tue Jul 20 09:42:52 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Tue, 20 Jul 2010 13:42:52 +0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 7/20/10, Richard Hughes wrote: > On 16 July 2010 00:46, Alexandre Prokoudine > wrote: >> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 > > I've just fixed this, you want to apply > dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Many thanks! Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Tue Jul 20 12:03:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 13:03:56 +0100 Subject: GUADEC Message-ID: I've just finished writing my slides[1] for GUADEC. I'm presenting on the Friday afternoon, see http://www.guadec.org/index.php/guadec/2010/schedConf/program for details. I'm going to be there for the full week. If you grab me at GUADEC, be sure to introduce yourself as I'm really bad with names and faces. :-) Hopefully see some of you there! Richard. [1] I say "writing", but it's mostly all pictures and diagrams... From luto at mit.edu Tue Jul 20 19:06:51 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 20 Jul 2010 15:06:51 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: I have a Dell U2711, which has 10 bits per channel over DisplayPort (although I'm not sure that anything other than i915 can drive 10 bits right now, and even i915 needs bleeding-edge drivers). Can GCM program a 10-bit video card LUT? Also, the U2711 has an internal LUT, although no one seems to know how to program it (even on Windows) or even whether it can be programmed with anything other than a (not-very-good) factory calibration. Richard, did your libcolor-glib work give you any ideas for how to test for DDC control of a LUT on an unknown monitor? I'd be happy to test and fiddle. --Andy From pmjdebruijn at pcode.nl Tue Jul 20 21:58:32 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 20 Jul 2010 23:58:32 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 11:42 AM, Alexandre Prokoudine wrote: > On 7/20/10, Richard Hughes wrote: >> On 16 July 2010 00:46, Alexandre Prokoudine >> wrote: >>> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 >> >> I've just fixed this, you want to apply >> dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x I applied that patch to my 2.31.1 package too... However, I'm still curious then... User 1 logs in: gcm-prefs loads videolut gcm-prefs sets profile atom for user 1 User 2 logs in gcm-prefs loads videolut (from a different profile) gcm-prefs sets profile atom for user 2 User 1 switches back... Won't user 1 now end up the the video lut of the profile of user 2, but still have his own profile's atom set? This obviously won't be a problem if both users use the same profile... Regards, Pascal de Bruijn From hughsient at gmail.com Wed Jul 21 08:26:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:26:38 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 20 July 2010 22:58, Pascal de Bruijn wrote: > User 2 logs in > gcm-prefs loads videolut (from a different profile) > gcm-prefs sets profile atom for user 2 Yes, this is a valid bug. We probably should get our GSD plugin to watch for ConsoleKit changes (the ACTIVE attribute) but really this needs some proper session support. I really don't want to add yet another session process just watching for a session active state change. Better ideas welcome. Richard. From hughsient at gmail.com Wed Jul 21 08:32:50 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:32:50 +0100 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). ?Can GCM > program a 10-bit video card LUT? In theory, yes. I've made the GcmClut object generate the amount of data for each LUT size, but I admit I've never tested it on anything other than 8 bpp. > Also, the U2711 has an internal LUT, although no one seems to know how > to program it (even on Windows) or even whether it can be programmed > with anything other than a (not-very-good) factory calibration. > Richard, did your libcolor-glib work give you any ideas for how to > test for DDC control of a LUT on an unknown monitor? ?I'd be happy to > test and fiddle. Yes. I'm still waiting for me DreamColor monitor to arrive, and that allows a custom colorspace to be uploaded. For your monitor, you probably need to convince the manufacturer to give you the specs, or find a windows tool that calibrates the monitor and then trace that. You always have to be a little but careful sending hardware random data to reverse engineer it. First, the output of "gcm-ddc-util --enumerate" should give us something to work on. Richard. From luto at mit.edu Wed Jul 21 21:09:39 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Wed, 21 Jul 2010 17:09:39 -0400 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 4:32 AM, Richard Hughes wrote: > On 20 July 2010 20:06, Andrew Lutomirski wrote: >> I have a Dell U2711, which has 10 bits per channel over DisplayPort >> (although I'm not sure that anything other than i915 can drive 10 bits >> right now, and even i915 needs bleeding-edge drivers). ?Can GCM >> program a 10-bit video card LUT? > > In theory, yes. I've made the GcmClut object generate the amount of > data for each LUT size, but I admit I've never tested it on anything > other than 8 bpp. > >> Also, the U2711 has an internal LUT, although no one seems to know how >> to program it (even on Windows) or even whether it can be programmed >> with anything other than a (not-very-good) factory calibration. >> Richard, did your libcolor-glib work give you any ideas for how to >> test for DDC control of a LUT on an unknown monitor? ?I'd be happy to >> test and fiddle. > > Yes. I'm still waiting for me DreamColor monitor to arrive, and that > allows a custom colorspace to be uploaded. For your monitor, you > probably need to convince the manufacturer to give you the specs, or > find a windows tool that calibrates the monitor and then trace that. > > You always have to be a little but careful sending hardware random > data to reverse engineer it. First, the output of "gcm-ddc-util > --enumerate" should give us something to work on. gcm-dump-edid says: Monitor name: DELL U2711 Vendor name: Dell Serial number: D971T0471EFL PNP identifier: DEL Size: 60x34 Gamma: 2.200000 gcm-ddc-util --enumerate says: $ sudo ./gcm-ddc-util --enumerate EDID: f3b71e4fd0bf14ac3db509cbc4ba48ba PNPID: DELA055 Model: U2711 0x02 [secondary-degauss] 0x04 [reset-factory-defaults] 0x05 [reset-brightness-and-contrast] 0x06 [reset-factory-geometry] 0x08 [reset-factory-default-color] 0x10 [brightness] 0x12 [contrast] 0x14 [select-color-preset] ( 1 5 8 0 0 ) 0x16 [red-video-gain] 0x18 [green-video-gain] 0x1a [blue-video-gain] 0x52 [saturation] 0x60 [input-source-select] ( 1 3 4 5 0 0 11 ) 0xac [horizontal-frequency] 0xae [vertical-frequency] 0xb2 [unknown] 0xb6 [unknown] 0xc6 [unknown] 0xc8 [unknown] 0xc9 [firmware-version] 0xd6 [dpms-control-(1---on/4---stby)] ( 1 4 5 ) 0xdc [magicbright-(1---text/2---internet/3---entertain/4---custom)] ( 0 2 3 4 5 ) 0xdf [vcp-version] 0xfd [power-led] --control 0xb2 --get doesn't seem to work. This is also suspicious: $ sudo ./gcm-ddc-util --display f3b71e4fd0bf14ac3db509cbc4ba48ba --control vcp-version --get vcp-version is 513, max is 255 I'm not really sure what I'm looking for, though, and I haven't spotted the DreamColor code. (Is it there?) --Andy > > Richard. > From alexdeucher at gmail.com Thu Jul 22 04:12:46 2010 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 22 Jul 2010 00:12:46 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). Can GCM > program a 10-bit video card LUT? FWIW, all radeons (even the original r100) support 10 bit LUTs. Alex From graeme2 at argyllcms.com Thu Jul 22 04:59:52 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 22 Jul 2010 14:59:52 +1000 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: <4C47D048.70702@argyllcms.com> Alex Deucher wrote: > FWIW, all radeons (even the original r100) support 10 bit LUTs. My Nvidia 8600GT has 10 bit LUTs & D/A converters to VGA. I'd imagine that the digital path to the display is only 8 bit though.. Graeme Gill. From hughsient at gmail.com Thu Jul 22 09:16:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 10:16:40 +0100 Subject: Anyone got a huey? Message-ID: Have any of you got a huey and a few minutes? I want to do some comparisons between two dumps to try to find differences and to help reverse engineer it. Yell if you can help. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 10:00:11 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 12:00:11 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: > Have any of you got a huey and a few minutes? I want to do some > comparisons between two dumps to try to find differences and to help > reverse engineer it. Yell if you can help. Got One... What do I need to do? I can get back to you tonight... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 11:45:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 12:45:10 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 11:00, Pascal de Bruijn wrote: > On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >> Have any of you got a huey and a few minutes? I want to do some >> comparisons between two dumps to try to find differences and to help >> reverse engineer it. Yell if you can help. > > Got One... > > What do I need to do? * Build GCM git master from today * Insert the HUEY * ./tools/gcm-dump-sensor * Send me offlist the sensor-dump.txt file it produces. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 13:02:30 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 15:02:30 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:45 PM, Richard Hughes wrote: > On 22 July 2010 11:00, Pascal de Bruijn wrote: >> On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >>> Have any of you got a huey and a few minutes? I want to do some >>> comparisons between two dumps to try to find differences and to help >>> reverse engineer it. Yell if you can help. >> >> Got One... >> >> What do I need to do? > > * Build GCM git master from today > * Insert the HUEY > * ./tools/gcm-dump-sensor > * Send me offlist the sensor-dump.txt file it produces. Would that build on GNOME 2.30.x? Maybe I could try an alpha live cd of sorts, I'll try to work something out... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 13:15:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 14:15:54 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 14:02, Pascal de Bruijn wrote: > Would that build on GNOME 2.30.x? No way. Although, you could probably hack up configure to lower the deps and then _only_ build libcolor-glib and the tools. That might work. > Maybe I could try an alpha live cd of sorts, I'll try to work something out... Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds and then installing http://people.freedesktop.org/~hughsient/fedora/13/i386/ should probably work. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 16:30:47 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 18:30:47 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 3:15 PM, Richard Hughes wrote: > On 22 July 2010 14:02, Pascal de Bruijn wrote: >> Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > >> Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds > and then installing > http://people.freedesktop.org/~hughsient/fedora/13/i386/ should > probably work. Well, I got a whole lot of won't boot :) I could bring the Huey with me next Friday to GUADEC so you can check it out yourself? Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 16:53:46 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 17:53:46 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 17:30, Pascal de Bruijn wrote: > I got a whole lot of won't boot :) Hah! Welcome to rawhide ;-) > I could bring the Huey with me next Friday to GUADEC so you can check > it out yourself? That would be good, thanks. It only takes about 2 seconds to dump all the registers. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 17:11:55 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 19:11:55 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: > On 20 July 2010 22:58, Pascal de Bruijn wrote: >> User 2 logs in >> gcm-prefs loads videolut (from a different profile) >> gcm-prefs sets profile atom for user 2 > > Yes, this is a valid bug. We probably should get our GSD plugin to > watch for ConsoleKit changes (the ACTIVE attribute) but really this > needs some proper session support. I really don't want to add yet > another session process just watching for a session active state > change. Well it's a very rare use case tho... Since screen calibration is inherently a system properly and not really a user thing... It could become a user thing when two users disagree on what gamma/white point should be profiled against... But then again, there isn't that much debate about this, and even so, a single shop will standardize to a single setting... Though technically it's a bug that could be hit and produce some really funky shit :) Regards, Pascal de Bruijn From andy at luto.us Thu Jul 22 17:40:11 2010 From: andy at luto.us (Andrew Lutomirski) Date: Thu, 22 Jul 2010 13:40:11 -0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: > On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>> User 2 logs in >>> gcm-prefs loads videolut (from a different profile) >>> gcm-prefs sets profile atom for user 2 >> >> Yes, this is a valid bug. We probably should get our GSD plugin to >> watch for ConsoleKit changes (the ACTIVE attribute) but really this >> needs some proper session support. I really don't want to add yet >> another session process just watching for a session active state >> change. > > Well it's a very rare use case tho... > > Since screen calibration is inherently a system properly and not > really a user thing... I disagree. Profiling the monitor is inherently a system thing (presumably it's the *same* monitor for all users). The LUT setting is a different story. One user might want 6500K, another might want 7000K, and a third might want no correction at all for maximum 3D gamut because they know that whatever program they care about is already using a CLUT profile. A fourth user might run dispwin -c themselves and the first user might want their calibration back when they switch back. (Of course, the profile to use depends on the LUT, but that's "just" an implementation detail.) > > It could become a user thing when two users disagree on what > gamma/white point should be profiled against... But then again, there > isn't that much debate about this, and even so, a single shop will > standardize to a single setting... You should get a Lenovo X series laptop. I had to calibrate mine to 6000K because the screen is *so* bad that I lose an annoying amount of brightness and get rather crappy results if I calibrate to anything else. (Last I checked, the calibration GUI doesn't have that setting, so I just did it manually with dispcal.) But I'm not sure there's a problem at all. Don't the two users have their own X servers, and shouldn't the X server restore the LUT on its own? (I *think* that drv-intel 2.9.0 or newer with recent xserver is smart enough.) --Andy From len at math.northwestern.edu Fri Jul 23 15:58:21 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Fri, 23 Jul 2010 10:58:21 -0500 Subject: Fedora version Message-ID: <1279900701.7721.14.camel@localhost> I would liked to try out gnome color management. I am currently using Fedora 12, but I can if necessary upgrade to Fedora 13. I understand that it will be available as a Fedora 14 package, but I wonder if a package is available I could try before that. I can if necessary compile it from source, but that is usually time consuming and requires searching for additional packages. I have used Argyllcms with an Eye One Pro to calibrate/profile my monitor and my printer. Gimp, firefox, and inkscape can use the monitor profile, but there are some difficulties with other applications such as eye of gnome. I've been printing by a complicated method using argyllcms and photoprint. I was hoping an integrated gnome package might allow me to deal with such matters in a straightforward manner. Can you suggest anything to help? P.S. I do have Ubuntu on a laptop, but working from there would be a bit awkward. -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Fri Jul 23 16:12:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Jul 2010 17:12:16 +0100 Subject: Fedora version In-Reply-To: <1279900701.7721.14.camel@localhost> References: <1279900701.7721.14.camel@localhost> Message-ID: On 23 July 2010 16:58, Leonard Evens wrote: > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > 13. ?I understand that it will be available as a Fedora 14 package, but > I wonder if a package is available I could try before that. Just update to fedora 13. It's included by default. Richard. From marek at matulka.net Fri Jul 23 16:22:23 2010 From: marek at matulka.net (Marek Matulka) Date: Fri, 23 Jul 2010 17:22:23 +0100 Subject: Fedora version In-Reply-To: References: <1279900701.7721.14.camel@localhost> Message-ID: <1279902143.2667.32.camel@localhost> On Fri, 2010-07-23 at 17:12 +0100, Richard Hughes wrote: > On 23 July 2010 16:58, Leonard Evens wrote: > > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > > 13. I understand that it will be available as a Fedora 14 package, but > > I wonder if a package is available I could try before that. > > Just update to fedora 13. It's included by default. how do I get a ?calibrate? functionality? I have a Fedora 13 installed, with argyllcms and all required packages, I can do calibration manually from the command line, but not through gnome-color-management package... I use Spyder 2. Thanks, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From knizek.confy at volny.cz Sun Jul 25 06:29:02 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sun, 25 Jul 2010 08:29:02 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: <1280039342.4370.22.camel@localhost> Richard Hughes p??e v ?t 22. 07. 2010 v 14:15 +0100: > On 22 July 2010 14:02, Pascal de Bruijn wrote: > > Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > > > Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds It does not boot for me either (cannot mount /dev/mapper/live-rw filesystem), I may try in a week time again. BTW, I have got a huey, which was delivered with wide-gamut Samsung XL20. There was a discussion on argyllcms list whether it is somehow modified or not compared to a standard huey. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Sun Jul 25 13:21:15 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 25 Jul 2010 14:21:15 +0100 Subject: Anyone got a huey? In-Reply-To: <1280039342.4370.22.camel@localhost> References: <1280039342.4370.22.camel@localhost> Message-ID: On 25 July 2010 07:29, Milan Kn??ek wrote: > There was a discussion on argyllcms list whether it is somehow > modified or not compared to a standard huey. I would be very interested in the dump, although I know GCM is kinda hard to install at the moment. Richard. From amluto at gmail.com Sun Jul 25 13:35:50 2010 From: amluto at gmail.com (Andy Lutomirski) Date: Sun, 25 Jul 2010 09:35:50 -0400 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: I'll send the patch I used later on. It's enough to build libcolor-glib (sans gcm-brightness) and the tools. --Andy On Jul 25, 2010, at 9:21 AM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list From knizek.confy at volny.cz Mon Jul 26 07:55:12 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 09:55:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: <1280130912.5411.3.camel@localhost> Richard Hughes p??e v Ne 25. 07. 2010 v 14:21 +0100: > On 25 July 2010 07:29, Milan Kn??ek wrote: > > There was a discussion on argyllcms list whether it is somehow > > modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Would it help to install Fedora 13 and compile on it? Or install Fedora 13 and upgrade to current development version ("rawhide" - is there a howto?)? P.S. I am used to Archlinux and Ubuntu, hence sorry for beginner's questions. regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at MIT.EDU Mon Jul 26 14:41:36 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:41:36 -0400 Subject: [PATCH] Make -Werror command-line configurable Message-ID: <1280155296-1270-1-git-send-email-luto@mit.edu> -Werror is already enabled by --enable-strict (default) and GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do that and don't hardcode it. --- Hi all- This is my first of two patches for building libcolor-glib on F13. This one is probable suitable for the real tree. The second one is way too hackish. --Andy configure.ac | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d34767d..7572ee1 100644 --- a/configure.ac +++ b/configure.ac @@ -51,7 +51,7 @@ LT_INIT AM_PROG_CC_C_O IT_PROG_INTLTOOL([0.35.0]) -GNOME_COMPILE_WARNINGS +GNOME_COMPILE_WARNINGS(error) GNOME_DOC_INIT # set up gtk-doc @@ -91,7 +91,6 @@ CPPFLAGS="$CPPFLAGS -DGSEAL_ENABLE" if test "$GCC" = "yes"; then WARNINGFLAGS_C="$WARNINGFLAGS_C -Wall" - WARNINGFLAGS_C="$WARNINGFLAGS_C -Werror" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wcast-align -Wno-uninitialized" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wmissing-declarations" # WARNINGFLAGS_C="$WARNINGFLAGS_C -Wredundant-decls" -- 1.7.1.1 From luto at MIT.EDU Mon Jul 26 14:45:02 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:45:02 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 Message-ID: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> This patch, if configured with ./configure --enable-compile-warnings=yes --disable-sane --disable-strict is enough to build libcolor-glib and most of tools. (You'll have to cd explicitly -- 'make libcolor-glib' doesn't do anything.) --- configure.ac | 16 ++++---- libcolor-glib/gcm-brightness.c | 80 +------------------------------------- libcolor-glib/gcm-sensor-huey.c | 4 +- libcolor-glib/gcm-usb.c | 11 ++--- 4 files changed, 18 insertions(+), 93 deletions(-) diff --git a/configure.ac b/configure.ac index 7572ee1..8a5c64b 100644 --- a/configure.ac +++ b/configure.ac @@ -134,20 +134,20 @@ GLIB_GSETTINGS dnl --------------------------------------------------------------------------- dnl - Check library dependencies dnl --------------------------------------------------------------------------- -PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.9) +PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.24) PKG_CHECK_MODULES(XORG, xxf86vm xrandr) -PKG_CHECK_MODULES(GTK, gtk+-3.0 >= 2.90.3) -PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) +PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.20) +#PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) PKG_CHECK_MODULES(GUDEV, gudev-1.0) PKG_CHECK_MODULES(LCMS, lcms2) PKG_CHECK_MODULES(X11, x11) PKG_CHECK_MODULES(USB, [libusb-1.0 >= 1.0.0]) dnl Required for the properties window -PKG_CHECK_MODULES(CONTROL_CENTER, [ - libgnome-control-center >= 2.31.4]) -PANELS_DIR="${libdir}/control-center-1/panels" -AC_SUBST(PANELS_DIR) +#PKG_CHECK_MODULES(CONTROL_CENTER, [ + #libgnome-control-center >= 2.31.4]) +#PANELS_DIR="${libdir}/control-center-1/panels" +#AC_SUBST(PANELS_DIR) dnl **** Check for VTE **** PKG_CHECK_MODULES(VTE, vte3 >= 0.25.1, has_vte=yes, has_vte=no) @@ -195,7 +195,7 @@ if test x$enable_exiv = xyes; then AC_DEFINE(HAVE_EXIV,1,[Use EXIV support for detecting scanners]) fi -PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) +#PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) PKG_CHECK_MODULES(EXIF, libexif) AC_CHECK_LIB(tiff, TIFFReadRGBAImageOriented, diff --git a/libcolor-glib/gcm-brightness.c b/libcolor-glib/gcm-brightness.c index 3785e50..251810a 100644 --- a/libcolor-glib/gcm-brightness.c +++ b/libcolor-glib/gcm-brightness.c @@ -47,7 +47,7 @@ static void gcm_brightness_finalize (GObject *object); struct _GcmBrightnessPrivate { guint percentage; - GDBusConnection *connection; + void *connection; }; enum { @@ -68,43 +68,7 @@ G_DEFINE_TYPE (GcmBrightness, gcm_brightness, G_TYPE_OBJECT) gboolean gcm_brightness_set_percentage (GcmBrightness *brightness, guint percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *args = NULL; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - g_return_val_if_fail (percentage <= 100, FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - args = g_variant_new ("(u)", percentage), - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "SetBrightness", - args, - NULL, - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* success */ - ret = TRUE; -out: - if (args != NULL) - g_variant_unref (args); - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** @@ -113,45 +77,7 @@ out: gboolean gcm_brightness_get_percentage (GcmBrightness *brightness, guint *percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "GetBrightness", - NULL, - G_VARIANT_TYPE ("(u)"), - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* get the brightness */ - g_variant_get (response, "(u)", &priv->percentage); - - /* copy if set */ - if (percentage != NULL) - *percentage = priv->percentage; - - /* success */ - ret = TRUE; -out: - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** diff --git a/libcolor-glib/gcm-sensor-huey.c b/libcolor-glib/gcm-sensor-huey.c index 63ede01..3778266 100644 --- a/libcolor-glib/gcm-sensor-huey.c +++ b/libcolor-glib/gcm-sensor-huey.c @@ -363,7 +363,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to send request: %s", libusb_strerror (retval)); + "failed to send request"); goto out; } @@ -377,7 +377,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to get reply: %s", libusb_strerror (retval)); + "failed to get reply"); goto out; } diff --git a/libcolor-glib/gcm-usb.c b/libcolor-glib/gcm-usb.c index 891ff0f..85a5c87 100644 --- a/libcolor-glib/gcm-usb.c +++ b/libcolor-glib/gcm-usb.c @@ -301,8 +301,7 @@ gcm_usb_load (GcmUsb *usb, GError **error) if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to init libusb: %s", - libusb_strerror (retval)); + "failed to init libusb"); goto out; } @@ -375,8 +374,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to set configuration 0x%02x: %s", - configuration, libusb_strerror (retval)); + "failed to set configuration 0x%02x", + configuration); ret = FALSE; goto out; } @@ -384,8 +383,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to claim interface 0x%02x: %s", - interface, libusb_strerror (retval)); + "failed to claim interface 0x%02x", + interface); ret = FALSE; goto out; } -- 1.7.1.1 From hughsient at gmail.com Mon Jul 26 15:17:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:17:21 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 22 July 2010 18:40, Andrew Lutomirski wrote: > On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: >> On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >>> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>>> User 2 logs in >>>> gcm-prefs loads videolut (from a different profile) >>>> gcm-prefs sets profile atom for user 2 >>> >>> Yes, this is a valid bug. We probably should get our GSD plugin to >>> watch for ConsoleKit changes (the ACTIVE attribute) but really this >>> needs some proper session support. I really don't want to add yet >>> another session process just watching for a session active state >>> change. >> >> Well it's a very rare use case tho... commit dbebdeaeda3e9d48d5fa61bd9a2cd334fb61a4ce Author: Richard Hughes Date: Mon Jul 26 16:49:50 2010 +0100 Add a gnome-settings-daemon module to fix some hard to fix bugs This allows us to: 1) set gcm-apply when we switch users, so the correct VCGT is used 2) open the calibration window when a colorimeter is plugged in :100644 100644 0121d84... 3dcc91b... M Makefile.am :100644 100644 aa540d6... b030aba... M configure.ac :100644 100644 efdf3d4... c6cee42... M contrib/gnome-color-manager.spec.in :000000 100644 0000000... 0c620eb... A session/.gitignore :000000 100644 0000000... cba7279... A session/Makefile.am :000000 100644 0000000... fb6ec82... A session/color.gnome-settings-plugin :000000 100644 0000000... 312188e... A session/egg-console-kit.c :000000 100644 0000000... 2d897f1... A session/egg-console-kit.h :000000 100644 0000000... cc86414... A session/gsd-color-manager.c :000000 100644 0000000... 0c70ef5... A session/gsd-color-manager.h :000000 100644 0000000... 3883953... A session/gsd-color-plugin.c :000000 100644 0000000... d72b4bd... A session/gsd-color-plugin.h :100644 100644 a8848e8... 844c0b8... M src/Makefile.am :100644 100644 9b53705... 99aa7f2... M src/gcm-apply.c Richard. From hughsient at gmail.com Mon Jul 26 15:48:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:48:43 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: On 26 July 2010 15:45, Andy Lutomirski wrote: > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. ?(You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) Yup. Gross. :-) but thanks for posting. Richard. From hughsient at gmail.com Mon Jul 26 15:50:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:50:23 +0100 Subject: [PATCH] Make -Werror command-line configurable In-Reply-To: <1280155296-1270-1-git-send-email-luto@mit.edu> References: <1280155296-1270-1-git-send-email-luto@mit.edu> Message-ID: On 26 July 2010 15:41, Andy Lutomirski wrote: > -Werror is already enabled by --enable-strict (default) and > GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do > that and don't hardcode it. Applied, thanks. Richard. From pmjdebruijn at pcode.nl Mon Jul 26 18:31:12 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 26 Jul 2010 20:31:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On Sun, Jul 25, 2010 at 3:21 PM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Kinda is a bit of an understatement :p Anyhow, there's another easy and nasty way to solve this... Can't you provide fully statically built versions of the utils? I can get you a DDC dump of my display as well... Regards, Pascal de Bruijn From knizek.confy at volny.cz Mon Jul 26 19:32:35 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 21:32:35 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: <1280172755.4389.13.camel@localhost> Andy Lutomirski p??e v Po 26. 07. 2010 v 10:45 -0400: > This patch, if configured with > > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. (You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) The patch applied with errors on configure.ac, I updated it manually accordingly. However, there are still missing lcms2 and libusb-1.0 packages in Fedora 13 repositories. I have removed the version requirements for the two, but compilation afterwards failed on some libusb matters. As Pascal suggested, could someone skilled provide the necessary binaries compiled statically so that we can send the sensor data? Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Mon Jul 26 23:22:31 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:22:31 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280172755.4389.13.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: On 26 July 2010 20:32, Milan Kn??ek wrote: > As Pascal suggested, could someone skilled provide the necessary > binaries compiled statically so that we can send the sensor data? Grab the packages from http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/ and rebuild them. They should work okay on F12/13. Richard. From hughsient at gmail.com Mon Jul 26 23:25:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:25:02 +0100 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On 26 July 2010 19:31, Pascal de Bruijn wrote: > Can't you provide fully statically built versions of the utils? Ick. I'll give this a try, but I think it is made deliberately hard on Fedora. Richard. From len at math.northwestern.edu Mon Jul 26 23:45:28 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Mon, 26 Jul 2010 18:45:28 -0500 Subject: Possible interaction between the Color manager and Argyllcms Message-ID: <1280187928.2019.36.camel@localhost> 1. I am running Fedora 13. dispwin used directly doesn't seem to do what it did previously. I can use dispwin -I Profile_path to install a profile, but it doesn't persist as it did under previous versions of Fedora (including Fedora 12). But, I can use the gnome color manager to set the display profile, and that does seem topersist. I wonder if the gnome color management is somehow interfering with way argyllcms ordinarily works. 2. In using the color manager to profile a laptop (running Ubuntu 10.4) screen, and using my Eye One Pro, I encountered some problems. The Eye-One Pro has to be calibrated on its base, but the color manager doesn't ask me to do that. In order to get it done, I have to press Details, which brings up the usual argyllcms command line interface. But it is not clear exactly what I am supposed to do using that interface and what using the color manager. If I understood the intended sequence of events, it might be clearer to me how to proceed. Also, the color manager didn't allow me to do any hardware calibration. Of course, for my laptop screen that is somewhat restricted---the only control is screen brightness. I don't know what will happen when I try this an external monitor with lots of controls. Perhaps I am just supposed to continue in the Details window with argyllcms commands? -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Tue Jul 27 08:55:41 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 09:55:41 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280187928.2019.36.camel@localhost> References: <1280187928.2019.36.camel@localhost> Message-ID: On 27 July 2010 00:45, Leonard Evens wrote: > 1. ?I am running Fedora 13. ?dispwin used directly doesn't seem to do > what it did previously. ? I can use dispwin -I Profile_path ?to install > a profile, but it doesn't persist as it did under previous versions of > Fedora (including Fedora 12). ?But, I can use the gnome color manager to > set the display profile, and that does seem topersist. How do you mean persist? dispwin is probably trying to set the gamma tables in xorg, which GPM is also trying to do. If you want to make GCM just leave everything to argyll, just untick the color tickbox in the GNOME session preferences. > I wonder if the gnome color management is somehow interfering with way > argyllcms ordinarily works. As I understand it, dispwin runs, sets some values and then exits. GCM runs gcm-apply at session start, and then also exits. If you run gcm-prefs, the settings probably get re-applied. I think it's probably a good idea to let GCM actually apply the profile, and use argyll to create the profile. If you dump the generated icc profile somewhere GCM knows about, that should work pretty well. > 2. ?In using the color manager to profile a laptop (running Ubuntu 10.4) > screen, and using my Eye One Pro, I encountered some problems. ?The > Eye-One Pro has to be calibrated on its base, but the color manager > doesn't ask me to do that. ?In order to get it done, I have to press > Details, which brings up the usual argyllcms command line interface. > But it is not clear exactly what I am supposed to do using that > interface and what using the color manager. Ideally we can control the hardware using something other than a VTE window. Using a VTE widget sucks as we always have to try and convert the standard output to something localized and sane. Newer, unreleased, versions of argyll allow us to set an environment variable and get some easier to parse values, but there's no support in GCM for that just yet, as we're waiting for a release. It's likely we just have to add another screenscrape section to deal with the "Please insert the device into the dock" type of thing. Screenscaping sucks, but there's not a lot more we can do. If you supply a "gcm-prefs --verbose" trace whilst you're calibrating I can add the required screenscrape bits. I don't have the hardware myself, although donations are always very welcome. > Also, ?the color manager didn't allow me to do any hardware calibration. > Of course, for my laptop screen that is somewhat restricted---the only > control is screen brightness. ?I don't know what will happen when I try > this an external monitor with lots of controls. ?Perhaps I am just > supposed ?to continue in the Details window with argyllcms commands? Do you mean monitors with a programmable LUT? We're aiming to support these kind of things in the next few months. Monitors that allow custom gamma ramps via DDC/CI are also interesting to me, although specs on those are kinda hard to get. Richard. From knizek.confy at volny.cz Tue Jul 27 12:22:14 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Tue, 27 Jul 2010 14:22:14 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: <1280233334.4390.8.camel@localhost> Thanks both Andrew and Richard for trying to help a Fedora newbie :-) Due to dependency hell with GTK+3 on Fedora 13 (trying to build Richard's SRPM), I finally found a way to upgrade to rawhide and did so. Dependencies are not a problem anymore, but compilation of the current GIT fails (I used Andrew's configure options, since strict checking fails much sooner during the compilation): $ ./configure --enable-compile-warnings=yes --disable-sane --disable-strict ...bla bla ... $ make ... bla bla ... Making all in tools make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' CC gcm_dump_profile-gcm-dump-profile.o CCLD gcm-dump-profile ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to `libusb_strerror' collect2: ld returned 1 exit status make[2]: *** [gcm-dump-profile] Error 1 make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' make: *** [all] Error 2 If I recall correctly, something similar appeared with the sources patched by Andrew to compile on Fedora 13. (Even with libusb1.) Any help? P.S. If I do not get further, I may install Fedora 13 x86_64 and try the Andres's binary instead. -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at mit.edu Tue Jul 27 12:35:03 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 27 Jul 2010 08:35:03 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280233334.4390.8.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > Dependencies are not a problem anymore, but compilation of the current > GIT fails (I used Andrew's configure options, since strict checking > fails much sooner during the compilation): > > $ ./configure --enable-compile-warnings=yes --disable-sane > --disable-strict > ...bla bla ... > $ make > ... bla bla ... > > Making all in tools > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > ?CC ? ? gcm_dump_profile-gcm-dump-profile.o > ?CCLD ? gcm-dump-profile > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > `libusb_strerror' > collect2: ld returned 1 exit status > make[2]: *** [gcm-dump-profile] Error 1 > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > make: *** [all] Error 2 > > > If I recall correctly, something similar appeared with the sources > patched by Andrew to compile on Fedora 13. (Even with libusb1.) Yes. One of my patches removed a few calls to libusb_strerror. That function doesn't exist in Fedora's libusb-1.0. --Andy > > Any help? > > P.S. If I do not get further, I may install Fedora 13 x86_64 and try the > Andres's binary instead. > > -- > Milan Knizek > knizek (dot) confy (at) volny (dot) cz > http://www.milan-knizek.net - About linux and photography (Czech > language only) > > From hughsient at gmail.com Wed Jul 28 06:28:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 07:28:38 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280244947.2019.71.camel@localhost> References: <1280187928.2019.36.camel@localhost> <1280244947.2019.71.camel@localhost> Message-ID: On 27 July 2010 16:35, Leonard Evens wrote: > Under argyllcms, dispwin -I ?xxx.icc is supposed to load the table in > xorg, and create a file .config/olor.jcnf which tells where xxx.icc is located. > ... > But, according to Martin at the argyllcms mailing list, if you compile > argyllcms from source, it works as expected. Right, this makes sense. We don't compile the jncf bits in Fedora as it didn't compile with the system version of yajl, which we need to use in Fedora. It might be fairly easy to make argyll use the system version, in which case I think it's okay to turn on the jncf bits. > The way Argyllcms (and the Xrite software under Windows) works, you make > a series of adjustments to the monitor by using "hardware" controls for > Contrast, Brightness, and RGB values. You use them to set white point, > black point, etc. Argyllcms tells you how far off you are from your > target value in either direction. ?If you get these right, then the > calibration LUT loaded into Xorg is minimal and doesn't really change > screen appearance much. ?Is that what you mean by programmable LUT? No, programmable LUT is where you can send a 3D matrix to the monitor and it does most of the color calibration in hardware. You need a pretty nice monitor like an HP DreamColor to be able ot make use of this feature. GCM doesn't ask the user to set contrast and brightness manually, as ideally we can do this automatically using DDC/CI. That's one of the nice features that's on the TODO. Richard. From hughsient at gmail.com Wed Jul 28 09:02:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 10:02:54 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On 27 July 2010 13:35, Andrew Lutomirski wrote: > Yes. ?One of my patches removed a few calls to libusb_strerror. ?That > function doesn't exist in Fedora's libusb-1.0. Can you give master a go please: commit a4dbe5e6ddf6e96f59826537dbbcc542e7fd5fa1 Author: Richard Hughes Date: Wed Jul 28 11:00:22 2010 +0200 Add gcm-compat.h to deal with unreleased versions of libusb :100644 100644 584ca05... de5cc4b... M configure.ac :100644 100644 71b8c89... 4c6c70d... M libcolor-glib/Makefile.am :000000 100644 0000000... 3e30993... A libcolor-glib/gcm-compat.h :100644 100644 c54a0cc... a5991dc... M libcolor-glib/gcm-sensor-huey.c :100644 100644 b5a628f... 043f832... M libcolor-glib/gcm-usb.c :100644 100644 39ab6b2... a96b102... M libcolor-glib/libcolor-glib.h Thanks, Richard. From jyqvklioo at googlemail.com Wed Jul 28 16:28:23 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 18:28:23 +0200 Subject: color managing libraries Message-ID: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Testing LCMS with photo editing showed noticeable color degradation on operations which should show none. I think I discovered why when I read LCMS documentation. LCMS is madness. It puts everything through the so called "sRGB" color space. For those who are not familiar with this color spare, it is designed to represent what CRT monitors show by default with no color management. It has a tiny color gamut and a discontinuity in gamma correction. (2 segments) LCMS needlessly truncates the gamut of any operation (which is not already in the sRGB color space) by converting colors to that color space unconditionally. Please, stop the madness. Do not use LCMS. Indications I saw in writing from the author (not addressed to me) indicate he is not receptive to acknowledging the poor handling his software does. I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? From hughsient at gmail.com Wed Jul 28 16:37:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 18:37:02 +0200 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 28 July 2010 18:28, wrote: > LCMS is madness. Nahh, I think lcms is actually pretty cool. > It puts everything through the so called "sRGB" color space. I don't think that's true at all, can you point to the docs (or code) that says that? > I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? gnome-color-manager already uses argyll for its calibration needs, and lcms for it's internal pixel conversion stuff. Richard. From jyqvklioo at googlemail.com Wed Jul 28 19:23:50 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 21:23:50 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > > I don't think that's true at all, can you point to the docs (or code) > that says that? I sought the text that gave me this impression and did not find it. It has been years since I read whatever it was. Possibly it was related to an image editing application which used LCMS rather than LCMS itself. The application which I saw the impressively bad results in was Krita. I tested where the source and all settable color spaces were not sRGB. From graeme2 at argyllcms.com Wed Jul 28 23:57:05 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 29 Jul 2010 09:57:05 +1000 Subject: color managing libraries In-Reply-To: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> <20100728212350.0cf065e9@jyqvklioo.googlemail.com> Message-ID: <4C50C3D1.6040804@argyllcms.com> jyqvklioo at googlemail.com wrote: > The application which I saw the impressively bad results in was Krita. > I tested where the source and all settable color spaces were not sRGB. Why jump to the conclusion that it's LCMS ? Color management is complicated. Just like the situation when programming, if it doesn't work the way you expect, the most likely explanation is that you've done something wrong. [From my observations on the lcms mailing list, Marti is very responsive to reports of problems.] Graeme Gill. From alexandre.prokoudine at gmail.com Thu Jul 29 00:17:58 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Thu, 29 Jul 2010 04:17:58 +0400 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 7/28/10, jyqvklioo com> wrote: > Testing LCMS with photo editing showed noticeable color degradation on > operations which should show none. > I think I discovered why when I read LCMS documentation. > > LCMS is madness. > > It puts everything through the so called "sRGB" color space. > For those who are not familiar with this color spare, it is designed to > represent what CRT monitors show by default with no color management. > It has a tiny color gamut and a discontinuity in gamma correction. (2 > segments) > LCMS needlessly truncates the gamut of any operation (which is not already > in the sRGB color space) by converting colors to that color space > unconditionally. My dear jyqvklioo (do you work for a throat sweets manufacturer btw? :-)), I have a suspicion that you are confusing back-end with implementation. If Krita passes everything through sRGB, then it is because either it doesn't allow specifying a different working color space or it does allow that, but you didn't do it. LittleCMS has nothing to do with that. However feel free to prove me wrong and quote the bit from LittleCMS's docs that explicitly confirms your opinion. Alexandre Prokoudine http://libregraphicsworld.org From jyqvklioo at googlemail.com Thu Jul 29 06:47:07 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Thu, 29 Jul 2010 08:47:07 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100729084707.2f47845a@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > I don't think that's true at all, ... You do have experience with LCMS so I consider that in my estimation of odds. That combined with the notes I saw about increased accuracy in LCMS 2 and it being largely new code, I am optimistic and looking forward to trying out applications using LCMS, especially LCMS 2. From knizek.confy at volny.cz Sat Jul 31 07:26:25 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sat, 31 Jul 2010 09:26:25 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: <1280561185.4362.6.camel@localhost> Andrew Lutomirski p??e v ?t 27. 07. 2010 v 08:35 -0400: > On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > > > Dependencies are not a problem anymore, but compilation of the current > > GIT fails (I used Andrew's configure options, since strict checking > > fails much sooner during the compilation): > > > > $ ./configure --enable-compile-warnings=yes --disable-sane > > --disable-strict > > ...bla bla ... > > $ make > > ... bla bla ... > > > > Making all in tools > > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > > CC gcm_dump_profile-gcm-dump-profile.o > > CCLD gcm-dump-profile > > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > > `libusb_strerror' > > collect2: ld returned 1 exit status > > make[2]: *** [gcm-dump-profile] Error 1 > > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > > make: *** [all] Error 2 > > > > > > If I recall correctly, something similar appeared with the sources > > patched by Andrew to compile on Fedora 13. (Even with libusb1.) > > Yes. One of my patches removed a few calls to libusb_strerror. That > function doesn't exist in Fedora's libusb-1.0. Hm, I have not noticed that earlier. After applying those referring to libusb_strerror, the compilation failed in a yet later stage, luckily after ./tools/gcm-dump-sensor. Attached is the dump file from Huey sold together with Samsung SyncMaster XL20. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) -------------- next part -------------- // AUTOMATICALLY GENERATED -- DO NOT EDIT generic-dump-version:1 kind:huey vendor:Gretag-Macbeth AG model:Huey serial-number:75951 device:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.1 huey-dump-version:1 unlock-string:GrMb register[0x00]:0x00 register[0x01]:0x01 register[0x02]:0x28 register[0x03]:0xaf register[0x04]:0x3d register[0x05]:0x3a register[0x06]:0x67 register[0x07]:0x67 register[0x08]:0xba register[0x09]:0xc3 register[0x0a]:0x91 register[0x0b]:0x35 register[0x0c]:0x3c register[0x0d]:0x3b register[0x0e]:0x38 register[0x0f]:0x92 register[0x10]:0x3a register[0x11]:0x86 register[0x12]:0x6c register[0x13]:0x57 register[0x14]:0x3c register[0x15]:0xe1 register[0x16]:0xb3 register[0x17]:0x52 register[0x18]:0x39 register[0x19]:0xd0 register[0x1a]:0x39 register[0x1b]:0xd5 register[0x1c]:0xba register[0x1d]:0x68 register[0x1e]:0x40 register[0x1f]:0xbe register[0x20]:0x3a register[0x21]:0xae register[0x22]:0x52 register[0x23]:0x53 register[0x24]:0x3d register[0x25]:0x8f register[0x26]:0x3c register[0x27]:0x20 register[0x28]:0xff register[0x29]:0xff register[0x2a]:0xff register[0x2b]:0xff register[0x2c]:0xff register[0x2d]:0xff register[0x2e]:0xff register[0x2f]:0xff register[0x30]:0xff register[0x31]:0xff register[0x32]:0x45 register[0x33]:0x2b register[0x34]:0xe7 register[0x35]:0x9f register[0x36]:0x3d register[0x37]:0x39 register[0x38]:0x16 register[0x39]:0x8b register[0x3a]:0xbb register[0x3b]:0x12 register[0x3c]:0xed register[0x3d]:0xef register[0x3e]:0x3c register[0x3f]:0x23 register[0x40]:0xe3 register[0x41]:0x36 register[0x42]:0x3a register[0x43]:0x9e register[0x44]:0xef register[0x45]:0x06 register[0x46]:0x3c register[0x47]:0xd6 register[0x48]:0xfa register[0x49]:0x9f register[0x4a]:0x39 register[0x4b]:0xc1 register[0x4c]:0x79 register[0x4d]:0x37 register[0x4e]:0xba register[0x4f]:0x8d register[0x50]:0x39 register[0x51]:0x53 register[0x52]:0x3a register[0x53]:0x81 register[0x54]:0xf4 register[0x55]:0x46 register[0x56]:0x3d register[0x57]:0x8c register[0x58]:0x5c register[0x59]:0xa7 register[0x5a]:0x45 register[0x5b]:0x18 register[0x5c]:0xa5 register[0x5d]:0x90 register[0x5e]:0xff register[0x5f]:0xff register[0x60]:0xff register[0x61]:0xff register[0x62]:0xff register[0x63]:0xff register[0x64]:0xff register[0x65]:0xff register[0x66]:0xff register[0x67]:0x3c register[0x68]:0x98 register[0x69]:0xa8 register[0x6a]:0x9d register[0x6b]:0x3c register[0x6c]:0x65 register[0x6d]:0x60 register[0x6e]:0x41 register[0x6f]:0x3c register[0x70]:0x65 register[0x71]:0x60 register[0x72]:0x41 register[0x73]:0xff register[0x74]:0x09 register[0x75]:0x71 register[0x76]:0x20 register[0x77]:0x05 register[0x78]:0xff register[0x79]:0xff register[0x7a]:0x47 register[0x7b]:0x72 register[0x7c]:0x4d register[0x7d]:0x62 register[0x7e]:0x00 register[0x7f]:0x0e register[0x80]:0x01 register[0x81]:0x99 register[0x82]:0x69 register[0x83]:0x00 register[0x84]:0x02 register[0x85]:0x20 register[0x86]:0xf4 register[0x87]:0xee register[0x88]:0x02 register[0x89]:0x20 register[0x8a]:0xf4 register[0x8b]:0xee register[0x8c]:0x16 register[0x8d]:0xe4 register[0x8e]:0x00 register[0x8f]:0xff register[0x90]:0xff register[0x91]:0xff register[0x92]:0xff register[0x93]:0xff register[0x94]:0x3a register[0x95]:0x99 register[0x96]:0xc8 register[0x97]:0x02 register[0x98]:0xff register[0x99]:0xff register[0x9a]:0xff register[0x9b]:0xff register[0x9c]:0xff register[0x9d]:0xff register[0x9e]:0xff register[0x9f]:0xff register[0xa0]:0xff register[0xa1]:0xff register[0xa2]:0xff register[0xa3]:0xff register[0xa4]:0xff register[0xa5]:0xff register[0xa6]:0xff register[0xa7]:0xff register[0xa8]:0xff register[0xa9]:0xff register[0xaa]:0xff register[0xab]:0xff register[0xac]:0xff register[0xad]:0xff register[0xae]:0xff register[0xaf]:0xff register[0xb0]:0xff register[0xb1]:0xff register[0xb2]:0xff register[0xb3]:0xff register[0xb4]:0xff register[0xb5]:0xff register[0xb6]:0xff register[0xb7]:0xff register[0xb8]:0xff register[0xb9]:0xff register[0xba]:0xff register[0xbb]:0xff register[0xbc]:0xff register[0xbd]:0xff register[0xbe]:0xff register[0xbf]:0xff register[0xc0]:0xff register[0xc1]:0xff register[0xc2]:0xff register[0xc3]:0xff register[0xc4]:0xff register[0xc5]:0xff register[0xc6]:0xff register[0xc7]:0xff register[0xc8]:0xff register[0xc9]:0xff register[0xca]:0xff register[0xcb]:0xff register[0xcc]:0xff register[0xcd]:0xff register[0xce]:0xff register[0xcf]:0xff register[0xd0]:0xff register[0xd1]:0xff register[0xd2]:0xff register[0xd3]:0xff register[0xd4]:0xff register[0xd5]:0xff register[0xd6]:0xff register[0xd7]:0xff register[0xd8]:0xff register[0xd9]:0xff register[0xda]:0xff register[0xdb]:0xff register[0xdc]:0xff register[0xdd]:0xff register[0xde]:0xff register[0xdf]:0xff register[0xe0]:0xff register[0xe1]:0xff register[0xe2]:0xff register[0xe3]:0xff register[0xe4]:0xff register[0xe5]:0xff register[0xe6]:0xff register[0xe7]:0xff register[0xe8]:0xff register[0xe9]:0xff register[0xea]:0xff register[0xeb]:0xff register[0xec]:0xff register[0xed]:0xff register[0xee]:0xff register[0xef]:0xff register[0xf0]:0xff register[0xf1]:0xff register[0xf2]:0xff register[0xf3]:0xff register[0xf4]:0xff register[0xf5]:0xff register[0xf6]:0xff register[0xf7]:0xff register[0xf8]:0xff register[0xf9]:0xff register[0xfa]:0xff register[0xfb]:0xff register[0xfc]:0xff register[0xfd]:0xff register[0xfe]:0xff From hughsient at gmail.com Sat Jul 31 07:52:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 31 Jul 2010 09:52:45 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280561185.4362.6.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> <1280561185.4362.6.camel@localhost> Message-ID: On 31 July 2010 09:26, Milan Kn??ek wrote: > Attached is the dump file from Huey sold together with Samsung > SyncMaster XL20. Great, thanks. I'll analyze your dump and Pascals after I return from GUADEC. Richard. From hughsient at gmail.com Thu Jul 1 08:37:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 09:37:32 +0100 Subject: GNOME Color Manager 2.31.4 Message-ID: gnome-color-manager is a session program that makes it easy to manage, install and generate color profiles in the GNOME desktop. Version 2.31.4 ~~~~~~~~~~~~~~ Released: 2010-07-01 * Translations - Updated Galician translations (Fran Di?guez) - Updated Spanish translation (Jorge Gonz?lez) - Updated Estonian translation (Mattias P?ldaru) - Updated Hebrew translation (Yaron Shahrabani) - Updated Simplified Chinese translation (?? Gan Lu) * New Features: - Port from lcms to lcms2 (Richard Hughes) - Split gcm-prefs into a control center module and a profile viewer (Richard Hughes) - Add gcm_image_set_abstract_profile() so we can set LAB abstract profiles (Richard Hughes) - Add GcmProfileSearchFlags so we can control what kind of profiles are loaded (Richard Hughes) - Allow passing profile and device types to GetProfilesForType() (Richard Hughes) * Bugfix: - Do not try to convert if the input and output profiles are not RGB (Richard Hughes) - Refuse to import a local profile if it already exists system-wide (Richard Hughes) - Make GcmImage take a GcmProfile, not a base64 string (Richard Hughes) - Depend on gnome-control-center 2.31.4 for GTK 3.0 fixes (Richard Hughes) - Ensure we load the profile store in the DBus service (Richard Hughes) Richard. From gysvanzyl at gmail.com Thu Jul 1 15:31:58 2010 From: gysvanzyl at gmail.com (Gys van Zyl) Date: Thu, 1 Jul 2010 18:31:58 +0300 Subject: Color management in ubuntu Message-ID: Hi all, I have a couple of questions that may be a bit silly due to my beginner level knowledge of color management. I'm an amateur/hobby photographer and I've been using ubuntu for a while (currently using 10.04). For a while now I've realized the importance of having a color managed workflow, but have put off getting the hardware as I thought getting everything installed, set up and configured would be tough in linux. I recently purchased a Pantone Huey monitor calibration device and you could imagine my pleasant surprise when I found how extremely easy everything was to use with gnome color manager. In no time, with almost zero effort I had everything up and running. Kudos to the developer(s) - this is excellent software! So, to test how color management works in a browser, I found this web site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. Using google chrome (a non color managed browser) this page is a mess of incorrectly rendered photo's - I expected this. Using Firefox, things are a lot better - imbedded color profiles are now honored and the photos display fine. However, about half-way down the page at the heading "sRGB / Standard RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged sRGB rollover." In my Firefox window, the change is not minor, and I'm trying to figure out why this is. In my workflow all exif data is stripped from my photo's before I upload to the web. I thought that this wouldn't matter, as long as my final image was created in an sRGB colorspace. However, I have now found that my photo's look subtly but definitely different in the software I use (gimp, digikam) and my browsers. My limited understanding of color management led me to believe that un-tagged sRGB images should look the same in a browser on a color-managed system. However, on my system they don't and its causing a problem for me - my photo's don't display the way I intended. How can I resolve this? Is my understanding wrong, should I educate myself a bit more? Did I do something wrong when I calibrated my monitor? Gys -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmjdebruijn at pcode.nl Thu Jul 1 15:58:07 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 17:58:07 +0200 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 5:31 PM, Gys van Zyl wrote: > Hi all, > I have a couple of questions that may be a bit silly due to my beginner > level knowledge of color management. > I'm an?amateur/hobby photographer and?I've been using ubuntu for a while > (currently using 10.04). ?For a while now I've realized the importance of > having a color managed workflow, but have put off getting the hardware as I > thought getting everything installed, set up and configured would be tough > in linux. ?I recently purchased a Pantone Huey monitor calibration device > and you could imagine my pleasant surprise when I found how extremely easy > everything was to use with gnome color manager. ?In no time, with almost > zero effort I had everything up and running. ?Kudos?to the developer(s) - > this is excellent software! GCM + Argyll is a powerful combination indeed :) > So, to test how color management works in a browser, I found this web > site:?http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > ?Using google chrome (a non color managed browser) this page is a mess of > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a > lot better - imbedded color profiles are now honored and the photos display > fine. However, about half-way down the page at the heading "sRGB / Standard > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm > trying to figure out why this is. > In my workflow all exif data is stripped from my photo's before I upload to > the web. ?I thought that this wouldn't matter, as long as my final image was > created in an sRGB colorspace. ?However, I have now found that my photo's > look subtly but definitely different in the software I use (gimp, digikam) > and my browsers. > My limited understanding of color management led me to believe that > un-tagged sRGB images should look the same in a browser on a color-managed > system. ?However, on my system they don't and its causing a problem for me - > my photo's don't display the way I intended. ?How can I resolve this? ?Is my > understanding wrong, should I educate myself a bit more? ?Did I do something > wrong when I calibrated my monitor? The problem is that being color managed, and being properly configured is not always the same... All color managed applications checked for an embedded profile when loading images and will for example convert an Adobe RGB image to sRGB on request. If an image is untagged sRGB will be assumed. However, if you do not properly configure the application to use your display profile it will be displayed as plain srgb without your display profile applied, hence wrong colors (since only the videolut will have effect). I think GIMP doesn't use the system display profile by default. Firefox also requires the display profile to be configured through "about:config" search for "display_profile". Same goes for lots of other applications. So you will still need to check each an every applications configuration. Since they might use poor defaults. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 16:03:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:03:47 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On 1 July 2010 16:58, Pascal de Bruijn wrote: > I think GIMP doesn't use the system display profile by default. > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. Could you start to make to a list of applications and the fixes here please: http://live.gnome.org/GnomeColorManager/FAQ -- I think a list would be really useful for users. Then we can file bugs against the programs to use the GCM DBus interface or the ICCPROFILESINX specification and get things just working by default. As for everything else, I normally tag my "web-safe" with sRGB (it's a tiny increase in size, and probably a good idea) and ensure the display profile has been set correctly. Richard. From marek.matulka at gmail.com Thu Jul 1 16:18:57 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:18:57 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <1278001137.2552.11.camel@localhost> Hello, This is my first post on the group, but I've been following a group for some time. Well done guys for a rocking bit of software giving us a great colour management tool! On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: > > So, to test how color management works in a browser, I found this web > > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > > Using google chrome (a non color managed browser) this page is a mess of > > incorrectly rendered photo's - I expected this. Using Firefox, things are a > > lot better - imbedded color profiles are now honored and the photos display > > fine. However, about half-way down the page at the heading "sRGB / Standard > > RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged > > rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 > > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > > sRGB rollover." In my Firefox window, the change is not minor, and I'm > > trying to figure out why this is. > > In my workflow all exif data is stripped from my photo's before I upload to > > the web. I thought that this wouldn't matter, as long as my final image was > > created in an sRGB colorspace. However, I have now found that my photo's > > look subtly but definitely different in the software I use (gimp, digikam) > > and my browsers. > > My limited understanding of color management led me to believe that > > un-tagged sRGB images should look the same in a browser on a color-managed > > system. However, on my system they don't and its causing a problem for me - > > my photo's don't display the way I intended. How can I resolve this? Is my > > understanding wrong, should I educate myself a bit more? Did I do something > > wrong when I calibrated my monitor? > > The problem is that being color managed, and being properly configured > is not always the same... > > All color managed applications checked for an embedded profile when > loading images and will for example convert an Adobe RGB image to sRGB > on request. If an image is untagged sRGB will be assumed. > > However, if you do not properly configure the application to use your > display profile it will be displayed as plain srgb without your > display profile applied, hence wrong colors (since only the videolut > will have effect). > > I think GIMP doesn't use the system display profile by default. > > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. I had similar issue - when I created three images: 1. tagged with Adobe RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly displayed in GIMP, but not in any desktop viewer. I think the problem lies in assumption, that for untagged images viewer should not apply monitor profile, while it should assume sRGB and convert it accordingly. It seems GIMP is working that way hence all three images are correctly displayed. I have filled a bug report against Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=606996 this bug report includes example screenshots of gimp and eog. Although, I am not sure if my assumptions are right, so please correct me, if I am wrong. Greetings, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 16:27:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:27:39 +0100 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On 1 July 2010 17:18, Marek Matulka wrote: > Although, I am not sure if my assumptions are right, so please correct > me, if I am wrong. I think this functionality needs to live in the toolkit (e.g. GTK) and done automatically, as the harder applications have to work to do the right thing, the fewer that will actually do it. Richard. From marek.matulka at gmail.com Thu Jul 1 16:42:44 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:42:44 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: <1278002564.2552.12.camel@localhost> On Thu, 2010-07-01 at 17:27 +0100, Richard Hughes wrote: > On 1 July 2010 17:18, Marek Matulka wrote: > > Although, I am not sure if my assumptions are right, so please correct > > me, if I am wrong. > > I think this functionality needs to live in the toolkit (e.g. GTK) and > done automatically, as the harder applications have to work to do the > right thing, the fewer that will actually do it. That would be awesome! Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 17:25:52 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:25:52 +0100 Subject: Color management in ubuntu In-Reply-To: <1278002564.2552.12.camel@localhost> References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 17:42, Marek Matulka wrote: > That would be awesome! I've been experimenting with GLSL shaders, and doing the color conversion in hardware on the GPU. We've hit a few stumbing blocks in clutter, but I'm adding API to clutter where required. Using the hardware allows us to do lots of clever interpolation in 3D to make things super sweet. Without using GPU hardware it's quite hard to process high-def video at normal frame rates. Long term this means we can attach a ClutterShader object to different mutter windows and color correct whole windows / subwindows on the GPU. Thatis, unless the application opts out of color managed mode. Or opts in. I'm not sure. There's a net-color-spec that we could use, although this seems very difficult to implement without working on a post-composited display like compiz provides. Either way, unless the ClutterTexture patches get written none of it will work :) Richard. From pmjdebruijn at pcode.nl Thu Jul 1 17:29:17 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:29:17 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: > Hello, > > This is my first post on the group, but I've been following a group for > some time. Well done guys for a rocking bit of software giving us a > great colour management tool! > > On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >> > So, to test how color management works in a browser, I found this web >> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >> > ?Using google chrome (a non color managed browser) this page is a mess of >> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >> > lot better - imbedded color profiles are now honored and the photos display >> > fine. However, about half-way down the page at the heading "sRGB / Standard >> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >> > trying to figure out why this is. >> > In my workflow all exif data is stripped from my photo's before I upload to >> > the web. ?I thought that this wouldn't matter, as long as my final image was >> > created in an sRGB colorspace. ?However, I have now found that my photo's >> > look subtly but definitely different in the software I use (gimp, digikam) >> > and my browsers. >> > My limited understanding of color management led me to believe that >> > un-tagged sRGB images should look the same in a browser on a color-managed >> > system. ?However, on my system they don't and its causing a problem for me - >> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >> > understanding wrong, should I educate myself a bit more? ?Did I do something >> > wrong when I calibrated my monitor? >> >> The problem is that being color managed, and being properly configured >> is not always the same... >> >> All color managed applications checked for an embedded profile when >> loading images and will for example convert an Adobe RGB image to sRGB >> on request. If an image is untagged sRGB will be assumed. >> >> However, if you do not properly configure the application to use your >> display profile it will be displayed as plain srgb without your >> display profile applied, hence wrong colors (since only the videolut >> will have effect). >> >> I think GIMP doesn't use the system display profile by default. >> >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". >> >> Same goes for lots of other applications. So you will still need to >> check each an every applications configuration. Since they might use >> poor defaults. > > I had similar issue - when I created three images: 1. tagged with Adobe > RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly > displayed in GIMP, but not in any desktop viewer. > > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. The tagging of an image has _NOTHING_ to do with applying a display profile or not... If this really is the case, then someone should really be shot for that (not dead... the knees will do just fine :). The application of the display profile (should) only depend on the application settings not on the input image... All programs assume untagged images are sRGB, (even though tagging images with an sRGB profile _is_ a good idea, this will prevent future ambiguity). Programs which aren't color managed (or where color management is disabled) are just RGBin (from file) == RGBout (to display) That said... Please also note that not all forms of sRGB are equal, there are several version of the sRGB profile that might differ a bit... I think at one time there even was a simplified sRGB with a real 2.2 gamma curve... which is wrong, since sRGB is gamma 2.4 with a small dead area in the blacks. Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Thu Jul 1 17:31:02 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:31:02 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:25 PM, Richard Hughes wrote: > On 1 July 2010 17:42, Marek Matulka wrote: >> That would be awesome! > > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. And you need to make the applications aware that they do not need to do their own color management... Otherwise apps like the GIMP might apply an output profile themselves, having the display rgb processed again by the GLSL shaders. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 17:34:17 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:34:17 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:31, Pascal de Bruijn wrote: > And you need to make the applications aware that they do not need to > do their own color management... Otherwise apps like the GIMP might > apply an output profile themselves, having the display rgb processed > again by the GLSL shaders. Right. This is why I think it's going to have to be opt-in. In reality, I think we're a long way from pushing this into a distro. Richard From pmjdebruijn at pcode.nl Thu Jul 1 17:38:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:38:37 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:29 PM, Pascal de Bruijn wrote: > On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: >> Hello, >> >> This is my first post on the group, but I've been following a group for >> some time. Well done guys for a rocking bit of software giving us a >> great colour management tool! >> >> On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >>> > So, to test how color management works in a browser, I found this web >>> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >>> > ?Using google chrome (a non color managed browser) this page is a mess of >>> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >>> > lot better - imbedded color profiles are now honored and the photos display >>> > fine. However, about half-way down the page at the heading "sRGB / Standard >>> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >>> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >>> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >>> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >>> > trying to figure out why this is. >>> > In my workflow all exif data is stripped from my photo's before I upload to >>> > the web. ?I thought that this wouldn't matter, as long as my final image was >>> > created in an sRGB colorspace. ?However, I have now found that my photo's >>> > look subtly but definitely different in the software I use (gimp, digikam) >>> > and my browsers. >>> > My limited understanding of color management led me to believe that >>> > un-tagged sRGB images should look the same in a browser on a color-managed >>> > system. ?However, on my system they don't and its causing a problem for me - >>> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >>> > understanding wrong, should I educate myself a bit more? ?Did I do something >>> > wrong when I calibrated my monitor? >>> >>> The problem is that being color managed, and being properly configured >>> is not always the same... >>> >>> All color managed applications checked for an embedded profile when >>> loading images and will for example convert an Adobe RGB image to sRGB >>> on request. If an image is untagged sRGB will be assumed. >>> >>> However, if you do not properly configure the application to use your >>> display profile it will be displayed as plain srgb without your >>> display profile applied, hence wrong colors (since only the videolut >>> will have effect). >>> >>> I think GIMP doesn't use the system display profile by default. >>> >>> Firefox also requires the display profile to be configured through >>> "about:config" search for "display_profile". >>> >>> Same goes for lots of other applications. So you will still need to >>> check each an every applications configuration. Since they might use >>> poor defaults. >> >> I had similar issue - when I created three images: 1. tagged with Adobe >> RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly >> displayed in GIMP, but not in any desktop viewer. >> >> I think the problem lies in assumption, that for untagged images viewer >> should not apply monitor profile, while it should assume sRGB and >> convert it accordingly. It seems GIMP is working that way hence all >> three images are correctly displayed. > > The tagging of an image has _NOTHING_ to do with applying a display > profile or not... If this really is the case, then someone should > really be shot for that (not dead... the knees will do just fine :). Cutting my own rant short... It's easy for forget (I often do), that color management as a concept is non-obvious for pretty much everybody (including normal coders) who aren't into this stuff... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Thu Jul 1 18:00:09 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 20:00:09 +0200 Subject: Conceptual questions Message-ID: <4C2CD7A9.90409@hoech.org> Hi, I have a few conceptual questions. Currently GCM has preferences for RGB and CMYK working space, and "display" and "softproof" rendering intent. But what I think is missing for softproofing is a checkbox "Simulate media (paper) color" which when checked (which would be a good default), means absolute colorimetric intent should be used, otherwise relative colorimetric (_without_ black point compensation). Is my current understanding of the GCM UI intentions correct as follows: Image -> "display" intent in GCM -> device (for non-softproofing) Image -> "softproof" intent in GCM -> softproof colorspace (is there a way in GCM to choose a default for this?) -> relative without bpc or abscol (it is not clear to me which is used/assumed by GCM by default, I'd think abscol?) -> device Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jul 1 18:23:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 19:23:19 +0100 Subject: Conceptual questions In-Reply-To: <4C2CD7A9.90409@hoech.org> References: <4C2CD7A9.90409@hoech.org> Message-ID: On 1 July 2010 19:00, Florian H?ch wrote: > I think is missing for softproofing is a checkbox "Simulate media (paper) > color" which when checked (which would be a good default), means absolute > colorimetric intent should be used, otherwise relative colorimetric Isn't that a per-application thing, rather than a per-session thing? By "softproof" GCM indicates the proofing mode to use when doing things like print preview. In a print preview aka "softproof" you already know the device you are targeting and the ICC profiles available. I also think it's useful to talk in terms of use-cases, rather than presenting lots of tickyboxes in preferences panels. I've got enough feedback (of the negative kind :-) from my boss about the number of UI elements we expose already. Maybe if we all refer to the three people here http://live.gnome.org/GnomeColorManager#Typical_Users we can all work towards further use-cases and application notes. I do think this is a really important discussion and am really pleased you're onboard. Thanks. Richard. From knizek.confy at volny.cz Thu Jul 1 18:58:16 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 01 Jul 2010 20:58:16 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: <1278010696.9901.3.camel@athlon> Marek Matulka p??e v ?t 01. 07. 2010 v 17:18 +0100: > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. > > I have filled a bug report against Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=606996 > > this bug report includes example screenshots of gimp and eog. > It seems to be a bug like the one reported by me upstream some time ago: https://bugzilla.gnome.org/show_bug.cgi?id=554498 regards, -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From lists+gnome-color-manager at hoech.org Thu Jul 1 19:22:28 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 21:22:28 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> Message-ID: <4C2CEAF4.9030006@hoech.org> Am 01.07.2010 20:23, schrieb Richard Hughes: > On 1 July 2010 19:00, Florian H?ch wrote: >> I think is missing for softproofing is a checkbox "Simulate media (paper) >> color" which when checked (which would be a good default), means absolute >> colorimetric intent should be used, otherwise relative colorimetric > > Isn't that a per-application thing, rather than a per-session thing? > By "softproof" GCM indicates the proofing mode to use when doing > things like print preview. In a print preview aka "softproof" you > already know the device you are targeting and the ICC profiles > available. Ok, sounds reasonable. If the device/profile being simulated is chosen in the application, there's probably no need for GCM to provide settings for a default "softproofing" colorspace. > I also think it's useful to talk in terms of use-cases, rather than > presenting lots of tickyboxes in preferences panels. I've got enough > feedback (of the negative kind :-) from my boss about the number of UI > elements we expose already. Maybe if we all refer to the three people > here http://live.gnome.org/GnomeColorManager#Typical_Users we can all > work towards further use-cases and application notes. :) don't worry, I'm not keen on having a GCM plastered with checkboxes either. Re use cases: My original inquiry would fit in no. #4 ("An application wants to softproof for a printer device to show the user how the colors are going to be clipped when the file is printed"). Now you already said thats probably a per-application thing. I'm just trying to wrap my head around where the current GCM "softproof" intent setting comes into play, what users are choosing with it exactly (like I said, my assuption was it is the image -> device being simulated transform, in which case it makes sense to expose all four intents), and how it interacts/relates to the "display" intent setting (which should then actually be ignored for softproofing by an application). > I do think this is a really important discussion and am really pleased > you're onboard. Thanks. > > Richard. -- Florian H?ch http://hoech.net From jorge.fabregas at gmail.com Fri Jul 2 12:36:50 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Fri, 2 Jul 2010 08:36:50 -0400 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <201007020836.50739.jorge.fabregas@gmail.com> On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". Hello guys, I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary options (gfx.color_management...), restarted Firefox and I still can't see this picture correctly: http://www.color.org/version4html.xalter I see it as if my system only supports "ICC version 2" as the examples shown. I load my ICC profile with "dispwin -L" when my system starts but I'm not sure if its "version 4"? How can I know this? (sorry newbie here when it comes to color management). Thanks, Jorge From pmjdebruijn at pcode.nl Fri Jul 2 12:39:52 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 2 Jul 2010 14:39:52 +0200 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Jorge F?bregas : > On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". > > Hello guys, > > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary > options (gfx.color_management...), restarted Firefox and I still can't see > this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples shown. > I load my ICC profile with "dispwin -L" when my system starts but I'm not sure > if its "version 4"? ?How can I know this? ?(sorry newbie here when it comes to > color management). Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. Firefox 3.5+ uses it's own internal CMS which only processes v2 profiles, but it's faster. Regards, Pascal de Bruijn From marek.matulka at gmail.com Fri Jul 2 12:41:38 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Fri, 02 Jul 2010 13:41:38 +0100 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <1278074498.3005.14.camel@localhost> On Fri, 2010-07-02 at 08:36 -0400, Jorge F?bregas wrote: > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the > necessary options (gfx.color_management...), restarted Firefox and I > still can't see this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples > shown. I load my ICC profile with "dispwin -L" when my system starts > but I'm not sure if its "version 4"? How can I know this? (sorry > newbie here when it comes to color management). AFAIK Firefox does not support version 4 yet. Greetings, Marek From hughsient at gmail.com Fri Jul 2 12:49:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:49:55 +0100 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Pascal de Bruijn : > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? Richard. From hughsient at gmail.com Fri Jul 2 12:58:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:58:55 +0100 Subject: Conceptual questions In-Reply-To: <4C2CEAF4.9030006@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: On 1 July 2010 20:22, Florian H?ch wrote: > Ok, sounds reasonable. If the device/profile being simulated is chosen in > the application, there's probably no need for GCM to provide settings for a > default "softproofing" colorspace. Right. I don't think a "default softproofing device" makes much sense when you're aiming the feature at things like print preview. A "default softproofing device" might make sense as a per-application option if you're proofing to a PDF or something, although that sounds all very application specific. > Now you already said thats probably a per-application thing. I'm just trying > to wrap my head around where the current GCM "softproof" intent setting > comes into play, what users are choosing with it exactly (like I said, my > assuption was it is the image -> device being simulated transform, in which > case it makes sense to expose all four intents), and how it > interacts/relates to the "display" intent setting (which should then > actually be ignored for softproofing by an application). I'm guessing it's just choosing where to put the line. I would argue that asking the user what rendering mode they want to use for a print preview is overboard, as you could just choose a good default and use that. Similarly for rendering random RGB spaces to the desktop, perceptual is probably the best plan. You could argue, the rendering intents should be hardcoded in the application, or just in GSettings/DBus and not in the UI, and I might agree with you. GCM is just trying to find the sweet pot between options-city and not-enough-control-to-be-useful. I still don't mind drastically changing the UI or DBus interface if we need to. If you've got any better ideas about what should be in the UI (BPC?) as a sensible per-session default then I'm interested. You could also argue that dispcalGUI and GCM should be working closer together in this respect, and I'm open for suggestions. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 14:21:29 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 16:21:29 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: <4C2DF5E9.6060203@hoech.org> Am 02.07.2010 14:58, schrieb Richard Hughes: > Right. I don't think a "default softproofing device" makes much sense > when you're aiming the feature at things like print preview. A > "default softproofing device" might make sense as a per-application > option if you're proofing to a PDF or something, although that sounds > all very application specific. I think I agree on this. > I'm guessing it's just choosing where to put the line. I would argue > that asking the user what rendering mode they want to use for a print > preview is overboard, as you could just choose a good default and use > that. Similarly for rendering random RGB spaces to the desktop, > perceptual is probably the best plan. Right. My concern is more if applications (or rather developers) then know to do the "right thing" when they query GCM for the current "softproof" setting to do a print preview, which would be, "convert image with user selected GCM 'softproof' intent to device space, then absolute colorimetrically to the display" - we don't want gamut mapping to happen twice, that would invalidate the print preview. Of course matrix profiles only support colorimetric either way. Still, it's something to keep in mind. > If you've got any better ideas about what should be in the UI (BPC?) > as a sensible per-session default then I'm interested. You could also > argue that dispcalGUI and GCM should be working closer together in > this respect, and I'm open for suggestions. Personally I'd probably label the current "softproof" intent setting as "print preview" or something along the line. And I think adding an option for BPC would indeed be a nice touch. Rather than adding a checkbox or other additional control, just another intent "Relative with black point compensation" could be added to the dropdown lists. Re making dispcalGUI and GCM work closer together: Sure, it's an option. I wouldn't limit it to dispcalGUI though as other screen calibration/profiling solutions may exist in future (I hear LProf was/is planning to have a measurement capability, but I have to admit I'm not really well informed in that regard). Some wild thinking: Users can already choose their preferred applications for different filetypes/tasks. Maybe in the future, users can choose the preferred calibration solution in a similar way? Although right now, it's probably over the top, as only dispcalGUI and GCM exist as viable options afaik :) (and of course, directly using the Argyll tools on the commandline) Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 14:56:18 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 15:56:18 +0100 Subject: Conceptual questions In-Reply-To: <4C2DF5E9.6060203@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: On 2 July 2010 15:21, Florian H?ch wrote: > Personally I'd probably label the current "softproof" intent setting as > "print preview" or something along the line. Yes, good idea, I've done this in git master. > And I think adding an option for BPC would indeed be a nice touch. Rather > than adding a checkbox or other additional control, just another intent > "Relative with black point compensation" could be added to the dropdown > lists. Do we every want to do relative /without/ BPC? > Some wild thinking: Users can already choose their preferred > applications for different filetypes/tasks. Maybe in the future, users can > choose the preferred calibration solution in a similar way? Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and GcmCalibrateManual, and it would be pretty easy to make that pluggable using GIO extension points. One for the future perhaps. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 15:07:33 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 17:07:33 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: <4C2E00B5.80403@hoech.org> Am 02.07.2010 16:56, schrieb Richard Hughes: > On 2 July 2010 15:21, Florian H?ch wrote: >> Personally I'd probably label the current "softproof" intent setting as >> "print preview" or something along the line. > > Yes, good idea, I've done this in git master. Nice! >> And I think adding an option for BPC would indeed be a nice touch. Rather >> than adding a checkbox or other additional control, just another intent >> "Relative with black point compensation" could be added to the dropdown >> lists. > > Do we every want to do relative /without/ BPC? For proofing, without BPC is a must of course. But for image -> arbitrary display/output space, defaulting to BPC "on" for relative colorimetric seems to be the right choice (and will surely avoid some "why are my blacks crushed" cries from users :)). >> Some wild thinking: Users can already choose their preferred >> applications for different filetypes/tasks. Maybe in the future, users can >> choose the preferred calibration solution in a similar way? > > Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and > GcmCalibrateManual, and it would be pretty easy to make that pluggable > using GIO extension points. One for the future perhaps. Cool. I agree it's still a bit early. > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 15:26:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 16:26:11 +0100 Subject: Conceptual questions In-Reply-To: <4C2E00B5.80403@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: On 2 July 2010 16:07, Florian H?ch wrote: > For proofing, without BPC is a must of course. But for image -> arbitrary > display/output space, defaulting to BPC "on" for relative colorimetric seems > to be the right choice (and will surely avoid some "why are my blacks > crushed" cries from users :)). So, for 'Print Preview' these make sense: perceptual relative-colormetric relative-colormetric-bpc saturation absolute-colormetric and for 'Display': perceptual relative-colormetric saturation absolute-colormetric I'm not completely sure of all the nuances of BPC myself, so I would certainly appreciate any pointers and corrections. Thanks. Richard From lists+gnome-color-manager at hoech.org Fri Jul 2 16:10:36 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 18:10:36 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: <4C2E0F7C.4010202@hoech.org> Am 02.07.2010 17:26, schrieb Richard Hughes: > On 2 July 2010 16:07, Florian H?ch wrote: >> For proofing, without BPC is a must of course. But for image -> arbitrary >> display/output space, defaulting to BPC "on" for relative colorimetric seems >> to be the right choice (and will surely avoid some "why are my blacks >> crushed" cries from users :)). > > So, for 'Print Preview' these make sense: > > perceptual > relative-colormetric > relative-colormetric-bpc > saturation > absolute-colormetric > > and for 'Display': > > perceptual > relative-colormetric > saturation > absolute-colormetric > > I'm not completely sure of all the nuances of BPC myself, so I would > certainly appreciate any pointers and corrections. Thanks. Actually, for both print preview and display BPC can make sense, it all depends on the combinations involved (always assuming the print preview intent is for the image -> simulated device transform, not the simulated device -> display transform). The key is when print preview is used, the transform to the display must not use BPC (or perceptual/saturation). But when print preview is not used, then BPC makes a lot of sense for display imho, to avoid crushed blacks (e.g. conversion from a working space like AdobeRGB with 'zero' blackpoint to a display profile with 'lighter' blackpoint). I hope I'm making sense. -- Florian H?ch http://hoech.net From graeme2 at argyllcms.com Sat Jul 3 02:11:43 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Sat, 03 Jul 2010 12:11:43 +1000 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <4C2E9C5F.3080208@argyllcms.com> Richard Hughes wrote: > Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? You can always try and talk sense into them, but it seemed a wild decision to begin with, and therefore much harder to back down from.. [I doubt that the Firefox CMM is faster than a GPU. It may not even be faster than Argyll's cctiff/imdi, in spite of them using assembler.] Graeme Gill. From jorge.fabregas at gmail.com Sat Jul 3 13:59:42 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Sat, 3 Jul 2010 09:59:42 -0400 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <201007030959.43042.jorge.fabregas@gmail.com> On Friday 02 July 2010 08:39:52 Pascal de Bruijn wrote: > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. I see. Thanks Pascal! All the best, Jorge From hughsient at gmail.com Mon Jul 5 16:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 5 Jul 2010 17:44:10 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:25, Richard Hughes wrote: > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. Thanks to Neil Roberts who has added the required 3D texture support to clutter, I've got a mutter tree on my system that does full screen color management with a simple shader on the GPU. I've also added some demo code to GCM, although it's a standalone program and needs the cogl-texture-3d branch of clutter installed to even compile. Now, I have to fix the remaining bugs in mutter to enable this stuff, and then we have to work out how to mask bits of windows that are already color managed. Net color spec already exists, but isn't very friendly to a composited desktop that isn't compiz, i.e. not rendering to a flat rectangle of pixels. It's also not very toolkit friendly. Richard. From jorge.fabregas at gmail.com Tue Jul 6 12:58:56 2010 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Tue, 6 Jul 2010 08:58:56 -0400 Subject: Wallpaper & Icons on GNOME Desktop Message-ID: <201007060858.56709.jorge.fabregas@gmail.com> Hello everyone, I'm just curious: If you use Gnome Color Manager to create/use/load your ICC monitor profile... Will the GNOME desktop itself take into consideration the monitor profile so that I can render the icons & wallpaper accordingly? Thanks, Jorge From pmjdebruijn at pcode.nl Tue Jul 6 15:26:15 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 6 Jul 2010 17:26:15 +0200 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: <201007060858.56709.jorge.fabregas@gmail.com> References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: 2010/7/6 Jorge F?bregas : > Hello everyone, > > I'm just curious: If you use Gnome Color Manager to create/use/load your ICC > monitor profile... Will the GNOME ?desktop itself ?take into consideration the > monitor profile so that I can render the icons & wallpaper accordingly? Nope... Only specific applications are fully color managed (GIMP, Inkscape, F-Spot, Darktable, UFRaw)... Though a good display profile consist of two part: - VideoLUT which is mostly white point correction and gamma correction - XYZ Matrix which is color correction The VideoLUT is applied by the video driver, so everything benefits from this... The XYZ Matrix is only used by color managed applications which are properly configured... For example GIMP has this disabled by default, it can easily be enabled from it's Preferences. Regards, Pascal de Bruijn From jorge.fabregas at gmail.com Thu Jul 8 02:30:11 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Wed, 7 Jul 2010 22:30:11 -0400 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: <201007072230.12136.jorge.fabregas@gmail.com> On Tuesday 06 July 2010 11:26:15 Pascal de Bruijn wrote: > Nope... Only specific applications are fully color managed (GIMP, > Inkscape, F-Spot, Darktable, UFRaw)... Ok. > Though a good display profile consist of two part: > > - VideoLUT which is mostly white point correction and gamma correction > - XYZ Matrix which is color correction Yes, I had to read many articles about the difference between monitor calibration and profiling (and how many people new to CMS confuse both). > The VideoLUT is applied by the video driver, so everything benefits from > this... I see. I get it now. And indeed I notice a BIG difference on my overall desktop when I load the ICC profile. The change on visual appearance of my screen - when the calibration-part gets loaded (gamma & white-point correction) - is considerably higher than the changes made when a color-managed app takes into consideration the profile part (color correction). > The XYZ Matrix is only used by color managed applications which are > properly configured... I see, so the GNOME desktop (and practically anything X-related) takes advantage of the information stored on the VideoLUT but I won't see anything color-corrected (from the profiling part of the ICC) until a capable app is configured to do so. Thank you very much Pascal ! I really appreciate your help. All the best, Jorge From alexandre.prokoudine at gmail.com Thu Jul 15 23:46:59 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Fri, 16 Jul 2010 03:46:59 +0400 Subject: gcm not working for second logged in user Message-ID: Hi, It was reported earlier on IRC that g-c-m doesn't work for the second logged in user -- the applet starts and then closes itself. The user who reported that moved from 2.31.1 back to 2.30.0(-0ubuntu3) and still experiences the issue. Here is the current log, for 2.30: http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 11:34:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 12:34:24 +0100 Subject: libcolor-glib Message-ID: I've just merged a pretty big branch into GCM git master. libcolor-glib is a new library to be used pretty much exclusively by GCM. It's not designed to be used by end-user-applications like gimp and darktable, but instead just by gnome-color-manager and any additional tools that ISV's want to build. End user applications should continue to use the DBus interface which has not changed. libcolor-glib is starting to grow in functionality, and some of the core new pieces are: * Userspace DDC control, so we can control things like the HP DreamColor monitors and upload custom color spaces. * In-process colorimeter reading. The last point is interesting. I wanted to put the calibration routines in process, so we can get rid of that crappy VTE window, output scraping and all the popups from that. It would also allow us to do ambient lighting control like the windows tools do. This would however mean using argyll as a library (which it isn't) and also using argyll "headless", i.e. without a VTE. Argyll doesn't work very well without a console attached to it. Argyll is also AGPLv3, so can't be run in process with a GPLv2+ program. So, I've spent a couple of evenings reverse engineering the HUEY device. I needed a MIT licensed version of this code for another project I'm working on, and so including it in GCM as LGPLv2+ seemed obvious. The GcmSensorHuey object kinda works now, although I've made some very large guesses and approximations, and the XYZ color only *just* bears some resemblance to reality. The ambient light sensor does however work reliably, although I had to work out a fudge factor using my ColorMunki, so isn't exactly precise. If you know anything technical about the hardware, I'm all ears. So, for the next release if you're using a Huey and gcm-picker, you get the GCM in-process native driver. Anything else (including the ColorMunki) you get to use argyll like normal. Calibration is still always done with argyll, as generating a ICC profile is a little more involved that just getting a few XYZ values. So, a few Q&A's: Q: Do I intend on making other native drivers for other hardware A: No, as I don't have the hardware. I might make bits of the ColorMunki work like the ambient light sensor, although I'm having problems getting traces from the windows driver. Q: Are the GcmSensorHuey values accurate? A: No. If we know a bit more about the hardware we can reduce the amount of futzing and bodging we do. When my head recovers (reverse engineering is hard...) I'll take a look and see if we're doing anything batshit insane. Q: Can we help by copying the logic out of the decompiled windows driver or from Argyll. A: No. Don't even look at other source code if you want to contribute code as LGPLv2+. Note: it's okay to strace argyll commands, or to record the windows driver usb traffic, and this is what I've been doing. Q: Are you working on a sekret project? A: No. I'm putting a few technical demos together, but nothing sekret. Q: Are you aiming to replace Argyll. A: No. Argyll is a mature project that works really well and is a complete calibration workflow. GCM is a new project that does very limited things. Questions ahoy! :-) Richard. From alexandre.prokoudine at gmail.com Mon Jul 19 11:48:11 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 19 Jul 2010 15:48:11 +0400 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 7/19/10, Richard Hughes wrote: > libcolor-glib is starting to grow in functionality, and some of the > core new pieces are: > > * Userspace DDC control, so we can control things like the HP > DreamColor monitors and upload custom color spaces. > * In-process colorimeter reading. Tell me, are you up to Nobel prize this year? :) That sounds awesome! But I demand details about DDC :) Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 12:33:08 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:33:08 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 12:48, Alexandre Prokoudine wrote: > Tell me, are you up to Nobel prize this year? :) No, but I'm doing a talk at GUADEC and want to show some impressive demos. > That sounds awesome! But I demand details about DDC :) Right. Most of the core DDC logic belongs in the kernel, but a few of the device specific controls probably belong in userspace. The DreamColor display (which I'm hoping will arrive really soon now) will allow us to test and use a 30bit LUT in Xorg, and display wide gamut images. We need to use DDC controls to talk to the engine in the display, and I'm also waiting for more detailed specs to come out of HP. For what it's worth, HP have been very helpful indeed. A lot of the stuff I've been working on recently (GLSL hardware shaders, libcolor-glib) allows us to build a framework that's acceptable to the big-name studios, and keeping to the "just works" GNOME mantra. There's still a lot of work to do, but it's coming on fast now. I would really appreciate any help with the hardware parts, as a color sensor giving "kinda approximate" XYZ values isn't particularly useful. Richard. From pmjdebruijn at pcode.nl Mon Jul 19 12:41:51 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 19 Jul 2010 14:41:51 +0200 Subject: libcolor-glib In-Reply-To: References: Message-ID: On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: > On 19 July 2010 12:48, Alexandre Prokoudine > wrote: >> Tell me, are you up to Nobel prize this year? :) > > No, but I'm doing a talk at GUADEC and want to show some impressive demos. Well it all sounds pretty kick ass... But uh... so you'll be in the Netherlands? 26-30th? Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jul 19 12:53:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:53:21 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 13:41, Pascal de Bruijn wrote: > On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: >> On 19 July 2010 12:48, Alexandre Prokoudine >> wrote: >>> Tell me, are you up to Nobel prize this year? :) >> >> No, but I'm doing a talk at GUADEC and want to show some impressive demos. > > Well it all sounds pretty kick ass... > But uh... so you'll be in the Netherlands? 26-30th? I'll be in the Hague from 24th to the 31st. It would be good to grab a beer or seven. Richard. From hughsient at gmail.com Tue Jul 20 09:00:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 10:00:10 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 16 July 2010 00:46, Alexandre Prokoudine wrote: > http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 I've just fixed this, you want to apply dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Thanks, Richard. From alexandre.prokoudine at gmail.com Tue Jul 20 09:42:52 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Tue, 20 Jul 2010 13:42:52 +0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 7/20/10, Richard Hughes wrote: > On 16 July 2010 00:46, Alexandre Prokoudine > wrote: >> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 > > I've just fixed this, you want to apply > dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Many thanks! Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Tue Jul 20 12:03:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 13:03:56 +0100 Subject: GUADEC Message-ID: I've just finished writing my slides[1] for GUADEC. I'm presenting on the Friday afternoon, see http://www.guadec.org/index.php/guadec/2010/schedConf/program for details. I'm going to be there for the full week. If you grab me at GUADEC, be sure to introduce yourself as I'm really bad with names and faces. :-) Hopefully see some of you there! Richard. [1] I say "writing", but it's mostly all pictures and diagrams... From luto at mit.edu Tue Jul 20 19:06:51 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 20 Jul 2010 15:06:51 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: I have a Dell U2711, which has 10 bits per channel over DisplayPort (although I'm not sure that anything other than i915 can drive 10 bits right now, and even i915 needs bleeding-edge drivers). Can GCM program a 10-bit video card LUT? Also, the U2711 has an internal LUT, although no one seems to know how to program it (even on Windows) or even whether it can be programmed with anything other than a (not-very-good) factory calibration. Richard, did your libcolor-glib work give you any ideas for how to test for DDC control of a LUT on an unknown monitor? I'd be happy to test and fiddle. --Andy From pmjdebruijn at pcode.nl Tue Jul 20 21:58:32 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 20 Jul 2010 23:58:32 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 11:42 AM, Alexandre Prokoudine wrote: > On 7/20/10, Richard Hughes wrote: >> On 16 July 2010 00:46, Alexandre Prokoudine >> wrote: >>> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 >> >> I've just fixed this, you want to apply >> dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x I applied that patch to my 2.31.1 package too... However, I'm still curious then... User 1 logs in: gcm-prefs loads videolut gcm-prefs sets profile atom for user 1 User 2 logs in gcm-prefs loads videolut (from a different profile) gcm-prefs sets profile atom for user 2 User 1 switches back... Won't user 1 now end up the the video lut of the profile of user 2, but still have his own profile's atom set? This obviously won't be a problem if both users use the same profile... Regards, Pascal de Bruijn From hughsient at gmail.com Wed Jul 21 08:26:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:26:38 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 20 July 2010 22:58, Pascal de Bruijn wrote: > User 2 logs in > gcm-prefs loads videolut (from a different profile) > gcm-prefs sets profile atom for user 2 Yes, this is a valid bug. We probably should get our GSD plugin to watch for ConsoleKit changes (the ACTIVE attribute) but really this needs some proper session support. I really don't want to add yet another session process just watching for a session active state change. Better ideas welcome. Richard. From hughsient at gmail.com Wed Jul 21 08:32:50 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:32:50 +0100 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). ?Can GCM > program a 10-bit video card LUT? In theory, yes. I've made the GcmClut object generate the amount of data for each LUT size, but I admit I've never tested it on anything other than 8 bpp. > Also, the U2711 has an internal LUT, although no one seems to know how > to program it (even on Windows) or even whether it can be programmed > with anything other than a (not-very-good) factory calibration. > Richard, did your libcolor-glib work give you any ideas for how to > test for DDC control of a LUT on an unknown monitor? ?I'd be happy to > test and fiddle. Yes. I'm still waiting for me DreamColor monitor to arrive, and that allows a custom colorspace to be uploaded. For your monitor, you probably need to convince the manufacturer to give you the specs, or find a windows tool that calibrates the monitor and then trace that. You always have to be a little but careful sending hardware random data to reverse engineer it. First, the output of "gcm-ddc-util --enumerate" should give us something to work on. Richard. From luto at mit.edu Wed Jul 21 21:09:39 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Wed, 21 Jul 2010 17:09:39 -0400 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 4:32 AM, Richard Hughes wrote: > On 20 July 2010 20:06, Andrew Lutomirski wrote: >> I have a Dell U2711, which has 10 bits per channel over DisplayPort >> (although I'm not sure that anything other than i915 can drive 10 bits >> right now, and even i915 needs bleeding-edge drivers). ?Can GCM >> program a 10-bit video card LUT? > > In theory, yes. I've made the GcmClut object generate the amount of > data for each LUT size, but I admit I've never tested it on anything > other than 8 bpp. > >> Also, the U2711 has an internal LUT, although no one seems to know how >> to program it (even on Windows) or even whether it can be programmed >> with anything other than a (not-very-good) factory calibration. >> Richard, did your libcolor-glib work give you any ideas for how to >> test for DDC control of a LUT on an unknown monitor? ?I'd be happy to >> test and fiddle. > > Yes. I'm still waiting for me DreamColor monitor to arrive, and that > allows a custom colorspace to be uploaded. For your monitor, you > probably need to convince the manufacturer to give you the specs, or > find a windows tool that calibrates the monitor and then trace that. > > You always have to be a little but careful sending hardware random > data to reverse engineer it. First, the output of "gcm-ddc-util > --enumerate" should give us something to work on. gcm-dump-edid says: Monitor name: DELL U2711 Vendor name: Dell Serial number: D971T0471EFL PNP identifier: DEL Size: 60x34 Gamma: 2.200000 gcm-ddc-util --enumerate says: $ sudo ./gcm-ddc-util --enumerate EDID: f3b71e4fd0bf14ac3db509cbc4ba48ba PNPID: DELA055 Model: U2711 0x02 [secondary-degauss] 0x04 [reset-factory-defaults] 0x05 [reset-brightness-and-contrast] 0x06 [reset-factory-geometry] 0x08 [reset-factory-default-color] 0x10 [brightness] 0x12 [contrast] 0x14 [select-color-preset] ( 1 5 8 0 0 ) 0x16 [red-video-gain] 0x18 [green-video-gain] 0x1a [blue-video-gain] 0x52 [saturation] 0x60 [input-source-select] ( 1 3 4 5 0 0 11 ) 0xac [horizontal-frequency] 0xae [vertical-frequency] 0xb2 [unknown] 0xb6 [unknown] 0xc6 [unknown] 0xc8 [unknown] 0xc9 [firmware-version] 0xd6 [dpms-control-(1---on/4---stby)] ( 1 4 5 ) 0xdc [magicbright-(1---text/2---internet/3---entertain/4---custom)] ( 0 2 3 4 5 ) 0xdf [vcp-version] 0xfd [power-led] --control 0xb2 --get doesn't seem to work. This is also suspicious: $ sudo ./gcm-ddc-util --display f3b71e4fd0bf14ac3db509cbc4ba48ba --control vcp-version --get vcp-version is 513, max is 255 I'm not really sure what I'm looking for, though, and I haven't spotted the DreamColor code. (Is it there?) --Andy > > Richard. > From alexdeucher at gmail.com Thu Jul 22 04:12:46 2010 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 22 Jul 2010 00:12:46 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). Can GCM > program a 10-bit video card LUT? FWIW, all radeons (even the original r100) support 10 bit LUTs. Alex From graeme2 at argyllcms.com Thu Jul 22 04:59:52 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 22 Jul 2010 14:59:52 +1000 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: <4C47D048.70702@argyllcms.com> Alex Deucher wrote: > FWIW, all radeons (even the original r100) support 10 bit LUTs. My Nvidia 8600GT has 10 bit LUTs & D/A converters to VGA. I'd imagine that the digital path to the display is only 8 bit though.. Graeme Gill. From hughsient at gmail.com Thu Jul 22 09:16:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 10:16:40 +0100 Subject: Anyone got a huey? Message-ID: Have any of you got a huey and a few minutes? I want to do some comparisons between two dumps to try to find differences and to help reverse engineer it. Yell if you can help. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 10:00:11 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 12:00:11 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: > Have any of you got a huey and a few minutes? I want to do some > comparisons between two dumps to try to find differences and to help > reverse engineer it. Yell if you can help. Got One... What do I need to do? I can get back to you tonight... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 11:45:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 12:45:10 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 11:00, Pascal de Bruijn wrote: > On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >> Have any of you got a huey and a few minutes? I want to do some >> comparisons between two dumps to try to find differences and to help >> reverse engineer it. Yell if you can help. > > Got One... > > What do I need to do? * Build GCM git master from today * Insert the HUEY * ./tools/gcm-dump-sensor * Send me offlist the sensor-dump.txt file it produces. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 13:02:30 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 15:02:30 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:45 PM, Richard Hughes wrote: > On 22 July 2010 11:00, Pascal de Bruijn wrote: >> On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >>> Have any of you got a huey and a few minutes? I want to do some >>> comparisons between two dumps to try to find differences and to help >>> reverse engineer it. Yell if you can help. >> >> Got One... >> >> What do I need to do? > > * Build GCM git master from today > * Insert the HUEY > * ./tools/gcm-dump-sensor > * Send me offlist the sensor-dump.txt file it produces. Would that build on GNOME 2.30.x? Maybe I could try an alpha live cd of sorts, I'll try to work something out... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 13:15:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 14:15:54 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 14:02, Pascal de Bruijn wrote: > Would that build on GNOME 2.30.x? No way. Although, you could probably hack up configure to lower the deps and then _only_ build libcolor-glib and the tools. That might work. > Maybe I could try an alpha live cd of sorts, I'll try to work something out... Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds and then installing http://people.freedesktop.org/~hughsient/fedora/13/i386/ should probably work. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 16:30:47 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 18:30:47 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 3:15 PM, Richard Hughes wrote: > On 22 July 2010 14:02, Pascal de Bruijn wrote: >> Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > >> Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds > and then installing > http://people.freedesktop.org/~hughsient/fedora/13/i386/ should > probably work. Well, I got a whole lot of won't boot :) I could bring the Huey with me next Friday to GUADEC so you can check it out yourself? Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 16:53:46 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 17:53:46 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 17:30, Pascal de Bruijn wrote: > I got a whole lot of won't boot :) Hah! Welcome to rawhide ;-) > I could bring the Huey with me next Friday to GUADEC so you can check > it out yourself? That would be good, thanks. It only takes about 2 seconds to dump all the registers. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 17:11:55 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 19:11:55 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: > On 20 July 2010 22:58, Pascal de Bruijn wrote: >> User 2 logs in >> gcm-prefs loads videolut (from a different profile) >> gcm-prefs sets profile atom for user 2 > > Yes, this is a valid bug. We probably should get our GSD plugin to > watch for ConsoleKit changes (the ACTIVE attribute) but really this > needs some proper session support. I really don't want to add yet > another session process just watching for a session active state > change. Well it's a very rare use case tho... Since screen calibration is inherently a system properly and not really a user thing... It could become a user thing when two users disagree on what gamma/white point should be profiled against... But then again, there isn't that much debate about this, and even so, a single shop will standardize to a single setting... Though technically it's a bug that could be hit and produce some really funky shit :) Regards, Pascal de Bruijn From andy at luto.us Thu Jul 22 17:40:11 2010 From: andy at luto.us (Andrew Lutomirski) Date: Thu, 22 Jul 2010 13:40:11 -0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: > On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>> User 2 logs in >>> gcm-prefs loads videolut (from a different profile) >>> gcm-prefs sets profile atom for user 2 >> >> Yes, this is a valid bug. We probably should get our GSD plugin to >> watch for ConsoleKit changes (the ACTIVE attribute) but really this >> needs some proper session support. I really don't want to add yet >> another session process just watching for a session active state >> change. > > Well it's a very rare use case tho... > > Since screen calibration is inherently a system properly and not > really a user thing... I disagree. Profiling the monitor is inherently a system thing (presumably it's the *same* monitor for all users). The LUT setting is a different story. One user might want 6500K, another might want 7000K, and a third might want no correction at all for maximum 3D gamut because they know that whatever program they care about is already using a CLUT profile. A fourth user might run dispwin -c themselves and the first user might want their calibration back when they switch back. (Of course, the profile to use depends on the LUT, but that's "just" an implementation detail.) > > It could become a user thing when two users disagree on what > gamma/white point should be profiled against... But then again, there > isn't that much debate about this, and even so, a single shop will > standardize to a single setting... You should get a Lenovo X series laptop. I had to calibrate mine to 6000K because the screen is *so* bad that I lose an annoying amount of brightness and get rather crappy results if I calibrate to anything else. (Last I checked, the calibration GUI doesn't have that setting, so I just did it manually with dispcal.) But I'm not sure there's a problem at all. Don't the two users have their own X servers, and shouldn't the X server restore the LUT on its own? (I *think* that drv-intel 2.9.0 or newer with recent xserver is smart enough.) --Andy From len at math.northwestern.edu Fri Jul 23 15:58:21 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Fri, 23 Jul 2010 10:58:21 -0500 Subject: Fedora version Message-ID: <1279900701.7721.14.camel@localhost> I would liked to try out gnome color management. I am currently using Fedora 12, but I can if necessary upgrade to Fedora 13. I understand that it will be available as a Fedora 14 package, but I wonder if a package is available I could try before that. I can if necessary compile it from source, but that is usually time consuming and requires searching for additional packages. I have used Argyllcms with an Eye One Pro to calibrate/profile my monitor and my printer. Gimp, firefox, and inkscape can use the monitor profile, but there are some difficulties with other applications such as eye of gnome. I've been printing by a complicated method using argyllcms and photoprint. I was hoping an integrated gnome package might allow me to deal with such matters in a straightforward manner. Can you suggest anything to help? P.S. I do have Ubuntu on a laptop, but working from there would be a bit awkward. -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Fri Jul 23 16:12:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Jul 2010 17:12:16 +0100 Subject: Fedora version In-Reply-To: <1279900701.7721.14.camel@localhost> References: <1279900701.7721.14.camel@localhost> Message-ID: On 23 July 2010 16:58, Leonard Evens wrote: > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > 13. ?I understand that it will be available as a Fedora 14 package, but > I wonder if a package is available I could try before that. Just update to fedora 13. It's included by default. Richard. From marek at matulka.net Fri Jul 23 16:22:23 2010 From: marek at matulka.net (Marek Matulka) Date: Fri, 23 Jul 2010 17:22:23 +0100 Subject: Fedora version In-Reply-To: References: <1279900701.7721.14.camel@localhost> Message-ID: <1279902143.2667.32.camel@localhost> On Fri, 2010-07-23 at 17:12 +0100, Richard Hughes wrote: > On 23 July 2010 16:58, Leonard Evens wrote: > > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > > 13. I understand that it will be available as a Fedora 14 package, but > > I wonder if a package is available I could try before that. > > Just update to fedora 13. It's included by default. how do I get a ?calibrate? functionality? I have a Fedora 13 installed, with argyllcms and all required packages, I can do calibration manually from the command line, but not through gnome-color-management package... I use Spyder 2. Thanks, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From knizek.confy at volny.cz Sun Jul 25 06:29:02 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sun, 25 Jul 2010 08:29:02 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: <1280039342.4370.22.camel@localhost> Richard Hughes p??e v ?t 22. 07. 2010 v 14:15 +0100: > On 22 July 2010 14:02, Pascal de Bruijn wrote: > > Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > > > Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds It does not boot for me either (cannot mount /dev/mapper/live-rw filesystem), I may try in a week time again. BTW, I have got a huey, which was delivered with wide-gamut Samsung XL20. There was a discussion on argyllcms list whether it is somehow modified or not compared to a standard huey. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Sun Jul 25 13:21:15 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 25 Jul 2010 14:21:15 +0100 Subject: Anyone got a huey? In-Reply-To: <1280039342.4370.22.camel@localhost> References: <1280039342.4370.22.camel@localhost> Message-ID: On 25 July 2010 07:29, Milan Kn??ek wrote: > There was a discussion on argyllcms list whether it is somehow > modified or not compared to a standard huey. I would be very interested in the dump, although I know GCM is kinda hard to install at the moment. Richard. From amluto at gmail.com Sun Jul 25 13:35:50 2010 From: amluto at gmail.com (Andy Lutomirski) Date: Sun, 25 Jul 2010 09:35:50 -0400 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: I'll send the patch I used later on. It's enough to build libcolor-glib (sans gcm-brightness) and the tools. --Andy On Jul 25, 2010, at 9:21 AM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list From knizek.confy at volny.cz Mon Jul 26 07:55:12 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 09:55:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: <1280130912.5411.3.camel@localhost> Richard Hughes p??e v Ne 25. 07. 2010 v 14:21 +0100: > On 25 July 2010 07:29, Milan Kn??ek wrote: > > There was a discussion on argyllcms list whether it is somehow > > modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Would it help to install Fedora 13 and compile on it? Or install Fedora 13 and upgrade to current development version ("rawhide" - is there a howto?)? P.S. I am used to Archlinux and Ubuntu, hence sorry for beginner's questions. regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at MIT.EDU Mon Jul 26 14:41:36 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:41:36 -0400 Subject: [PATCH] Make -Werror command-line configurable Message-ID: <1280155296-1270-1-git-send-email-luto@mit.edu> -Werror is already enabled by --enable-strict (default) and GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do that and don't hardcode it. --- Hi all- This is my first of two patches for building libcolor-glib on F13. This one is probable suitable for the real tree. The second one is way too hackish. --Andy configure.ac | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d34767d..7572ee1 100644 --- a/configure.ac +++ b/configure.ac @@ -51,7 +51,7 @@ LT_INIT AM_PROG_CC_C_O IT_PROG_INTLTOOL([0.35.0]) -GNOME_COMPILE_WARNINGS +GNOME_COMPILE_WARNINGS(error) GNOME_DOC_INIT # set up gtk-doc @@ -91,7 +91,6 @@ CPPFLAGS="$CPPFLAGS -DGSEAL_ENABLE" if test "$GCC" = "yes"; then WARNINGFLAGS_C="$WARNINGFLAGS_C -Wall" - WARNINGFLAGS_C="$WARNINGFLAGS_C -Werror" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wcast-align -Wno-uninitialized" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wmissing-declarations" # WARNINGFLAGS_C="$WARNINGFLAGS_C -Wredundant-decls" -- 1.7.1.1 From luto at MIT.EDU Mon Jul 26 14:45:02 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:45:02 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 Message-ID: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> This patch, if configured with ./configure --enable-compile-warnings=yes --disable-sane --disable-strict is enough to build libcolor-glib and most of tools. (You'll have to cd explicitly -- 'make libcolor-glib' doesn't do anything.) --- configure.ac | 16 ++++---- libcolor-glib/gcm-brightness.c | 80 +------------------------------------- libcolor-glib/gcm-sensor-huey.c | 4 +- libcolor-glib/gcm-usb.c | 11 ++--- 4 files changed, 18 insertions(+), 93 deletions(-) diff --git a/configure.ac b/configure.ac index 7572ee1..8a5c64b 100644 --- a/configure.ac +++ b/configure.ac @@ -134,20 +134,20 @@ GLIB_GSETTINGS dnl --------------------------------------------------------------------------- dnl - Check library dependencies dnl --------------------------------------------------------------------------- -PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.9) +PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.24) PKG_CHECK_MODULES(XORG, xxf86vm xrandr) -PKG_CHECK_MODULES(GTK, gtk+-3.0 >= 2.90.3) -PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) +PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.20) +#PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) PKG_CHECK_MODULES(GUDEV, gudev-1.0) PKG_CHECK_MODULES(LCMS, lcms2) PKG_CHECK_MODULES(X11, x11) PKG_CHECK_MODULES(USB, [libusb-1.0 >= 1.0.0]) dnl Required for the properties window -PKG_CHECK_MODULES(CONTROL_CENTER, [ - libgnome-control-center >= 2.31.4]) -PANELS_DIR="${libdir}/control-center-1/panels" -AC_SUBST(PANELS_DIR) +#PKG_CHECK_MODULES(CONTROL_CENTER, [ + #libgnome-control-center >= 2.31.4]) +#PANELS_DIR="${libdir}/control-center-1/panels" +#AC_SUBST(PANELS_DIR) dnl **** Check for VTE **** PKG_CHECK_MODULES(VTE, vte3 >= 0.25.1, has_vte=yes, has_vte=no) @@ -195,7 +195,7 @@ if test x$enable_exiv = xyes; then AC_DEFINE(HAVE_EXIV,1,[Use EXIV support for detecting scanners]) fi -PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) +#PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) PKG_CHECK_MODULES(EXIF, libexif) AC_CHECK_LIB(tiff, TIFFReadRGBAImageOriented, diff --git a/libcolor-glib/gcm-brightness.c b/libcolor-glib/gcm-brightness.c index 3785e50..251810a 100644 --- a/libcolor-glib/gcm-brightness.c +++ b/libcolor-glib/gcm-brightness.c @@ -47,7 +47,7 @@ static void gcm_brightness_finalize (GObject *object); struct _GcmBrightnessPrivate { guint percentage; - GDBusConnection *connection; + void *connection; }; enum { @@ -68,43 +68,7 @@ G_DEFINE_TYPE (GcmBrightness, gcm_brightness, G_TYPE_OBJECT) gboolean gcm_brightness_set_percentage (GcmBrightness *brightness, guint percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *args = NULL; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - g_return_val_if_fail (percentage <= 100, FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - args = g_variant_new ("(u)", percentage), - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "SetBrightness", - args, - NULL, - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* success */ - ret = TRUE; -out: - if (args != NULL) - g_variant_unref (args); - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** @@ -113,45 +77,7 @@ out: gboolean gcm_brightness_get_percentage (GcmBrightness *brightness, guint *percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "GetBrightness", - NULL, - G_VARIANT_TYPE ("(u)"), - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* get the brightness */ - g_variant_get (response, "(u)", &priv->percentage); - - /* copy if set */ - if (percentage != NULL) - *percentage = priv->percentage; - - /* success */ - ret = TRUE; -out: - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** diff --git a/libcolor-glib/gcm-sensor-huey.c b/libcolor-glib/gcm-sensor-huey.c index 63ede01..3778266 100644 --- a/libcolor-glib/gcm-sensor-huey.c +++ b/libcolor-glib/gcm-sensor-huey.c @@ -363,7 +363,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to send request: %s", libusb_strerror (retval)); + "failed to send request"); goto out; } @@ -377,7 +377,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to get reply: %s", libusb_strerror (retval)); + "failed to get reply"); goto out; } diff --git a/libcolor-glib/gcm-usb.c b/libcolor-glib/gcm-usb.c index 891ff0f..85a5c87 100644 --- a/libcolor-glib/gcm-usb.c +++ b/libcolor-glib/gcm-usb.c @@ -301,8 +301,7 @@ gcm_usb_load (GcmUsb *usb, GError **error) if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to init libusb: %s", - libusb_strerror (retval)); + "failed to init libusb"); goto out; } @@ -375,8 +374,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to set configuration 0x%02x: %s", - configuration, libusb_strerror (retval)); + "failed to set configuration 0x%02x", + configuration); ret = FALSE; goto out; } @@ -384,8 +383,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to claim interface 0x%02x: %s", - interface, libusb_strerror (retval)); + "failed to claim interface 0x%02x", + interface); ret = FALSE; goto out; } -- 1.7.1.1 From hughsient at gmail.com Mon Jul 26 15:17:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:17:21 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 22 July 2010 18:40, Andrew Lutomirski wrote: > On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: >> On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >>> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>>> User 2 logs in >>>> gcm-prefs loads videolut (from a different profile) >>>> gcm-prefs sets profile atom for user 2 >>> >>> Yes, this is a valid bug. We probably should get our GSD plugin to >>> watch for ConsoleKit changes (the ACTIVE attribute) but really this >>> needs some proper session support. I really don't want to add yet >>> another session process just watching for a session active state >>> change. >> >> Well it's a very rare use case tho... commit dbebdeaeda3e9d48d5fa61bd9a2cd334fb61a4ce Author: Richard Hughes Date: Mon Jul 26 16:49:50 2010 +0100 Add a gnome-settings-daemon module to fix some hard to fix bugs This allows us to: 1) set gcm-apply when we switch users, so the correct VCGT is used 2) open the calibration window when a colorimeter is plugged in :100644 100644 0121d84... 3dcc91b... M Makefile.am :100644 100644 aa540d6... b030aba... M configure.ac :100644 100644 efdf3d4... c6cee42... M contrib/gnome-color-manager.spec.in :000000 100644 0000000... 0c620eb... A session/.gitignore :000000 100644 0000000... cba7279... A session/Makefile.am :000000 100644 0000000... fb6ec82... A session/color.gnome-settings-plugin :000000 100644 0000000... 312188e... A session/egg-console-kit.c :000000 100644 0000000... 2d897f1... A session/egg-console-kit.h :000000 100644 0000000... cc86414... A session/gsd-color-manager.c :000000 100644 0000000... 0c70ef5... A session/gsd-color-manager.h :000000 100644 0000000... 3883953... A session/gsd-color-plugin.c :000000 100644 0000000... d72b4bd... A session/gsd-color-plugin.h :100644 100644 a8848e8... 844c0b8... M src/Makefile.am :100644 100644 9b53705... 99aa7f2... M src/gcm-apply.c Richard. From hughsient at gmail.com Mon Jul 26 15:48:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:48:43 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: On 26 July 2010 15:45, Andy Lutomirski wrote: > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. ?(You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) Yup. Gross. :-) but thanks for posting. Richard. From hughsient at gmail.com Mon Jul 26 15:50:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:50:23 +0100 Subject: [PATCH] Make -Werror command-line configurable In-Reply-To: <1280155296-1270-1-git-send-email-luto@mit.edu> References: <1280155296-1270-1-git-send-email-luto@mit.edu> Message-ID: On 26 July 2010 15:41, Andy Lutomirski wrote: > -Werror is already enabled by --enable-strict (default) and > GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do > that and don't hardcode it. Applied, thanks. Richard. From pmjdebruijn at pcode.nl Mon Jul 26 18:31:12 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 26 Jul 2010 20:31:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On Sun, Jul 25, 2010 at 3:21 PM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Kinda is a bit of an understatement :p Anyhow, there's another easy and nasty way to solve this... Can't you provide fully statically built versions of the utils? I can get you a DDC dump of my display as well... Regards, Pascal de Bruijn From knizek.confy at volny.cz Mon Jul 26 19:32:35 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 21:32:35 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: <1280172755.4389.13.camel@localhost> Andy Lutomirski p??e v Po 26. 07. 2010 v 10:45 -0400: > This patch, if configured with > > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. (You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) The patch applied with errors on configure.ac, I updated it manually accordingly. However, there are still missing lcms2 and libusb-1.0 packages in Fedora 13 repositories. I have removed the version requirements for the two, but compilation afterwards failed on some libusb matters. As Pascal suggested, could someone skilled provide the necessary binaries compiled statically so that we can send the sensor data? Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Mon Jul 26 23:22:31 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:22:31 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280172755.4389.13.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: On 26 July 2010 20:32, Milan Kn??ek wrote: > As Pascal suggested, could someone skilled provide the necessary > binaries compiled statically so that we can send the sensor data? Grab the packages from http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/ and rebuild them. They should work okay on F12/13. Richard. From hughsient at gmail.com Mon Jul 26 23:25:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:25:02 +0100 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On 26 July 2010 19:31, Pascal de Bruijn wrote: > Can't you provide fully statically built versions of the utils? Ick. I'll give this a try, but I think it is made deliberately hard on Fedora. Richard. From len at math.northwestern.edu Mon Jul 26 23:45:28 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Mon, 26 Jul 2010 18:45:28 -0500 Subject: Possible interaction between the Color manager and Argyllcms Message-ID: <1280187928.2019.36.camel@localhost> 1. I am running Fedora 13. dispwin used directly doesn't seem to do what it did previously. I can use dispwin -I Profile_path to install a profile, but it doesn't persist as it did under previous versions of Fedora (including Fedora 12). But, I can use the gnome color manager to set the display profile, and that does seem topersist. I wonder if the gnome color management is somehow interfering with way argyllcms ordinarily works. 2. In using the color manager to profile a laptop (running Ubuntu 10.4) screen, and using my Eye One Pro, I encountered some problems. The Eye-One Pro has to be calibrated on its base, but the color manager doesn't ask me to do that. In order to get it done, I have to press Details, which brings up the usual argyllcms command line interface. But it is not clear exactly what I am supposed to do using that interface and what using the color manager. If I understood the intended sequence of events, it might be clearer to me how to proceed. Also, the color manager didn't allow me to do any hardware calibration. Of course, for my laptop screen that is somewhat restricted---the only control is screen brightness. I don't know what will happen when I try this an external monitor with lots of controls. Perhaps I am just supposed to continue in the Details window with argyllcms commands? -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Tue Jul 27 08:55:41 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 09:55:41 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280187928.2019.36.camel@localhost> References: <1280187928.2019.36.camel@localhost> Message-ID: On 27 July 2010 00:45, Leonard Evens wrote: > 1. ?I am running Fedora 13. ?dispwin used directly doesn't seem to do > what it did previously. ? I can use dispwin -I Profile_path ?to install > a profile, but it doesn't persist as it did under previous versions of > Fedora (including Fedora 12). ?But, I can use the gnome color manager to > set the display profile, and that does seem topersist. How do you mean persist? dispwin is probably trying to set the gamma tables in xorg, which GPM is also trying to do. If you want to make GCM just leave everything to argyll, just untick the color tickbox in the GNOME session preferences. > I wonder if the gnome color management is somehow interfering with way > argyllcms ordinarily works. As I understand it, dispwin runs, sets some values and then exits. GCM runs gcm-apply at session start, and then also exits. If you run gcm-prefs, the settings probably get re-applied. I think it's probably a good idea to let GCM actually apply the profile, and use argyll to create the profile. If you dump the generated icc profile somewhere GCM knows about, that should work pretty well. > 2. ?In using the color manager to profile a laptop (running Ubuntu 10.4) > screen, and using my Eye One Pro, I encountered some problems. ?The > Eye-One Pro has to be calibrated on its base, but the color manager > doesn't ask me to do that. ?In order to get it done, I have to press > Details, which brings up the usual argyllcms command line interface. > But it is not clear exactly what I am supposed to do using that > interface and what using the color manager. Ideally we can control the hardware using something other than a VTE window. Using a VTE widget sucks as we always have to try and convert the standard output to something localized and sane. Newer, unreleased, versions of argyll allow us to set an environment variable and get some easier to parse values, but there's no support in GCM for that just yet, as we're waiting for a release. It's likely we just have to add another screenscrape section to deal with the "Please insert the device into the dock" type of thing. Screenscaping sucks, but there's not a lot more we can do. If you supply a "gcm-prefs --verbose" trace whilst you're calibrating I can add the required screenscrape bits. I don't have the hardware myself, although donations are always very welcome. > Also, ?the color manager didn't allow me to do any hardware calibration. > Of course, for my laptop screen that is somewhat restricted---the only > control is screen brightness. ?I don't know what will happen when I try > this an external monitor with lots of controls. ?Perhaps I am just > supposed ?to continue in the Details window with argyllcms commands? Do you mean monitors with a programmable LUT? We're aiming to support these kind of things in the next few months. Monitors that allow custom gamma ramps via DDC/CI are also interesting to me, although specs on those are kinda hard to get. Richard. From knizek.confy at volny.cz Tue Jul 27 12:22:14 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Tue, 27 Jul 2010 14:22:14 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: <1280233334.4390.8.camel@localhost> Thanks both Andrew and Richard for trying to help a Fedora newbie :-) Due to dependency hell with GTK+3 on Fedora 13 (trying to build Richard's SRPM), I finally found a way to upgrade to rawhide and did so. Dependencies are not a problem anymore, but compilation of the current GIT fails (I used Andrew's configure options, since strict checking fails much sooner during the compilation): $ ./configure --enable-compile-warnings=yes --disable-sane --disable-strict ...bla bla ... $ make ... bla bla ... Making all in tools make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' CC gcm_dump_profile-gcm-dump-profile.o CCLD gcm-dump-profile ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to `libusb_strerror' collect2: ld returned 1 exit status make[2]: *** [gcm-dump-profile] Error 1 make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' make: *** [all] Error 2 If I recall correctly, something similar appeared with the sources patched by Andrew to compile on Fedora 13. (Even with libusb1.) Any help? P.S. If I do not get further, I may install Fedora 13 x86_64 and try the Andres's binary instead. -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at mit.edu Tue Jul 27 12:35:03 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 27 Jul 2010 08:35:03 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280233334.4390.8.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > Dependencies are not a problem anymore, but compilation of the current > GIT fails (I used Andrew's configure options, since strict checking > fails much sooner during the compilation): > > $ ./configure --enable-compile-warnings=yes --disable-sane > --disable-strict > ...bla bla ... > $ make > ... bla bla ... > > Making all in tools > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > ?CC ? ? gcm_dump_profile-gcm-dump-profile.o > ?CCLD ? gcm-dump-profile > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > `libusb_strerror' > collect2: ld returned 1 exit status > make[2]: *** [gcm-dump-profile] Error 1 > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > make: *** [all] Error 2 > > > If I recall correctly, something similar appeared with the sources > patched by Andrew to compile on Fedora 13. (Even with libusb1.) Yes. One of my patches removed a few calls to libusb_strerror. That function doesn't exist in Fedora's libusb-1.0. --Andy > > Any help? > > P.S. If I do not get further, I may install Fedora 13 x86_64 and try the > Andres's binary instead. > > -- > Milan Knizek > knizek (dot) confy (at) volny (dot) cz > http://www.milan-knizek.net - About linux and photography (Czech > language only) > > From hughsient at gmail.com Wed Jul 28 06:28:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 07:28:38 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280244947.2019.71.camel@localhost> References: <1280187928.2019.36.camel@localhost> <1280244947.2019.71.camel@localhost> Message-ID: On 27 July 2010 16:35, Leonard Evens wrote: > Under argyllcms, dispwin -I ?xxx.icc is supposed to load the table in > xorg, and create a file .config/olor.jcnf which tells where xxx.icc is located. > ... > But, according to Martin at the argyllcms mailing list, if you compile > argyllcms from source, it works as expected. Right, this makes sense. We don't compile the jncf bits in Fedora as it didn't compile with the system version of yajl, which we need to use in Fedora. It might be fairly easy to make argyll use the system version, in which case I think it's okay to turn on the jncf bits. > The way Argyllcms (and the Xrite software under Windows) works, you make > a series of adjustments to the monitor by using "hardware" controls for > Contrast, Brightness, and RGB values. You use them to set white point, > black point, etc. Argyllcms tells you how far off you are from your > target value in either direction. ?If you get these right, then the > calibration LUT loaded into Xorg is minimal and doesn't really change > screen appearance much. ?Is that what you mean by programmable LUT? No, programmable LUT is where you can send a 3D matrix to the monitor and it does most of the color calibration in hardware. You need a pretty nice monitor like an HP DreamColor to be able ot make use of this feature. GCM doesn't ask the user to set contrast and brightness manually, as ideally we can do this automatically using DDC/CI. That's one of the nice features that's on the TODO. Richard. From hughsient at gmail.com Wed Jul 28 09:02:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 10:02:54 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On 27 July 2010 13:35, Andrew Lutomirski wrote: > Yes. ?One of my patches removed a few calls to libusb_strerror. ?That > function doesn't exist in Fedora's libusb-1.0. Can you give master a go please: commit a4dbe5e6ddf6e96f59826537dbbcc542e7fd5fa1 Author: Richard Hughes Date: Wed Jul 28 11:00:22 2010 +0200 Add gcm-compat.h to deal with unreleased versions of libusb :100644 100644 584ca05... de5cc4b... M configure.ac :100644 100644 71b8c89... 4c6c70d... M libcolor-glib/Makefile.am :000000 100644 0000000... 3e30993... A libcolor-glib/gcm-compat.h :100644 100644 c54a0cc... a5991dc... M libcolor-glib/gcm-sensor-huey.c :100644 100644 b5a628f... 043f832... M libcolor-glib/gcm-usb.c :100644 100644 39ab6b2... a96b102... M libcolor-glib/libcolor-glib.h Thanks, Richard. From jyqvklioo at googlemail.com Wed Jul 28 16:28:23 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 18:28:23 +0200 Subject: color managing libraries Message-ID: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Testing LCMS with photo editing showed noticeable color degradation on operations which should show none. I think I discovered why when I read LCMS documentation. LCMS is madness. It puts everything through the so called "sRGB" color space. For those who are not familiar with this color spare, it is designed to represent what CRT monitors show by default with no color management. It has a tiny color gamut and a discontinuity in gamma correction. (2 segments) LCMS needlessly truncates the gamut of any operation (which is not already in the sRGB color space) by converting colors to that color space unconditionally. Please, stop the madness. Do not use LCMS. Indications I saw in writing from the author (not addressed to me) indicate he is not receptive to acknowledging the poor handling his software does. I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? From hughsient at gmail.com Wed Jul 28 16:37:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 18:37:02 +0200 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 28 July 2010 18:28, wrote: > LCMS is madness. Nahh, I think lcms is actually pretty cool. > It puts everything through the so called "sRGB" color space. I don't think that's true at all, can you point to the docs (or code) that says that? > I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? gnome-color-manager already uses argyll for its calibration needs, and lcms for it's internal pixel conversion stuff. Richard. From jyqvklioo at googlemail.com Wed Jul 28 19:23:50 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 21:23:50 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > > I don't think that's true at all, can you point to the docs (or code) > that says that? I sought the text that gave me this impression and did not find it. It has been years since I read whatever it was. Possibly it was related to an image editing application which used LCMS rather than LCMS itself. The application which I saw the impressively bad results in was Krita. I tested where the source and all settable color spaces were not sRGB. From graeme2 at argyllcms.com Wed Jul 28 23:57:05 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 29 Jul 2010 09:57:05 +1000 Subject: color managing libraries In-Reply-To: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> <20100728212350.0cf065e9@jyqvklioo.googlemail.com> Message-ID: <4C50C3D1.6040804@argyllcms.com> jyqvklioo at googlemail.com wrote: > The application which I saw the impressively bad results in was Krita. > I tested where the source and all settable color spaces were not sRGB. Why jump to the conclusion that it's LCMS ? Color management is complicated. Just like the situation when programming, if it doesn't work the way you expect, the most likely explanation is that you've done something wrong. [From my observations on the lcms mailing list, Marti is very responsive to reports of problems.] Graeme Gill. From alexandre.prokoudine at gmail.com Thu Jul 29 00:17:58 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Thu, 29 Jul 2010 04:17:58 +0400 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 7/28/10, jyqvklioo com> wrote: > Testing LCMS with photo editing showed noticeable color degradation on > operations which should show none. > I think I discovered why when I read LCMS documentation. > > LCMS is madness. > > It puts everything through the so called "sRGB" color space. > For those who are not familiar with this color spare, it is designed to > represent what CRT monitors show by default with no color management. > It has a tiny color gamut and a discontinuity in gamma correction. (2 > segments) > LCMS needlessly truncates the gamut of any operation (which is not already > in the sRGB color space) by converting colors to that color space > unconditionally. My dear jyqvklioo (do you work for a throat sweets manufacturer btw? :-)), I have a suspicion that you are confusing back-end with implementation. If Krita passes everything through sRGB, then it is because either it doesn't allow specifying a different working color space or it does allow that, but you didn't do it. LittleCMS has nothing to do with that. However feel free to prove me wrong and quote the bit from LittleCMS's docs that explicitly confirms your opinion. Alexandre Prokoudine http://libregraphicsworld.org From jyqvklioo at googlemail.com Thu Jul 29 06:47:07 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Thu, 29 Jul 2010 08:47:07 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100729084707.2f47845a@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > I don't think that's true at all, ... You do have experience with LCMS so I consider that in my estimation of odds. That combined with the notes I saw about increased accuracy in LCMS 2 and it being largely new code, I am optimistic and looking forward to trying out applications using LCMS, especially LCMS 2. From knizek.confy at volny.cz Sat Jul 31 07:26:25 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sat, 31 Jul 2010 09:26:25 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: <1280561185.4362.6.camel@localhost> Andrew Lutomirski p??e v ?t 27. 07. 2010 v 08:35 -0400: > On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > > > Dependencies are not a problem anymore, but compilation of the current > > GIT fails (I used Andrew's configure options, since strict checking > > fails much sooner during the compilation): > > > > $ ./configure --enable-compile-warnings=yes --disable-sane > > --disable-strict > > ...bla bla ... > > $ make > > ... bla bla ... > > > > Making all in tools > > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > > CC gcm_dump_profile-gcm-dump-profile.o > > CCLD gcm-dump-profile > > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > > `libusb_strerror' > > collect2: ld returned 1 exit status > > make[2]: *** [gcm-dump-profile] Error 1 > > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > > make: *** [all] Error 2 > > > > > > If I recall correctly, something similar appeared with the sources > > patched by Andrew to compile on Fedora 13. (Even with libusb1.) > > Yes. One of my patches removed a few calls to libusb_strerror. That > function doesn't exist in Fedora's libusb-1.0. Hm, I have not noticed that earlier. After applying those referring to libusb_strerror, the compilation failed in a yet later stage, luckily after ./tools/gcm-dump-sensor. Attached is the dump file from Huey sold together with Samsung SyncMaster XL20. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) -------------- next part -------------- // AUTOMATICALLY GENERATED -- DO NOT EDIT generic-dump-version:1 kind:huey vendor:Gretag-Macbeth AG model:Huey serial-number:75951 device:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.1 huey-dump-version:1 unlock-string:GrMb register[0x00]:0x00 register[0x01]:0x01 register[0x02]:0x28 register[0x03]:0xaf register[0x04]:0x3d register[0x05]:0x3a register[0x06]:0x67 register[0x07]:0x67 register[0x08]:0xba register[0x09]:0xc3 register[0x0a]:0x91 register[0x0b]:0x35 register[0x0c]:0x3c register[0x0d]:0x3b register[0x0e]:0x38 register[0x0f]:0x92 register[0x10]:0x3a register[0x11]:0x86 register[0x12]:0x6c register[0x13]:0x57 register[0x14]:0x3c register[0x15]:0xe1 register[0x16]:0xb3 register[0x17]:0x52 register[0x18]:0x39 register[0x19]:0xd0 register[0x1a]:0x39 register[0x1b]:0xd5 register[0x1c]:0xba register[0x1d]:0x68 register[0x1e]:0x40 register[0x1f]:0xbe register[0x20]:0x3a register[0x21]:0xae register[0x22]:0x52 register[0x23]:0x53 register[0x24]:0x3d register[0x25]:0x8f register[0x26]:0x3c register[0x27]:0x20 register[0x28]:0xff register[0x29]:0xff register[0x2a]:0xff register[0x2b]:0xff register[0x2c]:0xff register[0x2d]:0xff register[0x2e]:0xff register[0x2f]:0xff register[0x30]:0xff register[0x31]:0xff register[0x32]:0x45 register[0x33]:0x2b register[0x34]:0xe7 register[0x35]:0x9f register[0x36]:0x3d register[0x37]:0x39 register[0x38]:0x16 register[0x39]:0x8b register[0x3a]:0xbb register[0x3b]:0x12 register[0x3c]:0xed register[0x3d]:0xef register[0x3e]:0x3c register[0x3f]:0x23 register[0x40]:0xe3 register[0x41]:0x36 register[0x42]:0x3a register[0x43]:0x9e register[0x44]:0xef register[0x45]:0x06 register[0x46]:0x3c register[0x47]:0xd6 register[0x48]:0xfa register[0x49]:0x9f register[0x4a]:0x39 register[0x4b]:0xc1 register[0x4c]:0x79 register[0x4d]:0x37 register[0x4e]:0xba register[0x4f]:0x8d register[0x50]:0x39 register[0x51]:0x53 register[0x52]:0x3a register[0x53]:0x81 register[0x54]:0xf4 register[0x55]:0x46 register[0x56]:0x3d register[0x57]:0x8c register[0x58]:0x5c register[0x59]:0xa7 register[0x5a]:0x45 register[0x5b]:0x18 register[0x5c]:0xa5 register[0x5d]:0x90 register[0x5e]:0xff register[0x5f]:0xff register[0x60]:0xff register[0x61]:0xff register[0x62]:0xff register[0x63]:0xff register[0x64]:0xff register[0x65]:0xff register[0x66]:0xff register[0x67]:0x3c register[0x68]:0x98 register[0x69]:0xa8 register[0x6a]:0x9d register[0x6b]:0x3c register[0x6c]:0x65 register[0x6d]:0x60 register[0x6e]:0x41 register[0x6f]:0x3c register[0x70]:0x65 register[0x71]:0x60 register[0x72]:0x41 register[0x73]:0xff register[0x74]:0x09 register[0x75]:0x71 register[0x76]:0x20 register[0x77]:0x05 register[0x78]:0xff register[0x79]:0xff register[0x7a]:0x47 register[0x7b]:0x72 register[0x7c]:0x4d register[0x7d]:0x62 register[0x7e]:0x00 register[0x7f]:0x0e register[0x80]:0x01 register[0x81]:0x99 register[0x82]:0x69 register[0x83]:0x00 register[0x84]:0x02 register[0x85]:0x20 register[0x86]:0xf4 register[0x87]:0xee register[0x88]:0x02 register[0x89]:0x20 register[0x8a]:0xf4 register[0x8b]:0xee register[0x8c]:0x16 register[0x8d]:0xe4 register[0x8e]:0x00 register[0x8f]:0xff register[0x90]:0xff register[0x91]:0xff register[0x92]:0xff register[0x93]:0xff register[0x94]:0x3a register[0x95]:0x99 register[0x96]:0xc8 register[0x97]:0x02 register[0x98]:0xff register[0x99]:0xff register[0x9a]:0xff register[0x9b]:0xff register[0x9c]:0xff register[0x9d]:0xff register[0x9e]:0xff register[0x9f]:0xff register[0xa0]:0xff register[0xa1]:0xff register[0xa2]:0xff register[0xa3]:0xff register[0xa4]:0xff register[0xa5]:0xff register[0xa6]:0xff register[0xa7]:0xff register[0xa8]:0xff register[0xa9]:0xff register[0xaa]:0xff register[0xab]:0xff register[0xac]:0xff register[0xad]:0xff register[0xae]:0xff register[0xaf]:0xff register[0xb0]:0xff register[0xb1]:0xff register[0xb2]:0xff register[0xb3]:0xff register[0xb4]:0xff register[0xb5]:0xff register[0xb6]:0xff register[0xb7]:0xff register[0xb8]:0xff register[0xb9]:0xff register[0xba]:0xff register[0xbb]:0xff register[0xbc]:0xff register[0xbd]:0xff register[0xbe]:0xff register[0xbf]:0xff register[0xc0]:0xff register[0xc1]:0xff register[0xc2]:0xff register[0xc3]:0xff register[0xc4]:0xff register[0xc5]:0xff register[0xc6]:0xff register[0xc7]:0xff register[0xc8]:0xff register[0xc9]:0xff register[0xca]:0xff register[0xcb]:0xff register[0xcc]:0xff register[0xcd]:0xff register[0xce]:0xff register[0xcf]:0xff register[0xd0]:0xff register[0xd1]:0xff register[0xd2]:0xff register[0xd3]:0xff register[0xd4]:0xff register[0xd5]:0xff register[0xd6]:0xff register[0xd7]:0xff register[0xd8]:0xff register[0xd9]:0xff register[0xda]:0xff register[0xdb]:0xff register[0xdc]:0xff register[0xdd]:0xff register[0xde]:0xff register[0xdf]:0xff register[0xe0]:0xff register[0xe1]:0xff register[0xe2]:0xff register[0xe3]:0xff register[0xe4]:0xff register[0xe5]:0xff register[0xe6]:0xff register[0xe7]:0xff register[0xe8]:0xff register[0xe9]:0xff register[0xea]:0xff register[0xeb]:0xff register[0xec]:0xff register[0xed]:0xff register[0xee]:0xff register[0xef]:0xff register[0xf0]:0xff register[0xf1]:0xff register[0xf2]:0xff register[0xf3]:0xff register[0xf4]:0xff register[0xf5]:0xff register[0xf6]:0xff register[0xf7]:0xff register[0xf8]:0xff register[0xf9]:0xff register[0xfa]:0xff register[0xfb]:0xff register[0xfc]:0xff register[0xfd]:0xff register[0xfe]:0xff From hughsient at gmail.com Sat Jul 31 07:52:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 31 Jul 2010 09:52:45 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280561185.4362.6.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> <1280561185.4362.6.camel@localhost> Message-ID: On 31 July 2010 09:26, Milan Kn??ek wrote: > Attached is the dump file from Huey sold together with Samsung > SyncMaster XL20. Great, thanks. I'll analyze your dump and Pascals after I return from GUADEC. Richard. From hughsient at gmail.com Thu Jul 1 08:37:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 09:37:32 +0100 Subject: GNOME Color Manager 2.31.4 Message-ID: gnome-color-manager is a session program that makes it easy to manage, install and generate color profiles in the GNOME desktop. Version 2.31.4 ~~~~~~~~~~~~~~ Released: 2010-07-01 * Translations - Updated Galician translations (Fran Di?guez) - Updated Spanish translation (Jorge Gonz?lez) - Updated Estonian translation (Mattias P?ldaru) - Updated Hebrew translation (Yaron Shahrabani) - Updated Simplified Chinese translation (?? Gan Lu) * New Features: - Port from lcms to lcms2 (Richard Hughes) - Split gcm-prefs into a control center module and a profile viewer (Richard Hughes) - Add gcm_image_set_abstract_profile() so we can set LAB abstract profiles (Richard Hughes) - Add GcmProfileSearchFlags so we can control what kind of profiles are loaded (Richard Hughes) - Allow passing profile and device types to GetProfilesForType() (Richard Hughes) * Bugfix: - Do not try to convert if the input and output profiles are not RGB (Richard Hughes) - Refuse to import a local profile if it already exists system-wide (Richard Hughes) - Make GcmImage take a GcmProfile, not a base64 string (Richard Hughes) - Depend on gnome-control-center 2.31.4 for GTK 3.0 fixes (Richard Hughes) - Ensure we load the profile store in the DBus service (Richard Hughes) Richard. From gysvanzyl at gmail.com Thu Jul 1 15:31:58 2010 From: gysvanzyl at gmail.com (Gys van Zyl) Date: Thu, 1 Jul 2010 18:31:58 +0300 Subject: Color management in ubuntu Message-ID: Hi all, I have a couple of questions that may be a bit silly due to my beginner level knowledge of color management. I'm an amateur/hobby photographer and I've been using ubuntu for a while (currently using 10.04). For a while now I've realized the importance of having a color managed workflow, but have put off getting the hardware as I thought getting everything installed, set up and configured would be tough in linux. I recently purchased a Pantone Huey monitor calibration device and you could imagine my pleasant surprise when I found how extremely easy everything was to use with gnome color manager. In no time, with almost zero effort I had everything up and running. Kudos to the developer(s) - this is excellent software! So, to test how color management works in a browser, I found this web site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. Using google chrome (a non color managed browser) this page is a mess of incorrectly rendered photo's - I expected this. Using Firefox, things are a lot better - imbedded color profiles are now honored and the photos display fine. However, about half-way down the page at the heading "sRGB / Standard RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged sRGB rollover." In my Firefox window, the change is not minor, and I'm trying to figure out why this is. In my workflow all exif data is stripped from my photo's before I upload to the web. I thought that this wouldn't matter, as long as my final image was created in an sRGB colorspace. However, I have now found that my photo's look subtly but definitely different in the software I use (gimp, digikam) and my browsers. My limited understanding of color management led me to believe that un-tagged sRGB images should look the same in a browser on a color-managed system. However, on my system they don't and its causing a problem for me - my photo's don't display the way I intended. How can I resolve this? Is my understanding wrong, should I educate myself a bit more? Did I do something wrong when I calibrated my monitor? Gys -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmjdebruijn at pcode.nl Thu Jul 1 15:58:07 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 17:58:07 +0200 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 5:31 PM, Gys van Zyl wrote: > Hi all, > I have a couple of questions that may be a bit silly due to my beginner > level knowledge of color management. > I'm an?amateur/hobby photographer and?I've been using ubuntu for a while > (currently using 10.04). ?For a while now I've realized the importance of > having a color managed workflow, but have put off getting the hardware as I > thought getting everything installed, set up and configured would be tough > in linux. ?I recently purchased a Pantone Huey monitor calibration device > and you could imagine my pleasant surprise when I found how extremely easy > everything was to use with gnome color manager. ?In no time, with almost > zero effort I had everything up and running. ?Kudos?to the developer(s) - > this is excellent software! GCM + Argyll is a powerful combination indeed :) > So, to test how color management works in a browser, I found this web > site:?http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > ?Using google chrome (a non color managed browser) this page is a mess of > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a > lot better - imbedded color profiles are now honored and the photos display > fine. However, about half-way down the page at the heading "sRGB / Standard > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm > trying to figure out why this is. > In my workflow all exif data is stripped from my photo's before I upload to > the web. ?I thought that this wouldn't matter, as long as my final image was > created in an sRGB colorspace. ?However, I have now found that my photo's > look subtly but definitely different in the software I use (gimp, digikam) > and my browsers. > My limited understanding of color management led me to believe that > un-tagged sRGB images should look the same in a browser on a color-managed > system. ?However, on my system they don't and its causing a problem for me - > my photo's don't display the way I intended. ?How can I resolve this? ?Is my > understanding wrong, should I educate myself a bit more? ?Did I do something > wrong when I calibrated my monitor? The problem is that being color managed, and being properly configured is not always the same... All color managed applications checked for an embedded profile when loading images and will for example convert an Adobe RGB image to sRGB on request. If an image is untagged sRGB will be assumed. However, if you do not properly configure the application to use your display profile it will be displayed as plain srgb without your display profile applied, hence wrong colors (since only the videolut will have effect). I think GIMP doesn't use the system display profile by default. Firefox also requires the display profile to be configured through "about:config" search for "display_profile". Same goes for lots of other applications. So you will still need to check each an every applications configuration. Since they might use poor defaults. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 16:03:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:03:47 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: On 1 July 2010 16:58, Pascal de Bruijn wrote: > I think GIMP doesn't use the system display profile by default. > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. Could you start to make to a list of applications and the fixes here please: http://live.gnome.org/GnomeColorManager/FAQ -- I think a list would be really useful for users. Then we can file bugs against the programs to use the GCM DBus interface or the ICCPROFILESINX specification and get things just working by default. As for everything else, I normally tag my "web-safe" with sRGB (it's a tiny increase in size, and probably a good idea) and ensure the display profile has been set correctly. Richard. From marek.matulka at gmail.com Thu Jul 1 16:18:57 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:18:57 +0100 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <1278001137.2552.11.camel@localhost> Hello, This is my first post on the group, but I've been following a group for some time. Well done guys for a rocking bit of software giving us a great colour management tool! On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: > > So, to test how color management works in a browser, I found this web > > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. > > Using google chrome (a non color managed browser) this page is a mess of > > incorrectly rendered photo's - I expected this. Using Firefox, things are a > > lot better - imbedded color profiles are now honored and the photos display > > fine. However, about half-way down the page at the heading "sRGB / Standard > > RGB 2.2 gamma" I've come across a problem. This photo is a tagged/untagged > > rollover of an sRGB image. It says that "If your monitor is profiled to 2.2 > > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged > > sRGB rollover." In my Firefox window, the change is not minor, and I'm > > trying to figure out why this is. > > In my workflow all exif data is stripped from my photo's before I upload to > > the web. I thought that this wouldn't matter, as long as my final image was > > created in an sRGB colorspace. However, I have now found that my photo's > > look subtly but definitely different in the software I use (gimp, digikam) > > and my browsers. > > My limited understanding of color management led me to believe that > > un-tagged sRGB images should look the same in a browser on a color-managed > > system. However, on my system they don't and its causing a problem for me - > > my photo's don't display the way I intended. How can I resolve this? Is my > > understanding wrong, should I educate myself a bit more? Did I do something > > wrong when I calibrated my monitor? > > The problem is that being color managed, and being properly configured > is not always the same... > > All color managed applications checked for an embedded profile when > loading images and will for example convert an Adobe RGB image to sRGB > on request. If an image is untagged sRGB will be assumed. > > However, if you do not properly configure the application to use your > display profile it will be displayed as plain srgb without your > display profile applied, hence wrong colors (since only the videolut > will have effect). > > I think GIMP doesn't use the system display profile by default. > > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". > > Same goes for lots of other applications. So you will still need to > check each an every applications configuration. Since they might use > poor defaults. I had similar issue - when I created three images: 1. tagged with Adobe RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly displayed in GIMP, but not in any desktop viewer. I think the problem lies in assumption, that for untagged images viewer should not apply monitor profile, while it should assume sRGB and convert it accordingly. It seems GIMP is working that way hence all three images are correctly displayed. I have filled a bug report against Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=606996 this bug report includes example screenshots of gimp and eog. Although, I am not sure if my assumptions are right, so please correct me, if I am wrong. Greetings, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 16:27:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 17:27:39 +0100 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On 1 July 2010 17:18, Marek Matulka wrote: > Although, I am not sure if my assumptions are right, so please correct > me, if I am wrong. I think this functionality needs to live in the toolkit (e.g. GTK) and done automatically, as the harder applications have to work to do the right thing, the fewer that will actually do it. Richard. From marek.matulka at gmail.com Thu Jul 1 16:42:44 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Thu, 01 Jul 2010 17:42:44 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: <1278002564.2552.12.camel@localhost> On Thu, 2010-07-01 at 17:27 +0100, Richard Hughes wrote: > On 1 July 2010 17:18, Marek Matulka wrote: > > Although, I am not sure if my assumptions are right, so please correct > > me, if I am wrong. > > I think this functionality needs to live in the toolkit (e.g. GTK) and > done automatically, as the harder applications have to work to do the > right thing, the fewer that will actually do it. That would be awesome! Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. From hughsient at gmail.com Thu Jul 1 17:25:52 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:25:52 +0100 Subject: Color management in ubuntu In-Reply-To: <1278002564.2552.12.camel@localhost> References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 17:42, Marek Matulka wrote: > That would be awesome! I've been experimenting with GLSL shaders, and doing the color conversion in hardware on the GPU. We've hit a few stumbing blocks in clutter, but I'm adding API to clutter where required. Using the hardware allows us to do lots of clever interpolation in 3D to make things super sweet. Without using GPU hardware it's quite hard to process high-def video at normal frame rates. Long term this means we can attach a ClutterShader object to different mutter windows and color correct whole windows / subwindows on the GPU. Thatis, unless the application opts out of color managed mode. Or opts in. I'm not sure. There's a net-color-spec that we could use, although this seems very difficult to implement without working on a post-composited display like compiz provides. Either way, unless the ClutterTexture patches get written none of it will work :) Richard. From pmjdebruijn at pcode.nl Thu Jul 1 17:29:17 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:29:17 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: > Hello, > > This is my first post on the group, but I've been following a group for > some time. Well done guys for a rocking bit of software giving us a > great colour management tool! > > On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >> > So, to test how color management works in a browser, I found this web >> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >> > ?Using google chrome (a non color managed browser) this page is a mess of >> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >> > lot better - imbedded color profiles are now honored and the photos display >> > fine. However, about half-way down the page at the heading "sRGB / Standard >> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >> > trying to figure out why this is. >> > In my workflow all exif data is stripped from my photo's before I upload to >> > the web. ?I thought that this wouldn't matter, as long as my final image was >> > created in an sRGB colorspace. ?However, I have now found that my photo's >> > look subtly but definitely different in the software I use (gimp, digikam) >> > and my browsers. >> > My limited understanding of color management led me to believe that >> > un-tagged sRGB images should look the same in a browser on a color-managed >> > system. ?However, on my system they don't and its causing a problem for me - >> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >> > understanding wrong, should I educate myself a bit more? ?Did I do something >> > wrong when I calibrated my monitor? >> >> The problem is that being color managed, and being properly configured >> is not always the same... >> >> All color managed applications checked for an embedded profile when >> loading images and will for example convert an Adobe RGB image to sRGB >> on request. If an image is untagged sRGB will be assumed. >> >> However, if you do not properly configure the application to use your >> display profile it will be displayed as plain srgb without your >> display profile applied, hence wrong colors (since only the videolut >> will have effect). >> >> I think GIMP doesn't use the system display profile by default. >> >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". >> >> Same goes for lots of other applications. So you will still need to >> check each an every applications configuration. Since they might use >> poor defaults. > > I had similar issue - when I created three images: 1. tagged with Adobe > RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly > displayed in GIMP, but not in any desktop viewer. > > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. The tagging of an image has _NOTHING_ to do with applying a display profile or not... If this really is the case, then someone should really be shot for that (not dead... the knees will do just fine :). The application of the display profile (should) only depend on the application settings not on the input image... All programs assume untagged images are sRGB, (even though tagging images with an sRGB profile _is_ a good idea, this will prevent future ambiguity). Programs which aren't color managed (or where color management is disabled) are just RGBin (from file) == RGBout (to display) That said... Please also note that not all forms of sRGB are equal, there are several version of the sRGB profile that might differ a bit... I think at one time there even was a simplified sRGB with a real 2.2 gamma curve... which is wrong, since sRGB is gamma 2.4 with a small dead area in the blacks. Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Thu Jul 1 17:31:02 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:31:02 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:25 PM, Richard Hughes wrote: > On 1 July 2010 17:42, Marek Matulka wrote: >> That would be awesome! > > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. And you need to make the applications aware that they do not need to do their own color management... Otherwise apps like the GIMP might apply an output profile themselves, having the display rgb processed again by the GLSL shaders. Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 1 17:34:17 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 18:34:17 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:31, Pascal de Bruijn wrote: > And you need to make the applications aware that they do not need to > do their own color management... Otherwise apps like the GIMP might > apply an output profile themselves, having the display rgb processed > again by the GLSL shaders. Right. This is why I think it's going to have to be opt-in. In reality, I think we're a long way from pushing this into a distro. Richard From pmjdebruijn at pcode.nl Thu Jul 1 17:38:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 1 Jul 2010 19:38:37 +0200 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> Message-ID: On Thu, Jul 1, 2010 at 7:29 PM, Pascal de Bruijn wrote: > On Thu, Jul 1, 2010 at 6:18 PM, Marek Matulka wrote: >> Hello, >> >> This is my first post on the group, but I've been following a group for >> some time. Well done guys for a rocking bit of software giving us a >> great colour management tool! >> >> On Thu, 2010-07-01 at 17:58 +0200, Pascal de Bruijn wrote: >>> > So, to test how color management works in a browser, I found this web >>> > site: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html. >>> > ?Using google chrome (a non color managed browser) this page is a mess of >>> > incorrectly rendered photo's - I expected this. ?Using Firefox, things are a >>> > lot better - imbedded color profiles are now honored and the photos display >>> > fine. However, about half-way down the page at the heading "sRGB / Standard >>> > RGB 2.2 gamma" I've come across a problem. ?This photo is a tagged/untagged >>> > rollover of an sRGB image. ?It says that "If your monitor is profiled to 2.2 >>> > gamma and D65- 6500 kelvin, there should be minimum change in the Un-tagged >>> > sRGB rollover." ?In my Firefox window, the change is not minor, and I'm >>> > trying to figure out why this is. >>> > In my workflow all exif data is stripped from my photo's before I upload to >>> > the web. ?I thought that this wouldn't matter, as long as my final image was >>> > created in an sRGB colorspace. ?However, I have now found that my photo's >>> > look subtly but definitely different in the software I use (gimp, digikam) >>> > and my browsers. >>> > My limited understanding of color management led me to believe that >>> > un-tagged sRGB images should look the same in a browser on a color-managed >>> > system. ?However, on my system they don't and its causing a problem for me - >>> > my photo's don't display the way I intended. ?How can I resolve this? ?Is my >>> > understanding wrong, should I educate myself a bit more? ?Did I do something >>> > wrong when I calibrated my monitor? >>> >>> The problem is that being color managed, and being properly configured >>> is not always the same... >>> >>> All color managed applications checked for an embedded profile when >>> loading images and will for example convert an Adobe RGB image to sRGB >>> on request. If an image is untagged sRGB will be assumed. >>> >>> However, if you do not properly configure the application to use your >>> display profile it will be displayed as plain srgb without your >>> display profile applied, hence wrong colors (since only the videolut >>> will have effect). >>> >>> I think GIMP doesn't use the system display profile by default. >>> >>> Firefox also requires the display profile to be configured through >>> "about:config" search for "display_profile". >>> >>> Same goes for lots of other applications. So you will still need to >>> check each an every applications configuration. Since they might use >>> poor defaults. >> >> I had similar issue - when I created three images: 1. tagged with Adobe >> RGB, 2. tagged with sRBG, 3. untagged - all three images were correctly >> displayed in GIMP, but not in any desktop viewer. >> >> I think the problem lies in assumption, that for untagged images viewer >> should not apply monitor profile, while it should assume sRGB and >> convert it accordingly. It seems GIMP is working that way hence all >> three images are correctly displayed. > > The tagging of an image has _NOTHING_ to do with applying a display > profile or not... If this really is the case, then someone should > really be shot for that (not dead... the knees will do just fine :). Cutting my own rant short... It's easy for forget (I often do), that color management as a concept is non-obvious for pretty much everybody (including normal coders) who aren't into this stuff... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Thu Jul 1 18:00:09 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 20:00:09 +0200 Subject: Conceptual questions Message-ID: <4C2CD7A9.90409@hoech.org> Hi, I have a few conceptual questions. Currently GCM has preferences for RGB and CMYK working space, and "display" and "softproof" rendering intent. But what I think is missing for softproofing is a checkbox "Simulate media (paper) color" which when checked (which would be a good default), means absolute colorimetric intent should be used, otherwise relative colorimetric (_without_ black point compensation). Is my current understanding of the GCM UI intentions correct as follows: Image -> "display" intent in GCM -> device (for non-softproofing) Image -> "softproof" intent in GCM -> softproof colorspace (is there a way in GCM to choose a default for this?) -> relative without bpc or abscol (it is not clear to me which is used/assumed by GCM by default, I'd think abscol?) -> device Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jul 1 18:23:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Jul 2010 19:23:19 +0100 Subject: Conceptual questions In-Reply-To: <4C2CD7A9.90409@hoech.org> References: <4C2CD7A9.90409@hoech.org> Message-ID: On 1 July 2010 19:00, Florian H?ch wrote: > I think is missing for softproofing is a checkbox "Simulate media (paper) > color" which when checked (which would be a good default), means absolute > colorimetric intent should be used, otherwise relative colorimetric Isn't that a per-application thing, rather than a per-session thing? By "softproof" GCM indicates the proofing mode to use when doing things like print preview. In a print preview aka "softproof" you already know the device you are targeting and the ICC profiles available. I also think it's useful to talk in terms of use-cases, rather than presenting lots of tickyboxes in preferences panels. I've got enough feedback (of the negative kind :-) from my boss about the number of UI elements we expose already. Maybe if we all refer to the three people here http://live.gnome.org/GnomeColorManager#Typical_Users we can all work towards further use-cases and application notes. I do think this is a really important discussion and am really pleased you're onboard. Thanks. Richard. From knizek.confy at volny.cz Thu Jul 1 18:58:16 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 01 Jul 2010 20:58:16 +0200 Subject: Color management in ubuntu In-Reply-To: <1278001137.2552.11.camel@localhost> References: <1278001137.2552.11.camel@localhost> Message-ID: <1278010696.9901.3.camel@athlon> Marek Matulka p??e v ?t 01. 07. 2010 v 17:18 +0100: > I think the problem lies in assumption, that for untagged images viewer > should not apply monitor profile, while it should assume sRGB and > convert it accordingly. It seems GIMP is working that way hence all > three images are correctly displayed. > > I have filled a bug report against Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=606996 > > this bug report includes example screenshots of gimp and eog. > It seems to be a bug like the one reported by me upstream some time ago: https://bugzilla.gnome.org/show_bug.cgi?id=554498 regards, -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From lists+gnome-color-manager at hoech.org Thu Jul 1 19:22:28 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Thu, 01 Jul 2010 21:22:28 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> Message-ID: <4C2CEAF4.9030006@hoech.org> Am 01.07.2010 20:23, schrieb Richard Hughes: > On 1 July 2010 19:00, Florian H?ch wrote: >> I think is missing for softproofing is a checkbox "Simulate media (paper) >> color" which when checked (which would be a good default), means absolute >> colorimetric intent should be used, otherwise relative colorimetric > > Isn't that a per-application thing, rather than a per-session thing? > By "softproof" GCM indicates the proofing mode to use when doing > things like print preview. In a print preview aka "softproof" you > already know the device you are targeting and the ICC profiles > available. Ok, sounds reasonable. If the device/profile being simulated is chosen in the application, there's probably no need for GCM to provide settings for a default "softproofing" colorspace. > I also think it's useful to talk in terms of use-cases, rather than > presenting lots of tickyboxes in preferences panels. I've got enough > feedback (of the negative kind :-) from my boss about the number of UI > elements we expose already. Maybe if we all refer to the three people > here http://live.gnome.org/GnomeColorManager#Typical_Users we can all > work towards further use-cases and application notes. :) don't worry, I'm not keen on having a GCM plastered with checkboxes either. Re use cases: My original inquiry would fit in no. #4 ("An application wants to softproof for a printer device to show the user how the colors are going to be clipped when the file is printed"). Now you already said thats probably a per-application thing. I'm just trying to wrap my head around where the current GCM "softproof" intent setting comes into play, what users are choosing with it exactly (like I said, my assuption was it is the image -> device being simulated transform, in which case it makes sense to expose all four intents), and how it interacts/relates to the "display" intent setting (which should then actually be ignored for softproofing by an application). > I do think this is a really important discussion and am really pleased > you're onboard. Thanks. > > Richard. -- Florian H?ch http://hoech.net From jorge.fabregas at gmail.com Fri Jul 2 12:36:50 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Fri, 2 Jul 2010 08:36:50 -0400 Subject: Color management in ubuntu In-Reply-To: References: Message-ID: <201007020836.50739.jorge.fabregas@gmail.com> On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: > Firefox also requires the display profile to be configured through > "about:config" search for "display_profile". Hello guys, I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary options (gfx.color_management...), restarted Firefox and I still can't see this picture correctly: http://www.color.org/version4html.xalter I see it as if my system only supports "ICC version 2" as the examples shown. I load my ICC profile with "dispwin -L" when my system starts but I'm not sure if its "version 4"? How can I know this? (sorry newbie here when it comes to color management). Thanks, Jorge From pmjdebruijn at pcode.nl Fri Jul 2 12:39:52 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 2 Jul 2010 14:39:52 +0200 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Jorge F?bregas : > On Thursday 01 July 2010 11:58:07 Pascal de Bruijn wrote: >> Firefox also requires the display profile to be configured through >> "about:config" search for "display_profile". > > Hello guys, > > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the necessary > options (gfx.color_management...), restarted Firefox and I still can't see > this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples shown. > I load my ICC profile with "dispwin -L" when my system starts but I'm not sure > if its "version 4"? ?How can I know this? ?(sorry newbie here when it comes to > color management). Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. Firefox 3.5+ uses it's own internal CMS which only processes v2 profiles, but it's faster. Regards, Pascal de Bruijn From marek.matulka at gmail.com Fri Jul 2 12:41:38 2010 From: marek.matulka at gmail.com (Marek Matulka) Date: Fri, 02 Jul 2010 13:41:38 +0100 Subject: Color management in ubuntu In-Reply-To: <201007020836.50739.jorge.fabregas@gmail.com> References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <1278074498.3005.14.camel@localhost> On Fri, 2010-07-02 at 08:36 -0400, Jorge F?bregas wrote: > I'm using Firefox 3.5.10 (Fedora 12) and I just activated the > necessary options (gfx.color_management...), restarted Firefox and I > still can't see this picture correctly: > > http://www.color.org/version4html.xalter > > I see it as if my system only supports "ICC version 2" as the examples > shown. I load my ICC profile with "dispwin -L" when my system starts > but I'm not sure if its "version 4"? How can I know this? (sorry > newbie here when it comes to color management). AFAIK Firefox does not support version 4 yet. Greetings, Marek From hughsient at gmail.com Fri Jul 2 12:49:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:49:55 +0100 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: 2010/7/2 Pascal de Bruijn : > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? Richard. From hughsient at gmail.com Fri Jul 2 12:58:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 13:58:55 +0100 Subject: Conceptual questions In-Reply-To: <4C2CEAF4.9030006@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: On 1 July 2010 20:22, Florian H?ch wrote: > Ok, sounds reasonable. If the device/profile being simulated is chosen in > the application, there's probably no need for GCM to provide settings for a > default "softproofing" colorspace. Right. I don't think a "default softproofing device" makes much sense when you're aiming the feature at things like print preview. A "default softproofing device" might make sense as a per-application option if you're proofing to a PDF or something, although that sounds all very application specific. > Now you already said thats probably a per-application thing. I'm just trying > to wrap my head around where the current GCM "softproof" intent setting > comes into play, what users are choosing with it exactly (like I said, my > assuption was it is the image -> device being simulated transform, in which > case it makes sense to expose all four intents), and how it > interacts/relates to the "display" intent setting (which should then > actually be ignored for softproofing by an application). I'm guessing it's just choosing where to put the line. I would argue that asking the user what rendering mode they want to use for a print preview is overboard, as you could just choose a good default and use that. Similarly for rendering random RGB spaces to the desktop, perceptual is probably the best plan. You could argue, the rendering intents should be hardcoded in the application, or just in GSettings/DBus and not in the UI, and I might agree with you. GCM is just trying to find the sweet pot between options-city and not-enough-control-to-be-useful. I still don't mind drastically changing the UI or DBus interface if we need to. If you've got any better ideas about what should be in the UI (BPC?) as a sensible per-session default then I'm interested. You could also argue that dispcalGUI and GCM should be working closer together in this respect, and I'm open for suggestions. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 14:21:29 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 16:21:29 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> Message-ID: <4C2DF5E9.6060203@hoech.org> Am 02.07.2010 14:58, schrieb Richard Hughes: > Right. I don't think a "default softproofing device" makes much sense > when you're aiming the feature at things like print preview. A > "default softproofing device" might make sense as a per-application > option if you're proofing to a PDF or something, although that sounds > all very application specific. I think I agree on this. > I'm guessing it's just choosing where to put the line. I would argue > that asking the user what rendering mode they want to use for a print > preview is overboard, as you could just choose a good default and use > that. Similarly for rendering random RGB spaces to the desktop, > perceptual is probably the best plan. Right. My concern is more if applications (or rather developers) then know to do the "right thing" when they query GCM for the current "softproof" setting to do a print preview, which would be, "convert image with user selected GCM 'softproof' intent to device space, then absolute colorimetrically to the display" - we don't want gamut mapping to happen twice, that would invalidate the print preview. Of course matrix profiles only support colorimetric either way. Still, it's something to keep in mind. > If you've got any better ideas about what should be in the UI (BPC?) > as a sensible per-session default then I'm interested. You could also > argue that dispcalGUI and GCM should be working closer together in > this respect, and I'm open for suggestions. Personally I'd probably label the current "softproof" intent setting as "print preview" or something along the line. And I think adding an option for BPC would indeed be a nice touch. Rather than adding a checkbox or other additional control, just another intent "Relative with black point compensation" could be added to the dropdown lists. Re making dispcalGUI and GCM work closer together: Sure, it's an option. I wouldn't limit it to dispcalGUI though as other screen calibration/profiling solutions may exist in future (I hear LProf was/is planning to have a measurement capability, but I have to admit I'm not really well informed in that regard). Some wild thinking: Users can already choose their preferred applications for different filetypes/tasks. Maybe in the future, users can choose the preferred calibration solution in a similar way? Although right now, it's probably over the top, as only dispcalGUI and GCM exist as viable options afaik :) (and of course, directly using the Argyll tools on the commandline) Regards, -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 14:56:18 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 15:56:18 +0100 Subject: Conceptual questions In-Reply-To: <4C2DF5E9.6060203@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: On 2 July 2010 15:21, Florian H?ch wrote: > Personally I'd probably label the current "softproof" intent setting as > "print preview" or something along the line. Yes, good idea, I've done this in git master. > And I think adding an option for BPC would indeed be a nice touch. Rather > than adding a checkbox or other additional control, just another intent > "Relative with black point compensation" could be added to the dropdown > lists. Do we every want to do relative /without/ BPC? > Some wild thinking: Users can already choose their preferred > applications for different filetypes/tasks. Maybe in the future, users can > choose the preferred calibration solution in a similar way? Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and GcmCalibrateManual, and it would be pretty easy to make that pluggable using GIO extension points. One for the future perhaps. Richard. From lists+gnome-color-manager at hoech.org Fri Jul 2 15:07:33 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 17:07:33 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> Message-ID: <4C2E00B5.80403@hoech.org> Am 02.07.2010 16:56, schrieb Richard Hughes: > On 2 July 2010 15:21, Florian H?ch wrote: >> Personally I'd probably label the current "softproof" intent setting as >> "print preview" or something along the line. > > Yes, good idea, I've done this in git master. Nice! >> And I think adding an option for BPC would indeed be a nice touch. Rather >> than adding a checkbox or other additional control, just another intent >> "Relative with black point compensation" could be added to the dropdown >> lists. > > Do we every want to do relative /without/ BPC? For proofing, without BPC is a must of course. But for image -> arbitrary display/output space, defaulting to BPC "on" for relative colorimetric seems to be the right choice (and will surely avoid some "why are my blacks crushed" cries from users :)). >> Some wild thinking: Users can already choose their preferred >> applications for different filetypes/tasks. Maybe in the future, users can >> choose the preferred calibration solution in a similar way? > > Sure, GcmCalibrate is superclassed by GcmCalibrateArgll and > GcmCalibrateManual, and it would be pretty easy to make that pluggable > using GIO extension points. One for the future perhaps. Cool. I agree it's still a bit early. > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Fri Jul 2 15:26:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 2 Jul 2010 16:26:11 +0100 Subject: Conceptual questions In-Reply-To: <4C2E00B5.80403@hoech.org> References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: On 2 July 2010 16:07, Florian H?ch wrote: > For proofing, without BPC is a must of course. But for image -> arbitrary > display/output space, defaulting to BPC "on" for relative colorimetric seems > to be the right choice (and will surely avoid some "why are my blacks > crushed" cries from users :)). So, for 'Print Preview' these make sense: perceptual relative-colormetric relative-colormetric-bpc saturation absolute-colormetric and for 'Display': perceptual relative-colormetric saturation absolute-colormetric I'm not completely sure of all the nuances of BPC myself, so I would certainly appreciate any pointers and corrections. Thanks. Richard From lists+gnome-color-manager at hoech.org Fri Jul 2 16:10:36 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 02 Jul 2010 18:10:36 +0200 Subject: Conceptual questions In-Reply-To: References: <4C2CD7A9.90409@hoech.org> <4C2CEAF4.9030006@hoech.org> <4C2DF5E9.6060203@hoech.org> <4C2E00B5.80403@hoech.org> Message-ID: <4C2E0F7C.4010202@hoech.org> Am 02.07.2010 17:26, schrieb Richard Hughes: > On 2 July 2010 16:07, Florian H?ch wrote: >> For proofing, without BPC is a must of course. But for image -> arbitrary >> display/output space, defaulting to BPC "on" for relative colorimetric seems >> to be the right choice (and will surely avoid some "why are my blacks >> crushed" cries from users :)). > > So, for 'Print Preview' these make sense: > > perceptual > relative-colormetric > relative-colormetric-bpc > saturation > absolute-colormetric > > and for 'Display': > > perceptual > relative-colormetric > saturation > absolute-colormetric > > I'm not completely sure of all the nuances of BPC myself, so I would > certainly appreciate any pointers and corrections. Thanks. Actually, for both print preview and display BPC can make sense, it all depends on the combinations involved (always assuming the print preview intent is for the image -> simulated device transform, not the simulated device -> display transform). The key is when print preview is used, the transform to the display must not use BPC (or perceptual/saturation). But when print preview is not used, then BPC makes a lot of sense for display imho, to avoid crushed blacks (e.g. conversion from a working space like AdobeRGB with 'zero' blackpoint to a display profile with 'lighter' blackpoint). I hope I'm making sense. -- Florian H?ch http://hoech.net From graeme2 at argyllcms.com Sat Jul 3 02:11:43 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Sat, 03 Jul 2010 12:11:43 +1000 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <4C2E9C5F.3080208@argyllcms.com> Richard Hughes wrote: > Can we convince them to try lcms2? Has anybody got any contacts in Mozilla? You can always try and talk sense into them, but it seemed a wild decision to begin with, and therefore much harder to back down from.. [I doubt that the Firefox CMM is faster than a GPU. It may not even be faster than Argyll's cctiff/imdi, in spite of them using assembler.] Graeme Gill. From jorge.fabregas at gmail.com Sat Jul 3 13:59:42 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Sat, 3 Jul 2010 09:59:42 -0400 Subject: Color management in ubuntu In-Reply-To: References: <201007020836.50739.jorge.fabregas@gmail.com> Message-ID: <201007030959.43042.jorge.fabregas@gmail.com> On Friday 02 July 2010 08:39:52 Pascal de Bruijn wrote: > Firefox 3.0 uses LCMS and will process both v2 and v4 profiles properly. > > Firefox 3.5+ uses it's own internal CMS which only processes v2 > profiles, but it's faster. I see. Thanks Pascal! All the best, Jorge From hughsient at gmail.com Mon Jul 5 16:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 5 Jul 2010 17:44:10 +0100 Subject: Color management in ubuntu In-Reply-To: References: <1278001137.2552.11.camel@localhost> <1278002564.2552.12.camel@localhost> Message-ID: On 1 July 2010 18:25, Richard Hughes wrote: > I've been experimenting with GLSL shaders, and doing the color > conversion in hardware on the GPU. We've hit a few stumbing blocks in > clutter, but I'm adding API to clutter where required. Using the > hardware allows us to do lots of clever interpolation in 3D to make > things super sweet. Without using GPU hardware it's quite hard to > process high-def video at normal frame rates. Thanks to Neil Roberts who has added the required 3D texture support to clutter, I've got a mutter tree on my system that does full screen color management with a simple shader on the GPU. I've also added some demo code to GCM, although it's a standalone program and needs the cogl-texture-3d branch of clutter installed to even compile. Now, I have to fix the remaining bugs in mutter to enable this stuff, and then we have to work out how to mask bits of windows that are already color managed. Net color spec already exists, but isn't very friendly to a composited desktop that isn't compiz, i.e. not rendering to a flat rectangle of pixels. It's also not very toolkit friendly. Richard. From jorge.fabregas at gmail.com Tue Jul 6 12:58:56 2010 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Tue, 6 Jul 2010 08:58:56 -0400 Subject: Wallpaper & Icons on GNOME Desktop Message-ID: <201007060858.56709.jorge.fabregas@gmail.com> Hello everyone, I'm just curious: If you use Gnome Color Manager to create/use/load your ICC monitor profile... Will the GNOME desktop itself take into consideration the monitor profile so that I can render the icons & wallpaper accordingly? Thanks, Jorge From pmjdebruijn at pcode.nl Tue Jul 6 15:26:15 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 6 Jul 2010 17:26:15 +0200 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: <201007060858.56709.jorge.fabregas@gmail.com> References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: 2010/7/6 Jorge F?bregas : > Hello everyone, > > I'm just curious: If you use Gnome Color Manager to create/use/load your ICC > monitor profile... Will the GNOME ?desktop itself ?take into consideration the > monitor profile so that I can render the icons & wallpaper accordingly? Nope... Only specific applications are fully color managed (GIMP, Inkscape, F-Spot, Darktable, UFRaw)... Though a good display profile consist of two part: - VideoLUT which is mostly white point correction and gamma correction - XYZ Matrix which is color correction The VideoLUT is applied by the video driver, so everything benefits from this... The XYZ Matrix is only used by color managed applications which are properly configured... For example GIMP has this disabled by default, it can easily be enabled from it's Preferences. Regards, Pascal de Bruijn From jorge.fabregas at gmail.com Thu Jul 8 02:30:11 2010 From: jorge.fabregas at gmail.com (Jorge =?utf-8?q?F=C3=A1bregas?=) Date: Wed, 7 Jul 2010 22:30:11 -0400 Subject: Wallpaper & Icons on GNOME Desktop In-Reply-To: References: <201007060858.56709.jorge.fabregas@gmail.com> Message-ID: <201007072230.12136.jorge.fabregas@gmail.com> On Tuesday 06 July 2010 11:26:15 Pascal de Bruijn wrote: > Nope... Only specific applications are fully color managed (GIMP, > Inkscape, F-Spot, Darktable, UFRaw)... Ok. > Though a good display profile consist of two part: > > - VideoLUT which is mostly white point correction and gamma correction > - XYZ Matrix which is color correction Yes, I had to read many articles about the difference between monitor calibration and profiling (and how many people new to CMS confuse both). > The VideoLUT is applied by the video driver, so everything benefits from > this... I see. I get it now. And indeed I notice a BIG difference on my overall desktop when I load the ICC profile. The change on visual appearance of my screen - when the calibration-part gets loaded (gamma & white-point correction) - is considerably higher than the changes made when a color-managed app takes into consideration the profile part (color correction). > The XYZ Matrix is only used by color managed applications which are > properly configured... I see, so the GNOME desktop (and practically anything X-related) takes advantage of the information stored on the VideoLUT but I won't see anything color-corrected (from the profiling part of the ICC) until a capable app is configured to do so. Thank you very much Pascal ! I really appreciate your help. All the best, Jorge From alexandre.prokoudine at gmail.com Thu Jul 15 23:46:59 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Fri, 16 Jul 2010 03:46:59 +0400 Subject: gcm not working for second logged in user Message-ID: Hi, It was reported earlier on IRC that g-c-m doesn't work for the second logged in user -- the applet starts and then closes itself. The user who reported that moved from 2.31.1 back to 2.30.0(-0ubuntu3) and still experiences the issue. Here is the current log, for 2.30: http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 11:34:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 12:34:24 +0100 Subject: libcolor-glib Message-ID: I've just merged a pretty big branch into GCM git master. libcolor-glib is a new library to be used pretty much exclusively by GCM. It's not designed to be used by end-user-applications like gimp and darktable, but instead just by gnome-color-manager and any additional tools that ISV's want to build. End user applications should continue to use the DBus interface which has not changed. libcolor-glib is starting to grow in functionality, and some of the core new pieces are: * Userspace DDC control, so we can control things like the HP DreamColor monitors and upload custom color spaces. * In-process colorimeter reading. The last point is interesting. I wanted to put the calibration routines in process, so we can get rid of that crappy VTE window, output scraping and all the popups from that. It would also allow us to do ambient lighting control like the windows tools do. This would however mean using argyll as a library (which it isn't) and also using argyll "headless", i.e. without a VTE. Argyll doesn't work very well without a console attached to it. Argyll is also AGPLv3, so can't be run in process with a GPLv2+ program. So, I've spent a couple of evenings reverse engineering the HUEY device. I needed a MIT licensed version of this code for another project I'm working on, and so including it in GCM as LGPLv2+ seemed obvious. The GcmSensorHuey object kinda works now, although I've made some very large guesses and approximations, and the XYZ color only *just* bears some resemblance to reality. The ambient light sensor does however work reliably, although I had to work out a fudge factor using my ColorMunki, so isn't exactly precise. If you know anything technical about the hardware, I'm all ears. So, for the next release if you're using a Huey and gcm-picker, you get the GCM in-process native driver. Anything else (including the ColorMunki) you get to use argyll like normal. Calibration is still always done with argyll, as generating a ICC profile is a little more involved that just getting a few XYZ values. So, a few Q&A's: Q: Do I intend on making other native drivers for other hardware A: No, as I don't have the hardware. I might make bits of the ColorMunki work like the ambient light sensor, although I'm having problems getting traces from the windows driver. Q: Are the GcmSensorHuey values accurate? A: No. If we know a bit more about the hardware we can reduce the amount of futzing and bodging we do. When my head recovers (reverse engineering is hard...) I'll take a look and see if we're doing anything batshit insane. Q: Can we help by copying the logic out of the decompiled windows driver or from Argyll. A: No. Don't even look at other source code if you want to contribute code as LGPLv2+. Note: it's okay to strace argyll commands, or to record the windows driver usb traffic, and this is what I've been doing. Q: Are you working on a sekret project? A: No. I'm putting a few technical demos together, but nothing sekret. Q: Are you aiming to replace Argyll. A: No. Argyll is a mature project that works really well and is a complete calibration workflow. GCM is a new project that does very limited things. Questions ahoy! :-) Richard. From alexandre.prokoudine at gmail.com Mon Jul 19 11:48:11 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 19 Jul 2010 15:48:11 +0400 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 7/19/10, Richard Hughes wrote: > libcolor-glib is starting to grow in functionality, and some of the > core new pieces are: > > * Userspace DDC control, so we can control things like the HP > DreamColor monitors and upload custom color spaces. > * In-process colorimeter reading. Tell me, are you up to Nobel prize this year? :) That sounds awesome! But I demand details about DDC :) Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jul 19 12:33:08 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:33:08 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 12:48, Alexandre Prokoudine wrote: > Tell me, are you up to Nobel prize this year? :) No, but I'm doing a talk at GUADEC and want to show some impressive demos. > That sounds awesome! But I demand details about DDC :) Right. Most of the core DDC logic belongs in the kernel, but a few of the device specific controls probably belong in userspace. The DreamColor display (which I'm hoping will arrive really soon now) will allow us to test and use a 30bit LUT in Xorg, and display wide gamut images. We need to use DDC controls to talk to the engine in the display, and I'm also waiting for more detailed specs to come out of HP. For what it's worth, HP have been very helpful indeed. A lot of the stuff I've been working on recently (GLSL hardware shaders, libcolor-glib) allows us to build a framework that's acceptable to the big-name studios, and keeping to the "just works" GNOME mantra. There's still a lot of work to do, but it's coming on fast now. I would really appreciate any help with the hardware parts, as a color sensor giving "kinda approximate" XYZ values isn't particularly useful. Richard. From pmjdebruijn at pcode.nl Mon Jul 19 12:41:51 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 19 Jul 2010 14:41:51 +0200 Subject: libcolor-glib In-Reply-To: References: Message-ID: On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: > On 19 July 2010 12:48, Alexandre Prokoudine > wrote: >> Tell me, are you up to Nobel prize this year? :) > > No, but I'm doing a talk at GUADEC and want to show some impressive demos. Well it all sounds pretty kick ass... But uh... so you'll be in the Netherlands? 26-30th? Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jul 19 12:53:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Jul 2010 13:53:21 +0100 Subject: libcolor-glib In-Reply-To: References: Message-ID: On 19 July 2010 13:41, Pascal de Bruijn wrote: > On Mon, Jul 19, 2010 at 2:33 PM, Richard Hughes wrote: >> On 19 July 2010 12:48, Alexandre Prokoudine >> wrote: >>> Tell me, are you up to Nobel prize this year? :) >> >> No, but I'm doing a talk at GUADEC and want to show some impressive demos. > > Well it all sounds pretty kick ass... > But uh... so you'll be in the Netherlands? 26-30th? I'll be in the Hague from 24th to the 31st. It would be good to grab a beer or seven. Richard. From hughsient at gmail.com Tue Jul 20 09:00:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 10:00:10 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 16 July 2010 00:46, Alexandre Prokoudine wrote: > http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 I've just fixed this, you want to apply dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Thanks, Richard. From alexandre.prokoudine at gmail.com Tue Jul 20 09:42:52 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Tue, 20 Jul 2010 13:42:52 +0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 7/20/10, Richard Hughes wrote: > On 16 July 2010 00:46, Alexandre Prokoudine > wrote: >> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 > > I've just fixed this, you want to apply > dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x Many thanks! Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Tue Jul 20 12:03:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Jul 2010 13:03:56 +0100 Subject: GUADEC Message-ID: I've just finished writing my slides[1] for GUADEC. I'm presenting on the Friday afternoon, see http://www.guadec.org/index.php/guadec/2010/schedConf/program for details. I'm going to be there for the full week. If you grab me at GUADEC, be sure to introduce yourself as I'm really bad with names and faces. :-) Hopefully see some of you there! Richard. [1] I say "writing", but it's mostly all pictures and diagrams... From luto at mit.edu Tue Jul 20 19:06:51 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 20 Jul 2010 15:06:51 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: I have a Dell U2711, which has 10 bits per channel over DisplayPort (although I'm not sure that anything other than i915 can drive 10 bits right now, and even i915 needs bleeding-edge drivers). Can GCM program a 10-bit video card LUT? Also, the U2711 has an internal LUT, although no one seems to know how to program it (even on Windows) or even whether it can be programmed with anything other than a (not-very-good) factory calibration. Richard, did your libcolor-glib work give you any ideas for how to test for DDC control of a LUT on an unknown monitor? I'd be happy to test and fiddle. --Andy From pmjdebruijn at pcode.nl Tue Jul 20 21:58:32 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Tue, 20 Jul 2010 23:58:32 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 11:42 AM, Alexandre Prokoudine wrote: > On 7/20/10, Richard Hughes wrote: >> On 16 July 2010 00:46, Alexandre Prokoudine >> wrote: >>> http://linuxgraphics.ru/forum/viewthread.php?thread_id=644&getfile=8413 >> >> I've just fixed this, you want to apply >> dc7ebf0ff9baa5bd9451087848a54b7c60d3ee43 to 2.30.x I applied that patch to my 2.31.1 package too... However, I'm still curious then... User 1 logs in: gcm-prefs loads videolut gcm-prefs sets profile atom for user 1 User 2 logs in gcm-prefs loads videolut (from a different profile) gcm-prefs sets profile atom for user 2 User 1 switches back... Won't user 1 now end up the the video lut of the profile of user 2, but still have his own profile's atom set? This obviously won't be a problem if both users use the same profile... Regards, Pascal de Bruijn From hughsient at gmail.com Wed Jul 21 08:26:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:26:38 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 20 July 2010 22:58, Pascal de Bruijn wrote: > User 2 logs in > gcm-prefs loads videolut (from a different profile) > gcm-prefs sets profile atom for user 2 Yes, this is a valid bug. We probably should get our GSD plugin to watch for ConsoleKit changes (the ACTIVE attribute) but really this needs some proper session support. I really don't want to add yet another session process just watching for a session active state change. Better ideas welcome. Richard. From hughsient at gmail.com Wed Jul 21 08:32:50 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Jul 2010 09:32:50 +0100 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). ?Can GCM > program a 10-bit video card LUT? In theory, yes. I've made the GcmClut object generate the amount of data for each LUT size, but I admit I've never tested it on anything other than 8 bpp. > Also, the U2711 has an internal LUT, although no one seems to know how > to program it (even on Windows) or even whether it can be programmed > with anything other than a (not-very-good) factory calibration. > Richard, did your libcolor-glib work give you any ideas for how to > test for DDC control of a LUT on an unknown monitor? ?I'd be happy to > test and fiddle. Yes. I'm still waiting for me DreamColor monitor to arrive, and that allows a custom colorspace to be uploaded. For your monitor, you probably need to convince the manufacturer to give you the specs, or find a windows tool that calibrates the monitor and then trace that. You always have to be a little but careful sending hardware random data to reverse engineer it. First, the output of "gcm-ddc-util --enumerate" should give us something to work on. Richard. From luto at mit.edu Wed Jul 21 21:09:39 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Wed, 21 Jul 2010 17:09:39 -0400 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 4:32 AM, Richard Hughes wrote: > On 20 July 2010 20:06, Andrew Lutomirski wrote: >> I have a Dell U2711, which has 10 bits per channel over DisplayPort >> (although I'm not sure that anything other than i915 can drive 10 bits >> right now, and even i915 needs bleeding-edge drivers). ?Can GCM >> program a 10-bit video card LUT? > > In theory, yes. I've made the GcmClut object generate the amount of > data for each LUT size, but I admit I've never tested it on anything > other than 8 bpp. > >> Also, the U2711 has an internal LUT, although no one seems to know how >> to program it (even on Windows) or even whether it can be programmed >> with anything other than a (not-very-good) factory calibration. >> Richard, did your libcolor-glib work give you any ideas for how to >> test for DDC control of a LUT on an unknown monitor? ?I'd be happy to >> test and fiddle. > > Yes. I'm still waiting for me DreamColor monitor to arrive, and that > allows a custom colorspace to be uploaded. For your monitor, you > probably need to convince the manufacturer to give you the specs, or > find a windows tool that calibrates the monitor and then trace that. > > You always have to be a little but careful sending hardware random > data to reverse engineer it. First, the output of "gcm-ddc-util > --enumerate" should give us something to work on. gcm-dump-edid says: Monitor name: DELL U2711 Vendor name: Dell Serial number: D971T0471EFL PNP identifier: DEL Size: 60x34 Gamma: 2.200000 gcm-ddc-util --enumerate says: $ sudo ./gcm-ddc-util --enumerate EDID: f3b71e4fd0bf14ac3db509cbc4ba48ba PNPID: DELA055 Model: U2711 0x02 [secondary-degauss] 0x04 [reset-factory-defaults] 0x05 [reset-brightness-and-contrast] 0x06 [reset-factory-geometry] 0x08 [reset-factory-default-color] 0x10 [brightness] 0x12 [contrast] 0x14 [select-color-preset] ( 1 5 8 0 0 ) 0x16 [red-video-gain] 0x18 [green-video-gain] 0x1a [blue-video-gain] 0x52 [saturation] 0x60 [input-source-select] ( 1 3 4 5 0 0 11 ) 0xac [horizontal-frequency] 0xae [vertical-frequency] 0xb2 [unknown] 0xb6 [unknown] 0xc6 [unknown] 0xc8 [unknown] 0xc9 [firmware-version] 0xd6 [dpms-control-(1---on/4---stby)] ( 1 4 5 ) 0xdc [magicbright-(1---text/2---internet/3---entertain/4---custom)] ( 0 2 3 4 5 ) 0xdf [vcp-version] 0xfd [power-led] --control 0xb2 --get doesn't seem to work. This is also suspicious: $ sudo ./gcm-ddc-util --display f3b71e4fd0bf14ac3db509cbc4ba48ba --control vcp-version --get vcp-version is 513, max is 255 I'm not really sure what I'm looking for, though, and I haven't spotted the DreamColor code. (Is it there?) --Andy > > Richard. > From alexdeucher at gmail.com Thu Jul 22 04:12:46 2010 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 22 Jul 2010 00:12:46 -0400 Subject: 10-but LUTs and the Dell U2711 Message-ID: On 20 July 2010 20:06, Andrew Lutomirski wrote: > I have a Dell U2711, which has 10 bits per channel over DisplayPort > (although I'm not sure that anything other than i915 can drive 10 bits > right now, and even i915 needs bleeding-edge drivers). Can GCM > program a 10-bit video card LUT? FWIW, all radeons (even the original r100) support 10 bit LUTs. Alex From graeme2 at argyllcms.com Thu Jul 22 04:59:52 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 22 Jul 2010 14:59:52 +1000 Subject: 10-but LUTs and the Dell U2711 In-Reply-To: References: Message-ID: <4C47D048.70702@argyllcms.com> Alex Deucher wrote: > FWIW, all radeons (even the original r100) support 10 bit LUTs. My Nvidia 8600GT has 10 bit LUTs & D/A converters to VGA. I'd imagine that the digital path to the display is only 8 bit though.. Graeme Gill. From hughsient at gmail.com Thu Jul 22 09:16:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 10:16:40 +0100 Subject: Anyone got a huey? Message-ID: Have any of you got a huey and a few minutes? I want to do some comparisons between two dumps to try to find differences and to help reverse engineer it. Yell if you can help. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 10:00:11 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 12:00:11 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: > Have any of you got a huey and a few minutes? I want to do some > comparisons between two dumps to try to find differences and to help > reverse engineer it. Yell if you can help. Got One... What do I need to do? I can get back to you tonight... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 11:45:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 12:45:10 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 11:00, Pascal de Bruijn wrote: > On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >> Have any of you got a huey and a few minutes? I want to do some >> comparisons between two dumps to try to find differences and to help >> reverse engineer it. Yell if you can help. > > Got One... > > What do I need to do? * Build GCM git master from today * Insert the HUEY * ./tools/gcm-dump-sensor * Send me offlist the sensor-dump.txt file it produces. Thanks, Richard. From pmjdebruijn at pcode.nl Thu Jul 22 13:02:30 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 15:02:30 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:45 PM, Richard Hughes wrote: > On 22 July 2010 11:00, Pascal de Bruijn wrote: >> On Thu, Jul 22, 2010 at 11:16 AM, Richard Hughes wrote: >>> Have any of you got a huey and a few minutes? I want to do some >>> comparisons between two dumps to try to find differences and to help >>> reverse engineer it. Yell if you can help. >> >> Got One... >> >> What do I need to do? > > * Build GCM git master from today > * Insert the HUEY > * ./tools/gcm-dump-sensor > * Send me offlist the sensor-dump.txt file it produces. Would that build on GNOME 2.30.x? Maybe I could try an alpha live cd of sorts, I'll try to work something out... Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 13:15:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 14:15:54 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 14:02, Pascal de Bruijn wrote: > Would that build on GNOME 2.30.x? No way. Although, you could probably hack up configure to lower the deps and then _only_ build libcolor-glib and the tools. That might work. > Maybe I could try an alpha live cd of sorts, I'll try to work something out... Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds and then installing http://people.freedesktop.org/~hughsient/fedora/13/i386/ should probably work. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 16:30:47 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 18:30:47 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 3:15 PM, Richard Hughes wrote: > On 22 July 2010 14:02, Pascal de Bruijn wrote: >> Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > >> Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds > and then installing > http://people.freedesktop.org/~hughsient/fedora/13/i386/ should > probably work. Well, I got a whole lot of won't boot :) I could bring the Huey with me next Friday to GUADEC so you can check it out yourself? Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jul 22 16:53:46 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 22 Jul 2010 17:53:46 +0100 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: On 22 July 2010 17:30, Pascal de Bruijn wrote: > I got a whole lot of won't boot :) Hah! Welcome to rawhide ;-) > I could bring the Huey with me next Friday to GUADEC so you can check > it out yourself? That would be good, thanks. It only takes about 2 seconds to dump all the registers. Richard. From pmjdebruijn at pcode.nl Thu Jul 22 17:11:55 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 22 Jul 2010 19:11:55 +0200 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: > On 20 July 2010 22:58, Pascal de Bruijn wrote: >> User 2 logs in >> gcm-prefs loads videolut (from a different profile) >> gcm-prefs sets profile atom for user 2 > > Yes, this is a valid bug. We probably should get our GSD plugin to > watch for ConsoleKit changes (the ACTIVE attribute) but really this > needs some proper session support. I really don't want to add yet > another session process just watching for a session active state > change. Well it's a very rare use case tho... Since screen calibration is inherently a system properly and not really a user thing... It could become a user thing when two users disagree on what gamma/white point should be profiled against... But then again, there isn't that much debate about this, and even so, a single shop will standardize to a single setting... Though technically it's a bug that could be hit and produce some really funky shit :) Regards, Pascal de Bruijn From andy at luto.us Thu Jul 22 17:40:11 2010 From: andy at luto.us (Andrew Lutomirski) Date: Thu, 22 Jul 2010 13:40:11 -0400 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: > On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>> User 2 logs in >>> gcm-prefs loads videolut (from a different profile) >>> gcm-prefs sets profile atom for user 2 >> >> Yes, this is a valid bug. We probably should get our GSD plugin to >> watch for ConsoleKit changes (the ACTIVE attribute) but really this >> needs some proper session support. I really don't want to add yet >> another session process just watching for a session active state >> change. > > Well it's a very rare use case tho... > > Since screen calibration is inherently a system properly and not > really a user thing... I disagree. Profiling the monitor is inherently a system thing (presumably it's the *same* monitor for all users). The LUT setting is a different story. One user might want 6500K, another might want 7000K, and a third might want no correction at all for maximum 3D gamut because they know that whatever program they care about is already using a CLUT profile. A fourth user might run dispwin -c themselves and the first user might want their calibration back when they switch back. (Of course, the profile to use depends on the LUT, but that's "just" an implementation detail.) > > It could become a user thing when two users disagree on what > gamma/white point should be profiled against... But then again, there > isn't that much debate about this, and even so, a single shop will > standardize to a single setting... You should get a Lenovo X series laptop. I had to calibrate mine to 6000K because the screen is *so* bad that I lose an annoying amount of brightness and get rather crappy results if I calibrate to anything else. (Last I checked, the calibration GUI doesn't have that setting, so I just did it manually with dispcal.) But I'm not sure there's a problem at all. Don't the two users have their own X servers, and shouldn't the X server restore the LUT on its own? (I *think* that drv-intel 2.9.0 or newer with recent xserver is smart enough.) --Andy From len at math.northwestern.edu Fri Jul 23 15:58:21 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Fri, 23 Jul 2010 10:58:21 -0500 Subject: Fedora version Message-ID: <1279900701.7721.14.camel@localhost> I would liked to try out gnome color management. I am currently using Fedora 12, but I can if necessary upgrade to Fedora 13. I understand that it will be available as a Fedora 14 package, but I wonder if a package is available I could try before that. I can if necessary compile it from source, but that is usually time consuming and requires searching for additional packages. I have used Argyllcms with an Eye One Pro to calibrate/profile my monitor and my printer. Gimp, firefox, and inkscape can use the monitor profile, but there are some difficulties with other applications such as eye of gnome. I've been printing by a complicated method using argyllcms and photoprint. I was hoping an integrated gnome package might allow me to deal with such matters in a straightforward manner. Can you suggest anything to help? P.S. I do have Ubuntu on a laptop, but working from there would be a bit awkward. -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Fri Jul 23 16:12:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Jul 2010 17:12:16 +0100 Subject: Fedora version In-Reply-To: <1279900701.7721.14.camel@localhost> References: <1279900701.7721.14.camel@localhost> Message-ID: On 23 July 2010 16:58, Leonard Evens wrote: > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > 13. ?I understand that it will be available as a Fedora 14 package, but > I wonder if a package is available I could try before that. Just update to fedora 13. It's included by default. Richard. From marek at matulka.net Fri Jul 23 16:22:23 2010 From: marek at matulka.net (Marek Matulka) Date: Fri, 23 Jul 2010 17:22:23 +0100 Subject: Fedora version In-Reply-To: References: <1279900701.7721.14.camel@localhost> Message-ID: <1279902143.2667.32.camel@localhost> On Fri, 2010-07-23 at 17:12 +0100, Richard Hughes wrote: > On 23 July 2010 16:58, Leonard Evens wrote: > > I am currently using Fedora 12, but I can if necessary upgrade to Fedora > > 13. I understand that it will be available as a Fedora 14 package, but > > I wonder if a package is available I could try before that. > > Just update to fedora 13. It's included by default. how do I get a ?calibrate? functionality? I have a Fedora 13 installed, with argyllcms and all required packages, I can do calibration manually from the command line, but not through gnome-color-management package... I use Spyder 2. Thanks, Marek -- http://marek.matulka.net/ Windows - u mnie nie dzia?a. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From knizek.confy at volny.cz Sun Jul 25 06:29:02 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sun, 25 Jul 2010 08:29:02 +0200 Subject: Anyone got a huey? In-Reply-To: References: Message-ID: <1280039342.4370.22.camel@localhost> Richard Hughes p??e v ?t 22. 07. 2010 v 14:15 +0100: > On 22 July 2010 14:02, Pascal de Bruijn wrote: > > Would that build on GNOME 2.30.x? > > No way. Although, you could probably hack up configure to lower the > deps and then _only_ build libcolor-glib and the tools. That might > work. > > > Maybe I could try an alpha live cd of sorts, I'll try to work something out... > > Yes, using http://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds It does not boot for me either (cannot mount /dev/mapper/live-rw filesystem), I may try in a week time again. BTW, I have got a huey, which was delivered with wide-gamut Samsung XL20. There was a discussion on argyllcms list whether it is somehow modified or not compared to a standard huey. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Sun Jul 25 13:21:15 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 25 Jul 2010 14:21:15 +0100 Subject: Anyone got a huey? In-Reply-To: <1280039342.4370.22.camel@localhost> References: <1280039342.4370.22.camel@localhost> Message-ID: On 25 July 2010 07:29, Milan Kn??ek wrote: > There was a discussion on argyllcms list whether it is somehow > modified or not compared to a standard huey. I would be very interested in the dump, although I know GCM is kinda hard to install at the moment. Richard. From amluto at gmail.com Sun Jul 25 13:35:50 2010 From: amluto at gmail.com (Andy Lutomirski) Date: Sun, 25 Jul 2010 09:35:50 -0400 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: I'll send the patch I used later on. It's enough to build libcolor-glib (sans gcm-brightness) and the tools. --Andy On Jul 25, 2010, at 9:21 AM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list From knizek.confy at volny.cz Mon Jul 26 07:55:12 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 09:55:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: <1280130912.5411.3.camel@localhost> Richard Hughes p??e v Ne 25. 07. 2010 v 14:21 +0100: > On 25 July 2010 07:29, Milan Kn??ek wrote: > > There was a discussion on argyllcms list whether it is somehow > > modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Would it help to install Fedora 13 and compile on it? Or install Fedora 13 and upgrade to current development version ("rawhide" - is there a howto?)? P.S. I am used to Archlinux and Ubuntu, hence sorry for beginner's questions. regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at MIT.EDU Mon Jul 26 14:41:36 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:41:36 -0400 Subject: [PATCH] Make -Werror command-line configurable Message-ID: <1280155296-1270-1-git-send-email-luto@mit.edu> -Werror is already enabled by --enable-strict (default) and GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do that and don't hardcode it. --- Hi all- This is my first of two patches for building libcolor-glib on F13. This one is probable suitable for the real tree. The second one is way too hackish. --Andy configure.ac | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d34767d..7572ee1 100644 --- a/configure.ac +++ b/configure.ac @@ -51,7 +51,7 @@ LT_INIT AM_PROG_CC_C_O IT_PROG_INTLTOOL([0.35.0]) -GNOME_COMPILE_WARNINGS +GNOME_COMPILE_WARNINGS(error) GNOME_DOC_INIT # set up gtk-doc @@ -91,7 +91,6 @@ CPPFLAGS="$CPPFLAGS -DGSEAL_ENABLE" if test "$GCC" = "yes"; then WARNINGFLAGS_C="$WARNINGFLAGS_C -Wall" - WARNINGFLAGS_C="$WARNINGFLAGS_C -Werror" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wcast-align -Wno-uninitialized" WARNINGFLAGS_C="$WARNINGFLAGS_C -Wmissing-declarations" # WARNINGFLAGS_C="$WARNINGFLAGS_C -Wredundant-decls" -- 1.7.1.1 From luto at MIT.EDU Mon Jul 26 14:45:02 2010 From: luto at MIT.EDU (Andy Lutomirski) Date: Mon, 26 Jul 2010 10:45:02 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 Message-ID: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> This patch, if configured with ./configure --enable-compile-warnings=yes --disable-sane --disable-strict is enough to build libcolor-glib and most of tools. (You'll have to cd explicitly -- 'make libcolor-glib' doesn't do anything.) --- configure.ac | 16 ++++---- libcolor-glib/gcm-brightness.c | 80 +------------------------------------- libcolor-glib/gcm-sensor-huey.c | 4 +- libcolor-glib/gcm-usb.c | 11 ++--- 4 files changed, 18 insertions(+), 93 deletions(-) diff --git a/configure.ac b/configure.ac index 7572ee1..8a5c64b 100644 --- a/configure.ac +++ b/configure.ac @@ -134,20 +134,20 @@ GLIB_GSETTINGS dnl --------------------------------------------------------------------------- dnl - Check library dependencies dnl --------------------------------------------------------------------------- -PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.9) +PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.24) PKG_CHECK_MODULES(XORG, xxf86vm xrandr) -PKG_CHECK_MODULES(GTK, gtk+-3.0 >= 2.90.3) -PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) +PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.20) +#PKG_CHECK_MODULES(GNOMEDESKTOP, gnome-desktop-3.0 >= 2.90.0) PKG_CHECK_MODULES(GUDEV, gudev-1.0) PKG_CHECK_MODULES(LCMS, lcms2) PKG_CHECK_MODULES(X11, x11) PKG_CHECK_MODULES(USB, [libusb-1.0 >= 1.0.0]) dnl Required for the properties window -PKG_CHECK_MODULES(CONTROL_CENTER, [ - libgnome-control-center >= 2.31.4]) -PANELS_DIR="${libdir}/control-center-1/panels" -AC_SUBST(PANELS_DIR) +#PKG_CHECK_MODULES(CONTROL_CENTER, [ + #libgnome-control-center >= 2.31.4]) +#PANELS_DIR="${libdir}/control-center-1/panels" +#AC_SUBST(PANELS_DIR) dnl **** Check for VTE **** PKG_CHECK_MODULES(VTE, vte3 >= 0.25.1, has_vte=yes, has_vte=no) @@ -195,7 +195,7 @@ if test x$enable_exiv = xyes; then AC_DEFINE(HAVE_EXIV,1,[Use EXIV support for detecting scanners]) fi -PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) +#PKG_CHECK_MODULES(CANBERRA, libcanberra-gtk3 >= 0.10) PKG_CHECK_MODULES(EXIF, libexif) AC_CHECK_LIB(tiff, TIFFReadRGBAImageOriented, diff --git a/libcolor-glib/gcm-brightness.c b/libcolor-glib/gcm-brightness.c index 3785e50..251810a 100644 --- a/libcolor-glib/gcm-brightness.c +++ b/libcolor-glib/gcm-brightness.c @@ -47,7 +47,7 @@ static void gcm_brightness_finalize (GObject *object); struct _GcmBrightnessPrivate { guint percentage; - GDBusConnection *connection; + void *connection; }; enum { @@ -68,43 +68,7 @@ G_DEFINE_TYPE (GcmBrightness, gcm_brightness, G_TYPE_OBJECT) gboolean gcm_brightness_set_percentage (GcmBrightness *brightness, guint percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *args = NULL; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - g_return_val_if_fail (percentage <= 100, FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - args = g_variant_new ("(u)", percentage), - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "SetBrightness", - args, - NULL, - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* success */ - ret = TRUE; -out: - if (args != NULL) - g_variant_unref (args); - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** @@ -113,45 +77,7 @@ out: gboolean gcm_brightness_get_percentage (GcmBrightness *brightness, guint *percentage, GError **error) { - GcmBrightnessPrivate *priv = brightness->priv; - gboolean ret = FALSE; - GVariant *response = NULL; - - g_return_val_if_fail (GCM_IS_BRIGHTNESS (brightness), FALSE); - - /* get a session bus connection */ - if (priv->connection == NULL) { - priv->connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, error); - if (priv->connection == NULL) - goto out; - } - - /* execute sync method */ - response = g_dbus_connection_call_sync (priv->connection, - GPM_DBUS_SERVICE, - GPM_DBUS_PATH_BACKLIGHT, - GPM_DBUS_INTERFACE_BACKLIGHT, - "GetBrightness", - NULL, - G_VARIANT_TYPE ("(u)"), - G_DBUS_CALL_FLAGS_NONE, - -1, NULL, error); - if (response == NULL) - goto out; - - /* get the brightness */ - g_variant_get (response, "(u)", &priv->percentage); - - /* copy if set */ - if (percentage != NULL) - *percentage = priv->percentage; - - /* success */ - ret = TRUE; -out: - if (response != NULL) - g_variant_unref (response); - return ret; + return FALSE; } /** diff --git a/libcolor-glib/gcm-sensor-huey.c b/libcolor-glib/gcm-sensor-huey.c index 63ede01..3778266 100644 --- a/libcolor-glib/gcm-sensor-huey.c +++ b/libcolor-glib/gcm-sensor-huey.c @@ -363,7 +363,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to send request: %s", libusb_strerror (retval)); + "failed to send request"); goto out; } @@ -377,7 +377,7 @@ gcm_sensor_huey_send_data (GcmSensorHuey *sensor_huey, if (retval < 0) { g_set_error (error, GCM_SENSOR_ERROR, GCM_SENSOR_ERROR_INTERNAL, - "failed to get reply: %s", libusb_strerror (retval)); + "failed to get reply"); goto out; } diff --git a/libcolor-glib/gcm-usb.c b/libcolor-glib/gcm-usb.c index 891ff0f..85a5c87 100644 --- a/libcolor-glib/gcm-usb.c +++ b/libcolor-glib/gcm-usb.c @@ -301,8 +301,7 @@ gcm_usb_load (GcmUsb *usb, GError **error) if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to init libusb: %s", - libusb_strerror (retval)); + "failed to init libusb"); goto out; } @@ -375,8 +374,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to set configuration 0x%02x: %s", - configuration, libusb_strerror (retval)); + "failed to set configuration 0x%02x", + configuration); ret = FALSE; goto out; } @@ -384,8 +383,8 @@ gcm_usb_connect (GcmUsb *usb, guint vendor_id, guint product_id, guint configura if (retval < 0) { g_set_error (error, GCM_USB_ERROR, GCM_USB_ERROR_INTERNAL, - "failed to claim interface 0x%02x: %s", - interface, libusb_strerror (retval)); + "failed to claim interface 0x%02x", + interface); ret = FALSE; goto out; } -- 1.7.1.1 From hughsient at gmail.com Mon Jul 26 15:17:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:17:21 +0100 Subject: gcm not working for second logged in user In-Reply-To: References: Message-ID: On 22 July 2010 18:40, Andrew Lutomirski wrote: > On Thu, Jul 22, 2010 at 1:11 PM, Pascal de Bruijn wrote: >> On Wed, Jul 21, 2010 at 10:26 AM, Richard Hughes wrote: >>> On 20 July 2010 22:58, Pascal de Bruijn wrote: >>>> User 2 logs in >>>> gcm-prefs loads videolut (from a different profile) >>>> gcm-prefs sets profile atom for user 2 >>> >>> Yes, this is a valid bug. We probably should get our GSD plugin to >>> watch for ConsoleKit changes (the ACTIVE attribute) but really this >>> needs some proper session support. I really don't want to add yet >>> another session process just watching for a session active state >>> change. >> >> Well it's a very rare use case tho... commit dbebdeaeda3e9d48d5fa61bd9a2cd334fb61a4ce Author: Richard Hughes Date: Mon Jul 26 16:49:50 2010 +0100 Add a gnome-settings-daemon module to fix some hard to fix bugs This allows us to: 1) set gcm-apply when we switch users, so the correct VCGT is used 2) open the calibration window when a colorimeter is plugged in :100644 100644 0121d84... 3dcc91b... M Makefile.am :100644 100644 aa540d6... b030aba... M configure.ac :100644 100644 efdf3d4... c6cee42... M contrib/gnome-color-manager.spec.in :000000 100644 0000000... 0c620eb... A session/.gitignore :000000 100644 0000000... cba7279... A session/Makefile.am :000000 100644 0000000... fb6ec82... A session/color.gnome-settings-plugin :000000 100644 0000000... 312188e... A session/egg-console-kit.c :000000 100644 0000000... 2d897f1... A session/egg-console-kit.h :000000 100644 0000000... cc86414... A session/gsd-color-manager.c :000000 100644 0000000... 0c70ef5... A session/gsd-color-manager.h :000000 100644 0000000... 3883953... A session/gsd-color-plugin.c :000000 100644 0000000... d72b4bd... A session/gsd-color-plugin.h :100644 100644 a8848e8... 844c0b8... M src/Makefile.am :100644 100644 9b53705... 99aa7f2... M src/gcm-apply.c Richard. From hughsient at gmail.com Mon Jul 26 15:48:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:48:43 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: On 26 July 2010 15:45, Andy Lutomirski wrote: > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. ?(You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) Yup. Gross. :-) but thanks for posting. Richard. From hughsient at gmail.com Mon Jul 26 15:50:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Jul 2010 16:50:23 +0100 Subject: [PATCH] Make -Werror command-line configurable In-Reply-To: <1280155296-1270-1-git-send-email-luto@mit.edu> References: <1280155296-1270-1-git-send-email-luto@mit.edu> Message-ID: On 26 July 2010 15:41, Andy Lutomirski wrote: > -Werror is already enabled by --enable-strict (default) and > GNOME_COMPILE_WARNINGS can be set to enable it as well, so just do > that and don't hardcode it. Applied, thanks. Richard. From pmjdebruijn at pcode.nl Mon Jul 26 18:31:12 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 26 Jul 2010 20:31:12 +0200 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On Sun, Jul 25, 2010 at 3:21 PM, Richard Hughes wrote: > On 25 July 2010 07:29, Milan Kn??ek wrote: >> There was a discussion on argyllcms list whether it is somehow >> modified or not compared to a standard huey. > > I would be very interested in the dump, although I know GCM is kinda > hard to install at the moment. Kinda is a bit of an understatement :p Anyhow, there's another easy and nasty way to solve this... Can't you provide fully statically built versions of the utils? I can get you a DDC dump of my display as well... Regards, Pascal de Bruijn From knizek.confy at volny.cz Mon Jul 26 19:32:35 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Mon, 26 Jul 2010 21:32:35 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> Message-ID: <1280172755.4389.13.camel@localhost> Andy Lutomirski p??e v Po 26. 07. 2010 v 10:45 -0400: > This patch, if configured with > > ./configure --enable-compile-warnings=yes --disable-sane --disable-strict > > is enough to build libcolor-glib and most of tools. (You'll have to cd > explicitly -- 'make libcolor-glib' doesn't do anything.) The patch applied with errors on configure.ac, I updated it manually accordingly. However, there are still missing lcms2 and libusb-1.0 packages in Fedora 13 repositories. I have removed the version requirements for the two, but compilation afterwards failed on some libusb matters. As Pascal suggested, could someone skilled provide the necessary binaries compiled statically so that we can send the sensor data? Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Mon Jul 26 23:22:31 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:22:31 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280172755.4389.13.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: On 26 July 2010 20:32, Milan Kn??ek wrote: > As Pascal suggested, could someone skilled provide the necessary > binaries compiled statically so that we can send the sensor data? Grab the packages from http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/ and rebuild them. They should work okay on F12/13. Richard. From hughsient at gmail.com Mon Jul 26 23:25:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 00:25:02 +0100 Subject: Anyone got a huey? In-Reply-To: References: <1280039342.4370.22.camel@localhost> Message-ID: On 26 July 2010 19:31, Pascal de Bruijn wrote: > Can't you provide fully statically built versions of the utils? Ick. I'll give this a try, but I think it is made deliberately hard on Fedora. Richard. From len at math.northwestern.edu Mon Jul 26 23:45:28 2010 From: len at math.northwestern.edu (Leonard Evens) Date: Mon, 26 Jul 2010 18:45:28 -0500 Subject: Possible interaction between the Color manager and Argyllcms Message-ID: <1280187928.2019.36.camel@localhost> 1. I am running Fedora 13. dispwin used directly doesn't seem to do what it did previously. I can use dispwin -I Profile_path to install a profile, but it doesn't persist as it did under previous versions of Fedora (including Fedora 12). But, I can use the gnome color manager to set the display profile, and that does seem topersist. I wonder if the gnome color management is somehow interfering with way argyllcms ordinarily works. 2. In using the color manager to profile a laptop (running Ubuntu 10.4) screen, and using my Eye One Pro, I encountered some problems. The Eye-One Pro has to be calibrated on its base, but the color manager doesn't ask me to do that. In order to get it done, I have to press Details, which brings up the usual argyllcms command line interface. But it is not clear exactly what I am supposed to do using that interface and what using the color manager. If I understood the intended sequence of events, it might be clearer to me how to proceed. Also, the color manager didn't allow me to do any hardware calibration. Of course, for my laptop screen that is somewhat restricted---the only control is screen brightness. I don't know what will happen when I try this an external monitor with lots of controls. Perhaps I am just supposed to continue in the Details window with argyllcms commands? -- Leonard Evens len at math.northwestern.edu Professor Emeritus, Department of Mathematics, Northwestern University From hughsient at gmail.com Tue Jul 27 08:55:41 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Jul 2010 09:55:41 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280187928.2019.36.camel@localhost> References: <1280187928.2019.36.camel@localhost> Message-ID: On 27 July 2010 00:45, Leonard Evens wrote: > 1. ?I am running Fedora 13. ?dispwin used directly doesn't seem to do > what it did previously. ? I can use dispwin -I Profile_path ?to install > a profile, but it doesn't persist as it did under previous versions of > Fedora (including Fedora 12). ?But, I can use the gnome color manager to > set the display profile, and that does seem topersist. How do you mean persist? dispwin is probably trying to set the gamma tables in xorg, which GPM is also trying to do. If you want to make GCM just leave everything to argyll, just untick the color tickbox in the GNOME session preferences. > I wonder if the gnome color management is somehow interfering with way > argyllcms ordinarily works. As I understand it, dispwin runs, sets some values and then exits. GCM runs gcm-apply at session start, and then also exits. If you run gcm-prefs, the settings probably get re-applied. I think it's probably a good idea to let GCM actually apply the profile, and use argyll to create the profile. If you dump the generated icc profile somewhere GCM knows about, that should work pretty well. > 2. ?In using the color manager to profile a laptop (running Ubuntu 10.4) > screen, and using my Eye One Pro, I encountered some problems. ?The > Eye-One Pro has to be calibrated on its base, but the color manager > doesn't ask me to do that. ?In order to get it done, I have to press > Details, which brings up the usual argyllcms command line interface. > But it is not clear exactly what I am supposed to do using that > interface and what using the color manager. Ideally we can control the hardware using something other than a VTE window. Using a VTE widget sucks as we always have to try and convert the standard output to something localized and sane. Newer, unreleased, versions of argyll allow us to set an environment variable and get some easier to parse values, but there's no support in GCM for that just yet, as we're waiting for a release. It's likely we just have to add another screenscrape section to deal with the "Please insert the device into the dock" type of thing. Screenscaping sucks, but there's not a lot more we can do. If you supply a "gcm-prefs --verbose" trace whilst you're calibrating I can add the required screenscrape bits. I don't have the hardware myself, although donations are always very welcome. > Also, ?the color manager didn't allow me to do any hardware calibration. > Of course, for my laptop screen that is somewhat restricted---the only > control is screen brightness. ?I don't know what will happen when I try > this an external monitor with lots of controls. ?Perhaps I am just > supposed ?to continue in the Details window with argyllcms commands? Do you mean monitors with a programmable LUT? We're aiming to support these kind of things in the next few months. Monitors that allow custom gamma ramps via DDC/CI are also interesting to me, although specs on those are kinda hard to get. Richard. From knizek.confy at volny.cz Tue Jul 27 12:22:14 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Tue, 27 Jul 2010 14:22:14 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> Message-ID: <1280233334.4390.8.camel@localhost> Thanks both Andrew and Richard for trying to help a Fedora newbie :-) Due to dependency hell with GTK+3 on Fedora 13 (trying to build Richard's SRPM), I finally found a way to upgrade to rawhide and did so. Dependencies are not a problem anymore, but compilation of the current GIT fails (I used Andrew's configure options, since strict checking fails much sooner during the compilation): $ ./configure --enable-compile-warnings=yes --disable-sane --disable-strict ...bla bla ... $ make ... bla bla ... Making all in tools make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' CC gcm_dump_profile-gcm-dump-profile.o CCLD gcm-dump-profile ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to `libusb_strerror' collect2: ld returned 1 exit status make[2]: *** [gcm-dump-profile] Error 1 make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' make: *** [all] Error 2 If I recall correctly, something similar appeared with the sources patched by Andrew to compile on Fedora 13. (Even with libusb1.) Any help? P.S. If I do not get further, I may install Fedora 13 x86_64 and try the Andres's binary instead. -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From luto at mit.edu Tue Jul 27 12:35:03 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 27 Jul 2010 08:35:03 -0400 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280233334.4390.8.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > Dependencies are not a problem anymore, but compilation of the current > GIT fails (I used Andrew's configure options, since strict checking > fails much sooner during the compilation): > > $ ./configure --enable-compile-warnings=yes --disable-sane > --disable-strict > ...bla bla ... > $ make > ... bla bla ... > > Making all in tools > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > ?CC ? ? gcm_dump_profile-gcm-dump-profile.o > ?CCLD ? gcm-dump-profile > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > `libusb_strerror' > collect2: ld returned 1 exit status > make[2]: *** [gcm-dump-profile] Error 1 > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > make: *** [all] Error 2 > > > If I recall correctly, something similar appeared with the sources > patched by Andrew to compile on Fedora 13. (Even with libusb1.) Yes. One of my patches removed a few calls to libusb_strerror. That function doesn't exist in Fedora's libusb-1.0. --Andy > > Any help? > > P.S. If I do not get further, I may install Fedora 13 x86_64 and try the > Andres's binary instead. > > -- > Milan Knizek > knizek (dot) confy (at) volny (dot) cz > http://www.milan-knizek.net - About linux and photography (Czech > language only) > > From hughsient at gmail.com Wed Jul 28 06:28:38 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 07:28:38 +0100 Subject: Possible interaction between the Color manager and Argyllcms In-Reply-To: <1280244947.2019.71.camel@localhost> References: <1280187928.2019.36.camel@localhost> <1280244947.2019.71.camel@localhost> Message-ID: On 27 July 2010 16:35, Leonard Evens wrote: > Under argyllcms, dispwin -I ?xxx.icc is supposed to load the table in > xorg, and create a file .config/olor.jcnf which tells where xxx.icc is located. > ... > But, according to Martin at the argyllcms mailing list, if you compile > argyllcms from source, it works as expected. Right, this makes sense. We don't compile the jncf bits in Fedora as it didn't compile with the system version of yajl, which we need to use in Fedora. It might be fairly easy to make argyll use the system version, in which case I think it's okay to turn on the jncf bits. > The way Argyllcms (and the Xrite software under Windows) works, you make > a series of adjustments to the monitor by using "hardware" controls for > Contrast, Brightness, and RGB values. You use them to set white point, > black point, etc. Argyllcms tells you how far off you are from your > target value in either direction. ?If you get these right, then the > calibration LUT loaded into Xorg is minimal and doesn't really change > screen appearance much. ?Is that what you mean by programmable LUT? No, programmable LUT is where you can send a 3D matrix to the monitor and it does most of the color calibration in hardware. You need a pretty nice monitor like an HP DreamColor to be able ot make use of this feature. GCM doesn't ask the user to set contrast and brightness manually, as ideally we can do this automatically using DDC/CI. That's one of the nice features that's on the TODO. Richard. From hughsient at gmail.com Wed Jul 28 09:02:54 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 10:02:54 +0100 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: On 27 July 2010 13:35, Andrew Lutomirski wrote: > Yes. ?One of my patches removed a few calls to libusb_strerror. ?That > function doesn't exist in Fedora's libusb-1.0. Can you give master a go please: commit a4dbe5e6ddf6e96f59826537dbbcc542e7fd5fa1 Author: Richard Hughes Date: Wed Jul 28 11:00:22 2010 +0200 Add gcm-compat.h to deal with unreleased versions of libusb :100644 100644 584ca05... de5cc4b... M configure.ac :100644 100644 71b8c89... 4c6c70d... M libcolor-glib/Makefile.am :000000 100644 0000000... 3e30993... A libcolor-glib/gcm-compat.h :100644 100644 c54a0cc... a5991dc... M libcolor-glib/gcm-sensor-huey.c :100644 100644 b5a628f... 043f832... M libcolor-glib/gcm-usb.c :100644 100644 39ab6b2... a96b102... M libcolor-glib/libcolor-glib.h Thanks, Richard. From jyqvklioo at googlemail.com Wed Jul 28 16:28:23 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 18:28:23 +0200 Subject: color managing libraries Message-ID: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Testing LCMS with photo editing showed noticeable color degradation on operations which should show none. I think I discovered why when I read LCMS documentation. LCMS is madness. It puts everything through the so called "sRGB" color space. For those who are not familiar with this color spare, it is designed to represent what CRT monitors show by default with no color management. It has a tiny color gamut and a discontinuity in gamma correction. (2 segments) LCMS needlessly truncates the gamut of any operation (which is not already in the sRGB color space) by converting colors to that color space unconditionally. Please, stop the madness. Do not use LCMS. Indications I saw in writing from the author (not addressed to me) indicate he is not receptive to acknowledging the poor handling his software does. I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? From hughsient at gmail.com Wed Jul 28 16:37:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Jul 2010 18:37:02 +0200 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 28 July 2010 18:28, wrote: > LCMS is madness. Nahh, I think lcms is actually pretty cool. > It puts everything through the so called "sRGB" color space. I don't think that's true at all, can you point to the docs (or code) that says that? > I am know little about Argyll, but will it suffice for all needs of gnome-color-manager? gnome-color-manager already uses argyll for its calibration needs, and lcms for it's internal pixel conversion stuff. Richard. From jyqvklioo at googlemail.com Wed Jul 28 19:23:50 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Wed, 28 Jul 2010 21:23:50 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > > I don't think that's true at all, can you point to the docs (or code) > that says that? I sought the text that gave me this impression and did not find it. It has been years since I read whatever it was. Possibly it was related to an image editing application which used LCMS rather than LCMS itself. The application which I saw the impressively bad results in was Krita. I tested where the source and all settable color spaces were not sRGB. From graeme2 at argyllcms.com Wed Jul 28 23:57:05 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 29 Jul 2010 09:57:05 +1000 Subject: color managing libraries In-Reply-To: <20100728212350.0cf065e9@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> <20100728212350.0cf065e9@jyqvklioo.googlemail.com> Message-ID: <4C50C3D1.6040804@argyllcms.com> jyqvklioo at googlemail.com wrote: > The application which I saw the impressively bad results in was Krita. > I tested where the source and all settable color spaces were not sRGB. Why jump to the conclusion that it's LCMS ? Color management is complicated. Just like the situation when programming, if it doesn't work the way you expect, the most likely explanation is that you've done something wrong. [From my observations on the lcms mailing list, Marti is very responsive to reports of problems.] Graeme Gill. From alexandre.prokoudine at gmail.com Thu Jul 29 00:17:58 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Thu, 29 Jul 2010 04:17:58 +0400 Subject: color managing libraries In-Reply-To: <20100728182823.7326cbef@jyqvklioo.googlemail.com> References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: On 7/28/10, jyqvklioo com> wrote: > Testing LCMS with photo editing showed noticeable color degradation on > operations which should show none. > I think I discovered why when I read LCMS documentation. > > LCMS is madness. > > It puts everything through the so called "sRGB" color space. > For those who are not familiar with this color spare, it is designed to > represent what CRT monitors show by default with no color management. > It has a tiny color gamut and a discontinuity in gamma correction. (2 > segments) > LCMS needlessly truncates the gamut of any operation (which is not already > in the sRGB color space) by converting colors to that color space > unconditionally. My dear jyqvklioo (do you work for a throat sweets manufacturer btw? :-)), I have a suspicion that you are confusing back-end with implementation. If Krita passes everything through sRGB, then it is because either it doesn't allow specifying a different working color space or it does allow that, but you didn't do it. LittleCMS has nothing to do with that. However feel free to prove me wrong and quote the bit from LittleCMS's docs that explicitly confirms your opinion. Alexandre Prokoudine http://libregraphicsworld.org From jyqvklioo at googlemail.com Thu Jul 29 06:47:07 2010 From: jyqvklioo at googlemail.com (jyqvklioo at googlemail.com) Date: Thu, 29 Jul 2010 08:47:07 +0200 Subject: color managing libraries In-Reply-To: References: <20100728182823.7326cbef@jyqvklioo.googlemail.com> Message-ID: <20100729084707.2f47845a@jyqvklioo.googlemail.com> > > It puts everything through the so called "sRGB" color space. > I don't think that's true at all, ... You do have experience with LCMS so I consider that in my estimation of odds. That combined with the notes I saw about increased accuracy in LCMS 2 and it being largely new code, I am optimistic and looking forward to trying out applications using LCMS, especially LCMS 2. From knizek.confy at volny.cz Sat Jul 31 07:26:25 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Sat, 31 Jul 2010 09:26:25 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> Message-ID: <1280561185.4362.6.camel@localhost> Andrew Lutomirski p??e v ?t 27. 07. 2010 v 08:35 -0400: > On Tue, Jul 27, 2010 at 8:22 AM, Milan Kn??ek wrote: > > Thanks both Andrew and Richard for trying to help a Fedora newbie :-) > > > > Due to dependency hell with GTK+3 on Fedora 13 (trying to build > > Richard's SRPM), I finally found a way to upgrade to rawhide and did so. > > > > Dependencies are not a problem anymore, but compilation of the current > > GIT fails (I used Andrew's configure options, since strict checking > > fails much sooner during the compilation): > > > > $ ./configure --enable-compile-warnings=yes --disable-sane > > --disable-strict > > ...bla bla ... > > $ make > > ... bla bla ... > > > > Making all in tools > > make[2]: Entering directory `/home/mu/src/gcm/gnome-color-manager/tools' > > CC gcm_dump_profile-gcm-dump-profile.o > > CCLD gcm-dump-profile > > ../libcolor-glib/.libs/libcolor-glib.so: undefined reference to > > `libusb_strerror' > > collect2: ld returned 1 exit status > > make[2]: *** [gcm-dump-profile] Error 1 > > make[2]: Leaving directory `/home/mu/src/gcm/gnome-color-manager/tools' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/mu/src/gcm/gnome-color-manager' > > make: *** [all] Error 2 > > > > > > If I recall correctly, something similar appeared with the sources > > patched by Andrew to compile on Fedora 13. (Even with libusb1.) > > Yes. One of my patches removed a few calls to libusb_strerror. That > function doesn't exist in Fedora's libusb-1.0. Hm, I have not noticed that earlier. After applying those referring to libusb_strerror, the compilation failed in a yet later stage, luckily after ./tools/gcm-dump-sensor. Attached is the dump file from Huey sold together with Samsung SyncMaster XL20. Regards, Milan -- Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) -------------- next part -------------- // AUTOMATICALLY GENERATED -- DO NOT EDIT generic-dump-version:1 kind:huey vendor:Gretag-Macbeth AG model:Huey serial-number:75951 device:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.1 huey-dump-version:1 unlock-string:GrMb register[0x00]:0x00 register[0x01]:0x01 register[0x02]:0x28 register[0x03]:0xaf register[0x04]:0x3d register[0x05]:0x3a register[0x06]:0x67 register[0x07]:0x67 register[0x08]:0xba register[0x09]:0xc3 register[0x0a]:0x91 register[0x0b]:0x35 register[0x0c]:0x3c register[0x0d]:0x3b register[0x0e]:0x38 register[0x0f]:0x92 register[0x10]:0x3a register[0x11]:0x86 register[0x12]:0x6c register[0x13]:0x57 register[0x14]:0x3c register[0x15]:0xe1 register[0x16]:0xb3 register[0x17]:0x52 register[0x18]:0x39 register[0x19]:0xd0 register[0x1a]:0x39 register[0x1b]:0xd5 register[0x1c]:0xba register[0x1d]:0x68 register[0x1e]:0x40 register[0x1f]:0xbe register[0x20]:0x3a register[0x21]:0xae register[0x22]:0x52 register[0x23]:0x53 register[0x24]:0x3d register[0x25]:0x8f register[0x26]:0x3c register[0x27]:0x20 register[0x28]:0xff register[0x29]:0xff register[0x2a]:0xff register[0x2b]:0xff register[0x2c]:0xff register[0x2d]:0xff register[0x2e]:0xff register[0x2f]:0xff register[0x30]:0xff register[0x31]:0xff register[0x32]:0x45 register[0x33]:0x2b register[0x34]:0xe7 register[0x35]:0x9f register[0x36]:0x3d register[0x37]:0x39 register[0x38]:0x16 register[0x39]:0x8b register[0x3a]:0xbb register[0x3b]:0x12 register[0x3c]:0xed register[0x3d]:0xef register[0x3e]:0x3c register[0x3f]:0x23 register[0x40]:0xe3 register[0x41]:0x36 register[0x42]:0x3a register[0x43]:0x9e register[0x44]:0xef register[0x45]:0x06 register[0x46]:0x3c register[0x47]:0xd6 register[0x48]:0xfa register[0x49]:0x9f register[0x4a]:0x39 register[0x4b]:0xc1 register[0x4c]:0x79 register[0x4d]:0x37 register[0x4e]:0xba register[0x4f]:0x8d register[0x50]:0x39 register[0x51]:0x53 register[0x52]:0x3a register[0x53]:0x81 register[0x54]:0xf4 register[0x55]:0x46 register[0x56]:0x3d register[0x57]:0x8c register[0x58]:0x5c register[0x59]:0xa7 register[0x5a]:0x45 register[0x5b]:0x18 register[0x5c]:0xa5 register[0x5d]:0x90 register[0x5e]:0xff register[0x5f]:0xff register[0x60]:0xff register[0x61]:0xff register[0x62]:0xff register[0x63]:0xff register[0x64]:0xff register[0x65]:0xff register[0x66]:0xff register[0x67]:0x3c register[0x68]:0x98 register[0x69]:0xa8 register[0x6a]:0x9d register[0x6b]:0x3c register[0x6c]:0x65 register[0x6d]:0x60 register[0x6e]:0x41 register[0x6f]:0x3c register[0x70]:0x65 register[0x71]:0x60 register[0x72]:0x41 register[0x73]:0xff register[0x74]:0x09 register[0x75]:0x71 register[0x76]:0x20 register[0x77]:0x05 register[0x78]:0xff register[0x79]:0xff register[0x7a]:0x47 register[0x7b]:0x72 register[0x7c]:0x4d register[0x7d]:0x62 register[0x7e]:0x00 register[0x7f]:0x0e register[0x80]:0x01 register[0x81]:0x99 register[0x82]:0x69 register[0x83]:0x00 register[0x84]:0x02 register[0x85]:0x20 register[0x86]:0xf4 register[0x87]:0xee register[0x88]:0x02 register[0x89]:0x20 register[0x8a]:0xf4 register[0x8b]:0xee register[0x8c]:0x16 register[0x8d]:0xe4 register[0x8e]:0x00 register[0x8f]:0xff register[0x90]:0xff register[0x91]:0xff register[0x92]:0xff register[0x93]:0xff register[0x94]:0x3a register[0x95]:0x99 register[0x96]:0xc8 register[0x97]:0x02 register[0x98]:0xff register[0x99]:0xff register[0x9a]:0xff register[0x9b]:0xff register[0x9c]:0xff register[0x9d]:0xff register[0x9e]:0xff register[0x9f]:0xff register[0xa0]:0xff register[0xa1]:0xff register[0xa2]:0xff register[0xa3]:0xff register[0xa4]:0xff register[0xa5]:0xff register[0xa6]:0xff register[0xa7]:0xff register[0xa8]:0xff register[0xa9]:0xff register[0xaa]:0xff register[0xab]:0xff register[0xac]:0xff register[0xad]:0xff register[0xae]:0xff register[0xaf]:0xff register[0xb0]:0xff register[0xb1]:0xff register[0xb2]:0xff register[0xb3]:0xff register[0xb4]:0xff register[0xb5]:0xff register[0xb6]:0xff register[0xb7]:0xff register[0xb8]:0xff register[0xb9]:0xff register[0xba]:0xff register[0xbb]:0xff register[0xbc]:0xff register[0xbd]:0xff register[0xbe]:0xff register[0xbf]:0xff register[0xc0]:0xff register[0xc1]:0xff register[0xc2]:0xff register[0xc3]:0xff register[0xc4]:0xff register[0xc5]:0xff register[0xc6]:0xff register[0xc7]:0xff register[0xc8]:0xff register[0xc9]:0xff register[0xca]:0xff register[0xcb]:0xff register[0xcc]:0xff register[0xcd]:0xff register[0xce]:0xff register[0xcf]:0xff register[0xd0]:0xff register[0xd1]:0xff register[0xd2]:0xff register[0xd3]:0xff register[0xd4]:0xff register[0xd5]:0xff register[0xd6]:0xff register[0xd7]:0xff register[0xd8]:0xff register[0xd9]:0xff register[0xda]:0xff register[0xdb]:0xff register[0xdc]:0xff register[0xdd]:0xff register[0xde]:0xff register[0xdf]:0xff register[0xe0]:0xff register[0xe1]:0xff register[0xe2]:0xff register[0xe3]:0xff register[0xe4]:0xff register[0xe5]:0xff register[0xe6]:0xff register[0xe7]:0xff register[0xe8]:0xff register[0xe9]:0xff register[0xea]:0xff register[0xeb]:0xff register[0xec]:0xff register[0xed]:0xff register[0xee]:0xff register[0xef]:0xff register[0xf0]:0xff register[0xf1]:0xff register[0xf2]:0xff register[0xf3]:0xff register[0xf4]:0xff register[0xf5]:0xff register[0xf6]:0xff register[0xf7]:0xff register[0xf8]:0xff register[0xf9]:0xff register[0xfa]:0xff register[0xfb]:0xff register[0xfc]:0xff register[0xfd]:0xff register[0xfe]:0xff From hughsient at gmail.com Sat Jul 31 07:52:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 31 Jul 2010 09:52:45 +0200 Subject: [GROSS HACK] building libcolor-glib and tools on F13 In-Reply-To: <1280561185.4362.6.camel@localhost> References: <96d32e4dee1223b7465669080db3cfe7d93ddb8b.1280155332.git.luto@mit.edu> <1280172755.4389.13.camel@localhost> <1280233334.4390.8.camel@localhost> <1280561185.4362.6.camel@localhost> Message-ID: On 31 July 2010 09:26, Milan Kn??ek wrote: > Attached is the dump file from Huey sold together with Samsung > SyncMaster XL20. Great, thanks. I'll analyze your dump and Pascals after I return from GUADEC. Richard.