From hughsient at gmail.com Tue Jun 1 11:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 1 Jun 2010 12:44:10 +0100 Subject: GNOME Color Manager 2.30.2 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.30.2 ~~~~~~~~~~~~~~ Released: 2010-06-01 * Translations - Added Japanese translation (Ryo Fujita) - Updated British English translation (Bruce Cowan) * Bugfix: - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not crash when the schema is invalid and GConf reports an error (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed. Fixes rh#590465 (Richard Hughes) - Get the profile permissions from GIO rather than hardcoding a hack (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 2 07:42:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 08:42:39 +0100 Subject: GNOME Color Manager accepted into desktop module for 2.32.x Message-ID: Some great news: The GNOME release team met in May to discuss potential modules to be added to GNOME, and they approved gnome-color-manager into the desktop set. This means that distros that ship GNOME 2.32 will also be shipping gnome-color-manager by default. The release team noted the excellent integration of GCM into the desktop, and did not gather a single negative problem or issue to watch. What this means for GCM: More work, more users and more bugs. * We have to do releases with the GNOME release schedule * We have to fix up any deviations from the Human Interface Guidelines * We have to keep random dependencies like exiv2 and SANE as optional build time deps. * We have to start testing on Solaris, FreeBSD and non-xorg platforms and adding portability fixes and code where required. * We have to remove deprecated module usage (GConf2 and dbus-glib are already gone in master) It's started a good day for me, as this recognizes the importance of color management in the GNOME desktop, and the programming, testing, artwork and translations from me and all you guys and girls. In the coming months I'm going to need more help translating, testing, checking, fixing and triaging bugs, so we can produce a gnome-color-manager-2.32.0 that we're proud of. Thanks. Richard. From hughsient at gmail.com Wed Jun 2 10:25:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 11:25:16 +0100 Subject: GCM and LGM 2010 Message-ID: Not being at LGM 2010 (too little travel budget, and in the middle of buying a house) I missed out on lots of important discussions. Can anybody who went fill in any details? What presentations were relevant to GCM? Was GCM discussed at all? Thanks. Richard. From hughsient at gmail.com Wed Jun 2 11:40:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 12:40:21 +0100 Subject: GNOME Color Manager 2.31.2 Message-ID: Version 2.31.2 ~~~~~~~~~~~~~~ Released: 2010-06-02 * Notes - You'll need Glib 2.25.1 and VTE 0.25.1 to compile now. - Lots of the new functionality is checked for at build time. Ensure you have development packages for cups, sane-backends, libtiff, libexif and exiv2 for full functionality. * Translations - Updated Czech translation (Milan Knizek) - Updated Danish translation (Ask H. Larsen) - Updated Estonian translation (Mattias P?ldaru) - Updated French translation (Claude Paroz) - Updated German doc translation (Mario Bl?ttermann) - Updated German translation (Christian Kirbach) - Updated German translation (Mario Bl?ttermann) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Port to GDBus (Richard Hughes) - Port to GSettings (Richard Hughes) - Port to GTest (Richard Hughes) - Add UI elements to assign multiple profiles for each device (Richard Hughes) - Add GetProfilesForFile() DBus method to get suitable ICC profiles for a given file (Richard Hughes) - Add a GConf to GSettings migration script (Richard Hughes) - Add optional exif2 support so we can get properties of RAW files (Richard Hughes) - Allow the user to just drag an image file onto the window to create a virtual profile (Richard Hughes) - Allow the user to double click a profile to make it default (Richard Hughes) * Bugfix: - Add a message in the help file explaining the drop file action (Richard Hughes) - Add gcm_profile_get_can_delete() and get the permissions from GIO rather than hardcoding a hack (Richard Hughes) - Add gcm_profile_get_checksum() so we can use this as a key to detect duplicates (Richard Hughes) - Add some information labels to the defaults pane (Richard Hughes) - Add two new settings objects 'enable-sane' and 'enable-cups' for in-field debugging (Richard Hughes) - Allow adding saved devices when coldplugging (Richard Hughes) - Allow RAW files to be dragged onto the UI with spaces in the name (Richard Hughes) - Allow virtual devices to have a serial number (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) - Ignore duplicate profiles by the MD5 checksum (Richard Hughes) - Include the serial number in the virtual device ID (Richard Hughes) - Include the trailing colon in translated strings. Fixes #619967 (Richard Hughes) - Migrate the old device-profiles.conf to the new location so the user does not have to do it manually (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed (Richard Hughes) - Do not bother the user with calibration notifications by default (Richard Hughes) - Put a short intent description in the combobox choices (Richard Hughes) - Support version 0.2 of the OpenIccDirectoryProposal (Richard Hughes) - Use the new ARGYLL_NOT_INTERACTIVE environment variable (Richard Hughes) - Use the newer VTE API (Richard Hughes) Richard. From pmjdebruijn at pcode.nl Thu Jun 3 17:18:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 3 Jun 2010 19:18:37 +0200 Subject: GCM and LGM 2010 In-Reply-To: References: Message-ID: On Wed, Jun 2, 2010 at 12:25 PM, Richard Hughes wrote: > Not being at LGM 2010 (too little travel budget, and in the middle of > buying a house) I missed out on lots of important discussions. Can > anybody who went fill in any details? What presentations were relevant > to GCM? Was GCM discussed at all? I was present for at least a day... I attended the OpenICC meeting... Kai-Uwe did a presentation on Oyranos which I sadly mostly missed :( I did talk to Kai-Uwe at the OpenICC meeting though, amongst other things we talked about how color management apps should interface with each other, and I pointed to GCM and it's DBUS API... Nobody present seemed to object to use DBUS for such a purpose... I do think they video'd most talks, so I guess you can still view most talks in a couple of days :) Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jun 10 13:39:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 10 Jun 2010 14:39:40 +0100 Subject: GNOME Color Manager: a question about some terms In-Reply-To: <20100610144011.4f613909@anche.no> References: <20100610144011.4f613909@anche.no> Message-ID: On 10 June 2010 13:40, F. Gr. wrote: > I'm translating GNOME Color Manager for Italian language. Great, thanks! > I would know > the differences among the terms "reference image", "chart type" and > "calibrated target". Have you got any links that explains the ones? Well, if it's unclear, we probably have to include things like that in the translator comments, and it also sounds like we're using different terms for the same thing. I've applied this to git master: commit d08e4ef23f7c50b754f8572ba139bdc2312abd1d Author: Richard Hughes Date: Thu Jun 10 14:38:11 2010 +0100 Use the same term 'calibration target' thoughout the UI Can you git pull from master again please, and then verify things are a bit easier to translate? I would also be interested in any other parts you found difficult. Thanks. Richard. From hughsient at gmail.com Mon Jun 14 16:09:27 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:09:27 +0100 Subject: What I've been up to... Message-ID: It's been a bit quiet from me recently. What I've been doing: * UI cleanups in the prefs widget * Porting everything to GNOME 3 * Working on full screen color management --- Wait. Full screen? Yup. I've been working on the mutter window manager to use GLSL shaders to do color correction on the GPU in hardware. Hopefully, it'll all be native in the window manager and only need a few tweaks to applications. It's early days, but it seems to work very well. I've attached a screenshot for your drooling pleasure. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 178361 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Mon Jun 14 16:36:21 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 18:36:21 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 6:09 PM, Richard Hughes wrote: > It's been a bit quiet from me recently. What I've been doing: > > * UI cleanups in the prefs widget > * Porting everything to GNOME 3 > * Working on full screen color management > > --- Wait. Full screen? > > Yup. I've been working on the mutter window manager to use GLSL > shaders to do color correction on the GPU in hardware. Hopefully, > it'll all be native in the window manager and only need a few tweaks > to applications. It's early days, but it seems to work very well. > > I've attached a screenshot for your drooling pleasure. I was already pretty happy with the current state of affairs... But this will rock severely :) Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 14 16:44:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:44:45 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 17:36, Pascal de Bruijn wrote: > I was already pretty happy with the current state of affairs... But > this will rock severely :) Well, it's early days -- but this should help the eyes of those lucky enough to have large-gamut monitors. Richard. From alexandre.prokoudine at gmail.com Mon Jun 14 17:42:26 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 21:42:26 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Richard Hughes wrote: > Well, it's early days -- but this should help the eyes of those lucky > enough to have large-gamut monitors. Exactly how? Will it make the profile be applied to displays LUT? :) Alexandre From pmjdebruijn at pcode.nl Mon Jun 14 17:50:46 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 19:50:46 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 7:42 PM, Alexandre Prokoudine wrote: > On 6/14/10, Richard Hughes wrote: > >> Well, it's early days -- but this should help the eyes of those lucky >> enough to have large-gamut monitors. > > Exactly how? Will it make the profile be applied to displays LUT? :) It's not... Since most displays don't have a programmable LUT... unless you want to spend 1500USD+ Not even talking about the fact that (as far as I know) there is no standardized way to load a LUT into the different brands of LCDs. Regards, Pascal de Bruijn From alexandre.prokoudine at gmail.com Mon Jun 14 18:20:01 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 22:20:01 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Pascal de Bruijn wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > It's not... Since most displays don't have a programmable LUT... > unless you want to spend 1500USD+ But I did spend it :) > Not even talking about the fact that (as far as I know) there is no > standardized way to load a LUT into the different brands of LCDs. >From what I remember they all used to rely on just two different chips. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jun 14 21:18:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:18:43 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 19:20, Alexandre Prokoudine wrote: >> It's not... Since most displays don't have a programmable LUT... >> unless you want to spend 1500USD+ > > But I did spend it :) Sure, it's very possible using i2c. I've used i2c quite a lot in my last job. The tricky bit is wiring it into Xorg, as i2c is pretty slow (at least in non-high speed mode) and X can't spawn extra threads. I also don't think you need to spend that much money if you want to be able to program the display LUT. I'm pretty sure I can do it on my ?200 LG screen. Richard. From hughsient at gmail.com Mon Jun 14 21:20:33 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:20:33 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 18:42, Alexandre Prokoudine wrote: > Exactly how? Will it make the profile be applied to displays LUT? :) No, but it should be useful for people with profiles without vcgt tags, and also to correct color casts. Richard. From luto at mit.edu Tue Jun 15 06:57:23 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 15 Jun 2010 02:57:23 -0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 5:20 PM, Richard Hughes wrote: > On 14 June 2010 18:42, Alexandre Prokoudine > wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > No, but it should be useful for people with profiles without vcgt > tags, and also to correct color casts. Are you planning on supporting CLUT or just matrix+shaper? And what does this do to vcgt? I'd guess that if we can't program our monitors' LUTs then we're better off not using vcgt and improving our gamut a touch. --Andy From hughsient at gmail.com Tue Jun 15 08:38:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 Jun 2010 09:38:02 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 15 June 2010 07:57, Andrew Lutomirski wrote: > Are you planning on supporting CLUT or just matrix+shaper? Both I guess. > And what does this do to vcgt? ?I'd guess that if we can't program our > monitors' LUTs then we're better off not using vcgt and improving our > gamut a touch. Yes, I'm not sure applying VCGT makes much sense if we're doing a 3d LUT. Richard. From lists+gnome-color-manager at hoech.org Tue Jun 15 15:55:11 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Tue, 15 Jun 2010 17:55:11 +0200 Subject: Installing display profiles/interfacing with gcm Message-ID: <4C17A25F.7060806@hoech.org> Hi, I'm currently looking for a way to install display profiles in a similar way as Argyll's dispwin does. So, I'm either looking for an utility 'gcm-install-display-profile' that would copy the file, do the mapping displayno->device and write the neccessary info to device-profiles.conf (does gcm-install-systemwide do this?). Or for another way to achieve what I just described (DBus?). Reason I'm asking is I'd like to offer profile installation in a GCM-compatible way in dispcalGUI if GCM is also installed, as I'm currently only supporting the Argyll dispwin (UCMM) way. Or is it safe/recommended to write to device-profiles.conf directly? Then, I'd just have to figure out how to do the Argyll displayno -> GCM device mapping (btw, what's the $(ascii) in xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). Pointers welcome :) Thanks in advance and regards -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 10:41:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 11:41:11 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C17A25F.7060806@hoech.org> References: <4C17A25F.7060806@hoech.org> Message-ID: On 15 June 2010 16:55, Florian H?ch wrote: > I'm currently looking for a way to install display profiles in a similar way > as Argyll's dispwin does. So, I'm either looking for an utility > 'gcm-install-display-profile' that would copy the > file, do the mapping displayno->device and write the neccessary info to > device-profiles.conf (does gcm-install-systemwide do this?). No, gcm-install-systemwide just installs the profiles system-wide. It's also pretty fragile the way it works, and probably needs rethinking in the near future. > Or for another way to achieve what I just described (DBus?). I think a DBus call would be okay, but it seems very specific to this use case. GCM also stores other data with the profile entry which would need to be formatted like the others by dispcalGUI. > Or is it safe/recommended to write to device-profiles.conf directly? I guess. If GCM is open at the time then it might cause problems, but I can always add an inotify watch on the config file and reload GCM's in-memory copy if it changes. I'm not sure this is a great idea, as the config file has no locking, and no ABI stability. > Then, I'd just have to figure out how to do the Argyll displayno -> GCM > device mapping (btw, what's the $(ascii) in > xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". I'm fully open to changing the format of the device-profiles.conf file if required. That could mean adding a hash=${md5_of_edid} parameter to the display section, or it could be just making the identifier be xrandr_${md5_of_edid} -- but then we have all the problems of writing the junk data required to display a meaningful device icon when the display is not attached. If the user has already run gcm-prefs and the device was saved, and you just want to change the default, then searching on hash= is probably the right thing to do. Of course, the best option is probably for GCM to expose libgcm (better names welcome) which would allow you to just call gcm_device_save() trivially in C. It would mean a compile-time optional dep on GCM, but it probably the most correct thing to do. Comments please. :-) Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 12:00:02 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 14:00:02 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> Message-ID: <4C18BCC2.20107@hoech.org> Am 16.06.2010 12:41, schrieb Richard Hughes: > On 15 June 2010 16:55, Florian H?ch wrote: >> I'm currently looking for a way to install display profiles in a similar way >> as Argyll's dispwin does. So, I'm either looking for an utility >> 'gcm-install-display-profile' that would copy the >> file, do the mapping displayno->device and write the neccessary info to >> device-profiles.conf (does gcm-install-systemwide do this?). > > No, gcm-install-systemwide just installs the profiles system-wide. > It's also pretty fragile the way it works, and probably needs > rethinking in the near future. Ok. >> Or for another way to achieve what I just described (DBus?). > > I think a DBus call would be okay, but it seems very specific to this > use case. GCM also stores other data with the profile entry which > would need to be formatted like the others by dispcalGUI. > >> Or is it safe/recommended to write to device-profiles.conf directly? > > I guess. If GCM is open at the time then it might cause problems, but > I can always add an inotify watch on the config file and reload GCM's > in-memory copy if it changes. I'm not sure this is a great idea, as > the config file has no locking, and no ABI stability. Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last resort". >> Then, I'd just have to figure out how to do the Argyll displayno -> GCM >> device mapping (btw, what's the $(ascii) in >> xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). > > It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". Ah, ok. So then all the naming information is available through the EDID? That's fine with me. > I'm > fully open to changing the format of the device-profiles.conf file if > required. That could mean adding a hash=${md5_of_edid} parameter to > the display section, or it could be just making the identifier be > xrandr_${md5_of_edid} -- but then we have all the problems of writing > the junk data required to display a meaningful device icon when the > display is not attached. If the user has already run gcm-prefs and the > device was saved, and you just want to change the default, then > searching on hash= is probably the right thing to do. Agreed on your points. I think the format of the config file is fine, although addition of the EDID hash key sounds like a nice idea. > Of course, the best option is probably for GCM to expose libgcm > (better names welcome) which would allow you to just call > gcm_device_save() trivially in C. It would mean a compile-time > optional dep on GCM, but it probably the most correct thing to do. That would be nice, then I could let GCM do "the right thing" for me. Dep on GCM is not a problem I think, as I'm probably going to use Python's ctypes then, which can tell me if the library is installed and I can also use it to wrap the C function call. Thanks for the infos so far! > Comments please. :-) > > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 14:13:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 15:13:55 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18BCC2.20107@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: On 16 June 2010 13:00, Florian H?ch wrote: > Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last > resort". Right. The lack of locking makes this a quick fix, but probably not a good idea. > Ah, ok. So then all the naming information is available through the EDID? Right. > Agreed on your points. I think the format of the config file is fine, > although addition of the EDID hash key sounds like a nice idea. commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 Author: Richard Hughes Date: Wed Jun 16 15:04:38 2010 +0100 Save the EDID MD5 hash to device-profiles.conf for xrandr devices > That would be nice, then I could let GCM do "the right thing" for me. Dep on > GCM is not a problem I think, as I'm probably going to use Python's ctypes > then, which can tell me if the library is installed and I can also use it to > wrap the C function call. Right, this is probably the best thing to do. I'll look at librification now, although it's quite a big change, and it might make sense for the gnome3 stuff to settle down first. Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 15:58:35 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 17:58:35 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: <4C18F4AB.50809@hoech.org> Am 16.06.2010 16:13, schrieb Richard Hughes: >> On 16 June 2010 13:00, Florian H?ch wrote: >>> Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last >>> resort". >> >> Right. The lack of locking makes this a quick fix, but probably not a good idea. >> >>> Ah, ok. So then all the naming information is available through the EDID? >> >> Right. >> >>> Agreed on your points. I think the format of the config file is fine, >>> although addition of the EDID hash key sounds like a nice idea. >> >> commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 >> Author: Richard Hughes >> Date: Wed Jun 16 15:04:38 2010 +0100 >> >> Save the EDID MD5 hash to device-profiles.conf for xrandr devices Cool, thanks! >>> That would be nice, then I could let GCM do "the right thing" for me. Dep on >>> GCM is not a problem I think, as I'm probably going to use Python's ctypes >>> then, which can tell me if the library is installed and I can also useit to >>> wrap the C function call. >> >> Right, this is probably the best thing to do. I'll look at >> librification now, although it's quite a big change, and it might make >> sense for the gnome3 stuff to settle down first. >> >> Richard. No need to hurry, I'm glad you're looking into it! :) -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jun 17 14:58:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 Jun 2010 15:58:20 +0100 Subject: Next release tomorrow Message-ID: I'm having to do a new development release of GCM tomorrow. GLib and GTK both changed API this point release, and we're trying to co-ordinate so there isn't breakage for the devel distros. If you've got pending translations, please merge them before tomorrow morning. Thanks. Richard. From lists at hoech.net Fri Jun 18 18:24:16 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 18 Jun 2010 20:24:16 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18F4AB.50809@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> <4C18F4AB.50809@hoech.org> Message-ID: <4C1BB9D0.4070803@hoech.net> I've now added rudimentary support for GCM in the upcoming next release of dispcalGUI (changes are not yet in SVN though). If GCM is installed and XRandR is working, I'm parsing EDID and also device-profiles.conf (only reading) to add necessary/useful info like manufacturer and model to the profile thats going to be installed, before gcm-import is called to bring the profile inside GCM. This way seems to work pretty well and can still be replaced later. -- Florian H?ch http://hoech.net From hughsient at gmail.com Mon Jun 21 08:03:44 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 09:03:44 +0100 Subject: Switching to lcms2? Message-ID: Does anybody have an problems if gnome-color-manager switches to lcms2 later this week? Richard. From pmjdebruijn at pcode.nl Mon Jun 21 08:44:08 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 10:44:08 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: > Does anybody have an problems if gnome-color-manager switches to lcms2 > later this week? Since the GSettings stuff already breaks compatibility with older distro's, I don't see why lcms2 would cause any additional problems... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 10:44:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 11:44:20 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 09:44, Pascal de Bruijn wrote: > On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >> Does anybody have an problems if gnome-color-manager switches to lcms2 >> later this week? > > Since the GSettings stuff already breaks compatibility with older > distro's, I don't see why lcms2 would cause any additional problems... This was my thought too. Richard. From pmjdebruijn at pcode.nl Mon Jun 21 10:52:34 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 12:52:34 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 12:44 PM, Richard Hughes wrote: > On 21 June 2010 09:44, Pascal de Bruijn wrote: >> On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >>> Does anybody have an problems if gnome-color-manager switches to lcms2 >>> later this week? >> >> Since the GSettings stuff already breaks compatibility with older >> distro's, I don't see why lcms2 would cause any additional problems... > > This was my thought too. I did notice LCMS2 hasn't hit the Debian package repo's yet... But it's still early after it's release... So I guess that'll get fixed before (for example) the next Ubuntu is released... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 16:06:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 17:06:35 +0100 Subject: GNOME Color Manager 2.31.3 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.3 ~~~~~~~~~~~~~~ Released: 2010-06-21 * Translations - Added Galician translations (Fran Di?guez) - Added Hebrew translation (Yaron Shahrabani) - Added Norwegian bokm?l translation (Kjartan Maraas) - Updated Indonesian translation (Andika Triwidada) - Updated Italian translation (Francesco Groccia) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Punjabi Translation (A S Alam) - Updated Spanish translation (Jorge Gonz?lez) - Updated Galician translations (Fran Di?guez) - Updated Hebrew translation (Yaron Shahrabani) * New Features: - Require GTK3 as per the GNOME release team announcement (Richard Hughes) - Port to GtkApplication (Richard Hughes) - Port to GDBus (Richard Hughes) - Use the GSetting enum functionality (Richard Hughes) - Make libnotify optional dependency as it relies on gtk-2.0 (Richard Hughes) - Make VTE optional as it relies on gtk-2.0 (Richard Hughes) - Require libcanberra-gtk3 (Richard Hughes) - Require gnome-desktop3 (Richard Hughes) * Bugfix: - Disconnect the VTE callbacks when ending the calibration to prevent a nasty crash (Richard Hughes) - Only emit ::added signals from the main thread, not the coldplug threads (Richard Hughes) - Redo the graph UI in the profiles page to be more HIG friendly (Richard Hughes) - Save the EDID MD5 hash to device-profiles.conf for xrandr devices (Richard Hughes) - Set the calibrate button insensitive if VTE is unavailable (Richard Hughes) - Use the same term 'calibration target' thoughout the UI (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 23 13:06:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:06:32 +0100 Subject: Gray profiles Message-ID: Does anybody actually use gray ICC profiles? Would it make sense to add a UI element for this type of profile? Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:20:47 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:20:47 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: > Does anybody actually use gray ICC profiles? Yes, Photoshop's grey profiles are a must to properly use greyscale images in Scribus. Sad but true. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Wed Jun 23 13:26:30 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:26:30 +0100 Subject: Gray profiles In-Reply-To: References: Message-ID: On 23 June 2010 14:20, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: >> Does anybody actually use gray ICC profiles? > > Yes, Photoshop's grey profiles are a must to properly use greyscale > images in Scribus. Sad but true. Do we have any open source or BSD gray icc profiles in any existing projects? Thanks, Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:29:56 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:29:56 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: >> Yes, Photoshop's grey profiles are a must to properly use greyscale >> images in Scribus. Sad but true. > > Do we have any open source or BSD gray icc profiles in any existing projects? Not that I know of. I was intending to look into it, but never found enough time and I'm currently lacking expertize in profiles creation anyway. Alexandre Prokoudine http://libregraphicsworld.org From pmjdebruijn at pcode.nl Wed Jun 23 16:00:36 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 23 Jun 2010 18:00:36 +0200 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 3:29 PM, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: > >>> Yes, Photoshop's grey profiles are a must to properly use greyscale >>> images in Scribus. Sad but true. >> >> Do we have any open source or BSD gray icc profiles in any existing projects? > > Not that I know of. I was intending to look into it, but never found > enough time and I'm currently lacking expertize in profiles creation > anyway. Maybe it's just me... But it doesn't sound like this would be to hard to do... I mean... You can't get the color wrong :) Regards, Pascal de Bruijn From graeme2 at argyllcms.com Thu Jun 24 03:44:13 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 24 Jun 2010 13:44:13 +1000 Subject: Gray profiles In-Reply-To: References: Message-ID: <4C22D48D.5020901@argyllcms.com> Pascal de Bruijn wrote: > I mean... You can't get the color wrong :) Yes you can. For a cLUT profile the A2B needs to map the colorant value to PCS, and your PCS value could have the wrong color ... Graeme Gill. From hughsient at gmail.com Thu Jun 24 11:08:22 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 12:08:22 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 11:52, Pascal de Bruijn wrote: > I did notice LCMS2 hasn't hit the Debian package repo's yet... But > it's still early after it's release... So I guess that'll get fixed > before (for example) the next Ubuntu is released... Okay, gnome-color-manager in git master now requires lcms2. This also means we can start to write ICC profiles with vcgt tags ourselves, to do things like manual calibration without calibration equipment. Richard. From hughsient at gmail.com Thu Jun 24 12:47:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 13:47:56 +0100 Subject: Photography contest! Message-ID: I need a sample image that will be used in the GNOME Color Manager profile viewer. The image will be changed according to the input and output color spaces, so the user can see what affect the profile has on a typical (example) image. This is an ideal task if you want to help the project, but can't code. So, the image has to be: * GPLv2+ or public domain * 200 pixels high by 400 pixels wide * Brightly colored, with lots of different types of color and shade * Nothing controversial, i.e. no photos of naked ladies or of a BP oil spill... * Interesting, not just a sunset or picture of water * Be saved as sRGB png format (although it's okay if that makes it look a bit odd...) The image has to show clearly what difference sRGB, Adobe and ProPhoto have when importing and exporting, so having some out of sRGB gamut colors would be ideal. Let the contest begin. :-) Richard. From hughsient at gmail.com Tue Jun 29 12:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:05:36 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? Message-ID: I'm pondering adding i2c-encoding functionality to GCM to allow us to reprogram the external panel gamma ramps, rather than using X. Using X has the disadvantage of lowering the number of colors we can display, as we artificially have to limit the gamut range when setting the VCGT tag. Changing this on the monitor itself gives us the advantage of not lowing the gamut range, as it's hopefully operating later in the analog chain. Ideas and feedback welcome. If anyone has ever tried this before, I would appreciate any advice. Thanks. Richard. From graeme2 at argyllcms.com Tue Jun 29 12:32:48 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Tue, 29 Jun 2010 22:32:48 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: Message-ID: <4C29E7F0.2020101@argyllcms.com> Richard Hughes wrote: > Ideas and feedback welcome. If anyone has ever tried this before, I > would appreciate any advice. Thanks. Naturally I've considered this. The problems are: There is no standard X mechanisms for doing this. X accesses the monitors i2c to load the EDID, but doesn't provide a general purpose communication channel. The logical place for it is in XRandR, since it knows about outputs (monitors). Although the i2c might be accessed elsewhere in Linux, there is the problem of figuring out the association between the i2c and the outputs. The above wouldn't have stopped me doing this for MSWin and OS X, but there is the second problem: there is no standard i2c video monitor protocol for this. Each manufacturer can do it their own way, and doesn't publish how they do it. You have to reverse engineer it for each monitor. Without access to a representative set of monitors, the coverage of monitors is likely to be spotty. (I don't have a single monitor with this feature.) Graeme Gill. From hughsient at gmail.com Tue Jun 29 12:59:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:59:48 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: <4C29E7F0.2020101@argyllcms.com> References: <4C29E7F0.2020101@argyllcms.com> Message-ID: On 29 June 2010 13:32, Graeme Gill wrote: > Naturally I've considered this. I had hoped so :-) > ? ? ? ?There is no standard X mechanisms for doing this. X accesses > the monitors i2c to load the EDID, but doesn't provide a general purpose > communication channel. The logical place for it is in XRandR, since it > knows about outputs (monitors). Although the i2c might be accessed elsewhere > in Linux, there is the problem of figuring out the association between > the i2c and the outputs. Right, I've looked at doing this in X (or the kernel, via KMS) and it basically comes down to ic2 being so slow. X can't run threaded, and using i2c means we have to block for huge amounts of time. Doing it in the kernel makes threads possible, although it makes things much harder in other ways. > The above wouldn't have stopped me doing this for MSWin and OS X, > but there is the second problem: there is no standard i2c video monitor > protocol for this. Each manufacturer can do it their own way, and > doesn't publish how they do it. You have to reverse engineer it > for each monitor. Without access to a representative set of > monitors, the coverage of monitors is likely to be spotty. Right, agreed. I've been looking at the database table in ddcontrol and it only supports a few monitors out of the thousands of different kinds ever made. With no agreed standard, I agree this is a classic chicken and egg thing. I've been trying to use the standard (no quirks) mode of ddcontrol and it seems to work kinda-okay, although that could be me getting lucky. > (I don't have a single monitor with this feature.) I've got an LG monitor with this functionality, although I'm only basing all my assumptions of "it'll work fine" on a sample size of 1. Whether it's worth doing, I'm not sure. Maybe effort is better put into putting the color conversion into a GLSL shader rather than poking about with VCGT-type data. Richard. From graeme2 at argyllcms.com Tue Jun 29 14:45:39 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Wed, 30 Jun 2010 00:45:39 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: <4C29E7F0.2020101@argyllcms.com> Message-ID: <4C2A0713.4040206@argyllcms.com> Richard Hughes wrote: > Right, I've looked at doing this in X (or the kernel, via KMS) and it > basically comes down to ic2 being so slow. X can't run threaded, and > using i2c means we have to block for huge amounts of time. Doing it in > the kernel makes threads possible, although it makes things much > harder in other ways. Hmm. A way around this would be to expose the i2c bus at a very low level through X, and rely on the caller to do the timing. (I think that the OS X stuff almost works at this level). > Right, agreed. I've been looking at the database table in ddcontrol > and it only supports a few monitors out of the thousands of different > kinds ever made. With no agreed standard, I agree this is a classic > chicken and egg thing. I've been trying to use the standard (no > quirks) mode of ddcontrol and it seems to work kinda-okay, although > that could be me getting lucky. As I understand it, there isn't LUT access though ddcontrol, since it's not in any VESA standard. There is access to other typical controls (brightness, contrast etc.), but each monitor seems to do that differently too from what I've been told. Some of the higher end monitors use USB to access the LUTs. (One of the display profile vendors offered an VGA breakout cable that allowed the i2c to be accessed via USB, simply because the i2c access via the video drivers on MSWin were so unreliable.) > Whether it's worth doing, I'm not sure. Maybe effort is better put > into putting the color conversion into a GLSL shader rather than > poking about with VCGT-type data. Anything is possible, but without a largish budget for buying and testing monitors, or being so important that they ship them to you for free (as one guesses happens with Microsoft), it's a tough problem to offer a known working piece of code. Graeme Gill. From hughsient at gmail.com Tue Jun 1 11:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 1 Jun 2010 12:44:10 +0100 Subject: GNOME Color Manager 2.30.2 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.30.2 ~~~~~~~~~~~~~~ Released: 2010-06-01 * Translations - Added Japanese translation (Ryo Fujita) - Updated British English translation (Bruce Cowan) * Bugfix: - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not crash when the schema is invalid and GConf reports an error (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed. Fixes rh#590465 (Richard Hughes) - Get the profile permissions from GIO rather than hardcoding a hack (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 2 07:42:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 08:42:39 +0100 Subject: GNOME Color Manager accepted into desktop module for 2.32.x Message-ID: Some great news: The GNOME release team met in May to discuss potential modules to be added to GNOME, and they approved gnome-color-manager into the desktop set. This means that distros that ship GNOME 2.32 will also be shipping gnome-color-manager by default. The release team noted the excellent integration of GCM into the desktop, and did not gather a single negative problem or issue to watch. What this means for GCM: More work, more users and more bugs. * We have to do releases with the GNOME release schedule * We have to fix up any deviations from the Human Interface Guidelines * We have to keep random dependencies like exiv2 and SANE as optional build time deps. * We have to start testing on Solaris, FreeBSD and non-xorg platforms and adding portability fixes and code where required. * We have to remove deprecated module usage (GConf2 and dbus-glib are already gone in master) It's started a good day for me, as this recognizes the importance of color management in the GNOME desktop, and the programming, testing, artwork and translations from me and all you guys and girls. In the coming months I'm going to need more help translating, testing, checking, fixing and triaging bugs, so we can produce a gnome-color-manager-2.32.0 that we're proud of. Thanks. Richard. From hughsient at gmail.com Wed Jun 2 10:25:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 11:25:16 +0100 Subject: GCM and LGM 2010 Message-ID: Not being at LGM 2010 (too little travel budget, and in the middle of buying a house) I missed out on lots of important discussions. Can anybody who went fill in any details? What presentations were relevant to GCM? Was GCM discussed at all? Thanks. Richard. From hughsient at gmail.com Wed Jun 2 11:40:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 12:40:21 +0100 Subject: GNOME Color Manager 2.31.2 Message-ID: Version 2.31.2 ~~~~~~~~~~~~~~ Released: 2010-06-02 * Notes - You'll need Glib 2.25.1 and VTE 0.25.1 to compile now. - Lots of the new functionality is checked for at build time. Ensure you have development packages for cups, sane-backends, libtiff, libexif and exiv2 for full functionality. * Translations - Updated Czech translation (Milan Knizek) - Updated Danish translation (Ask H. Larsen) - Updated Estonian translation (Mattias P?ldaru) - Updated French translation (Claude Paroz) - Updated German doc translation (Mario Bl?ttermann) - Updated German translation (Christian Kirbach) - Updated German translation (Mario Bl?ttermann) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Port to GDBus (Richard Hughes) - Port to GSettings (Richard Hughes) - Port to GTest (Richard Hughes) - Add UI elements to assign multiple profiles for each device (Richard Hughes) - Add GetProfilesForFile() DBus method to get suitable ICC profiles for a given file (Richard Hughes) - Add a GConf to GSettings migration script (Richard Hughes) - Add optional exif2 support so we can get properties of RAW files (Richard Hughes) - Allow the user to just drag an image file onto the window to create a virtual profile (Richard Hughes) - Allow the user to double click a profile to make it default (Richard Hughes) * Bugfix: - Add a message in the help file explaining the drop file action (Richard Hughes) - Add gcm_profile_get_can_delete() and get the permissions from GIO rather than hardcoding a hack (Richard Hughes) - Add gcm_profile_get_checksum() so we can use this as a key to detect duplicates (Richard Hughes) - Add some information labels to the defaults pane (Richard Hughes) - Add two new settings objects 'enable-sane' and 'enable-cups' for in-field debugging (Richard Hughes) - Allow adding saved devices when coldplugging (Richard Hughes) - Allow RAW files to be dragged onto the UI with spaces in the name (Richard Hughes) - Allow virtual devices to have a serial number (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) - Ignore duplicate profiles by the MD5 checksum (Richard Hughes) - Include the serial number in the virtual device ID (Richard Hughes) - Include the trailing colon in translated strings. Fixes #619967 (Richard Hughes) - Migrate the old device-profiles.conf to the new location so the user does not have to do it manually (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed (Richard Hughes) - Do not bother the user with calibration notifications by default (Richard Hughes) - Put a short intent description in the combobox choices (Richard Hughes) - Support version 0.2 of the OpenIccDirectoryProposal (Richard Hughes) - Use the new ARGYLL_NOT_INTERACTIVE environment variable (Richard Hughes) - Use the newer VTE API (Richard Hughes) Richard. From pmjdebruijn at pcode.nl Thu Jun 3 17:18:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 3 Jun 2010 19:18:37 +0200 Subject: GCM and LGM 2010 In-Reply-To: References: Message-ID: On Wed, Jun 2, 2010 at 12:25 PM, Richard Hughes wrote: > Not being at LGM 2010 (too little travel budget, and in the middle of > buying a house) I missed out on lots of important discussions. Can > anybody who went fill in any details? What presentations were relevant > to GCM? Was GCM discussed at all? I was present for at least a day... I attended the OpenICC meeting... Kai-Uwe did a presentation on Oyranos which I sadly mostly missed :( I did talk to Kai-Uwe at the OpenICC meeting though, amongst other things we talked about how color management apps should interface with each other, and I pointed to GCM and it's DBUS API... Nobody present seemed to object to use DBUS for such a purpose... I do think they video'd most talks, so I guess you can still view most talks in a couple of days :) Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jun 10 13:39:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 10 Jun 2010 14:39:40 +0100 Subject: GNOME Color Manager: a question about some terms In-Reply-To: <20100610144011.4f613909@anche.no> References: <20100610144011.4f613909@anche.no> Message-ID: On 10 June 2010 13:40, F. Gr. wrote: > I'm translating GNOME Color Manager for Italian language. Great, thanks! > I would know > the differences among the terms "reference image", "chart type" and > "calibrated target". Have you got any links that explains the ones? Well, if it's unclear, we probably have to include things like that in the translator comments, and it also sounds like we're using different terms for the same thing. I've applied this to git master: commit d08e4ef23f7c50b754f8572ba139bdc2312abd1d Author: Richard Hughes Date: Thu Jun 10 14:38:11 2010 +0100 Use the same term 'calibration target' thoughout the UI Can you git pull from master again please, and then verify things are a bit easier to translate? I would also be interested in any other parts you found difficult. Thanks. Richard. From hughsient at gmail.com Mon Jun 14 16:09:27 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:09:27 +0100 Subject: What I've been up to... Message-ID: It's been a bit quiet from me recently. What I've been doing: * UI cleanups in the prefs widget * Porting everything to GNOME 3 * Working on full screen color management --- Wait. Full screen? Yup. I've been working on the mutter window manager to use GLSL shaders to do color correction on the GPU in hardware. Hopefully, it'll all be native in the window manager and only need a few tweaks to applications. It's early days, but it seems to work very well. I've attached a screenshot for your drooling pleasure. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 178361 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Mon Jun 14 16:36:21 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 18:36:21 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 6:09 PM, Richard Hughes wrote: > It's been a bit quiet from me recently. What I've been doing: > > * UI cleanups in the prefs widget > * Porting everything to GNOME 3 > * Working on full screen color management > > --- Wait. Full screen? > > Yup. I've been working on the mutter window manager to use GLSL > shaders to do color correction on the GPU in hardware. Hopefully, > it'll all be native in the window manager and only need a few tweaks > to applications. It's early days, but it seems to work very well. > > I've attached a screenshot for your drooling pleasure. I was already pretty happy with the current state of affairs... But this will rock severely :) Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 14 16:44:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:44:45 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 17:36, Pascal de Bruijn wrote: > I was already pretty happy with the current state of affairs... But > this will rock severely :) Well, it's early days -- but this should help the eyes of those lucky enough to have large-gamut monitors. Richard. From alexandre.prokoudine at gmail.com Mon Jun 14 17:42:26 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 21:42:26 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Richard Hughes wrote: > Well, it's early days -- but this should help the eyes of those lucky > enough to have large-gamut monitors. Exactly how? Will it make the profile be applied to displays LUT? :) Alexandre From pmjdebruijn at pcode.nl Mon Jun 14 17:50:46 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 19:50:46 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 7:42 PM, Alexandre Prokoudine wrote: > On 6/14/10, Richard Hughes wrote: > >> Well, it's early days -- but this should help the eyes of those lucky >> enough to have large-gamut monitors. > > Exactly how? Will it make the profile be applied to displays LUT? :) It's not... Since most displays don't have a programmable LUT... unless you want to spend 1500USD+ Not even talking about the fact that (as far as I know) there is no standardized way to load a LUT into the different brands of LCDs. Regards, Pascal de Bruijn From alexandre.prokoudine at gmail.com Mon Jun 14 18:20:01 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 22:20:01 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Pascal de Bruijn wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > It's not... Since most displays don't have a programmable LUT... > unless you want to spend 1500USD+ But I did spend it :) > Not even talking about the fact that (as far as I know) there is no > standardized way to load a LUT into the different brands of LCDs. >From what I remember they all used to rely on just two different chips. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jun 14 21:18:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:18:43 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 19:20, Alexandre Prokoudine wrote: >> It's not... Since most displays don't have a programmable LUT... >> unless you want to spend 1500USD+ > > But I did spend it :) Sure, it's very possible using i2c. I've used i2c quite a lot in my last job. The tricky bit is wiring it into Xorg, as i2c is pretty slow (at least in non-high speed mode) and X can't spawn extra threads. I also don't think you need to spend that much money if you want to be able to program the display LUT. I'm pretty sure I can do it on my ?200 LG screen. Richard. From hughsient at gmail.com Mon Jun 14 21:20:33 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:20:33 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 18:42, Alexandre Prokoudine wrote: > Exactly how? Will it make the profile be applied to displays LUT? :) No, but it should be useful for people with profiles without vcgt tags, and also to correct color casts. Richard. From luto at mit.edu Tue Jun 15 06:57:23 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 15 Jun 2010 02:57:23 -0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 5:20 PM, Richard Hughes wrote: > On 14 June 2010 18:42, Alexandre Prokoudine > wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > No, but it should be useful for people with profiles without vcgt > tags, and also to correct color casts. Are you planning on supporting CLUT or just matrix+shaper? And what does this do to vcgt? I'd guess that if we can't program our monitors' LUTs then we're better off not using vcgt and improving our gamut a touch. --Andy From hughsient at gmail.com Tue Jun 15 08:38:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 Jun 2010 09:38:02 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 15 June 2010 07:57, Andrew Lutomirski wrote: > Are you planning on supporting CLUT or just matrix+shaper? Both I guess. > And what does this do to vcgt? ?I'd guess that if we can't program our > monitors' LUTs then we're better off not using vcgt and improving our > gamut a touch. Yes, I'm not sure applying VCGT makes much sense if we're doing a 3d LUT. Richard. From lists+gnome-color-manager at hoech.org Tue Jun 15 15:55:11 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Tue, 15 Jun 2010 17:55:11 +0200 Subject: Installing display profiles/interfacing with gcm Message-ID: <4C17A25F.7060806@hoech.org> Hi, I'm currently looking for a way to install display profiles in a similar way as Argyll's dispwin does. So, I'm either looking for an utility 'gcm-install-display-profile' that would copy the file, do the mapping displayno->device and write the neccessary info to device-profiles.conf (does gcm-install-systemwide do this?). Or for another way to achieve what I just described (DBus?). Reason I'm asking is I'd like to offer profile installation in a GCM-compatible way in dispcalGUI if GCM is also installed, as I'm currently only supporting the Argyll dispwin (UCMM) way. Or is it safe/recommended to write to device-profiles.conf directly? Then, I'd just have to figure out how to do the Argyll displayno -> GCM device mapping (btw, what's the $(ascii) in xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). Pointers welcome :) Thanks in advance and regards -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 10:41:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 11:41:11 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C17A25F.7060806@hoech.org> References: <4C17A25F.7060806@hoech.org> Message-ID: On 15 June 2010 16:55, Florian H?ch wrote: > I'm currently looking for a way to install display profiles in a similar way > as Argyll's dispwin does. So, I'm either looking for an utility > 'gcm-install-display-profile' that would copy the > file, do the mapping displayno->device and write the neccessary info to > device-profiles.conf (does gcm-install-systemwide do this?). No, gcm-install-systemwide just installs the profiles system-wide. It's also pretty fragile the way it works, and probably needs rethinking in the near future. > Or for another way to achieve what I just described (DBus?). I think a DBus call would be okay, but it seems very specific to this use case. GCM also stores other data with the profile entry which would need to be formatted like the others by dispcalGUI. > Or is it safe/recommended to write to device-profiles.conf directly? I guess. If GCM is open at the time then it might cause problems, but I can always add an inotify watch on the config file and reload GCM's in-memory copy if it changes. I'm not sure this is a great idea, as the config file has no locking, and no ABI stability. > Then, I'd just have to figure out how to do the Argyll displayno -> GCM > device mapping (btw, what's the $(ascii) in > xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". I'm fully open to changing the format of the device-profiles.conf file if required. That could mean adding a hash=${md5_of_edid} parameter to the display section, or it could be just making the identifier be xrandr_${md5_of_edid} -- but then we have all the problems of writing the junk data required to display a meaningful device icon when the display is not attached. If the user has already run gcm-prefs and the device was saved, and you just want to change the default, then searching on hash= is probably the right thing to do. Of course, the best option is probably for GCM to expose libgcm (better names welcome) which would allow you to just call gcm_device_save() trivially in C. It would mean a compile-time optional dep on GCM, but it probably the most correct thing to do. Comments please. :-) Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 12:00:02 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 14:00:02 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> Message-ID: <4C18BCC2.20107@hoech.org> Am 16.06.2010 12:41, schrieb Richard Hughes: > On 15 June 2010 16:55, Florian H?ch wrote: >> I'm currently looking for a way to install display profiles in a similar way >> as Argyll's dispwin does. So, I'm either looking for an utility >> 'gcm-install-display-profile' that would copy the >> file, do the mapping displayno->device and write the neccessary info to >> device-profiles.conf (does gcm-install-systemwide do this?). > > No, gcm-install-systemwide just installs the profiles system-wide. > It's also pretty fragile the way it works, and probably needs > rethinking in the near future. Ok. >> Or for another way to achieve what I just described (DBus?). > > I think a DBus call would be okay, but it seems very specific to this > use case. GCM also stores other data with the profile entry which > would need to be formatted like the others by dispcalGUI. > >> Or is it safe/recommended to write to device-profiles.conf directly? > > I guess. If GCM is open at the time then it might cause problems, but > I can always add an inotify watch on the config file and reload GCM's > in-memory copy if it changes. I'm not sure this is a great idea, as > the config file has no locking, and no ABI stability. Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last resort". >> Then, I'd just have to figure out how to do the Argyll displayno -> GCM >> device mapping (btw, what's the $(ascii) in >> xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). > > It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". Ah, ok. So then all the naming information is available through the EDID? That's fine with me. > I'm > fully open to changing the format of the device-profiles.conf file if > required. That could mean adding a hash=${md5_of_edid} parameter to > the display section, or it could be just making the identifier be > xrandr_${md5_of_edid} -- but then we have all the problems of writing > the junk data required to display a meaningful device icon when the > display is not attached. If the user has already run gcm-prefs and the > device was saved, and you just want to change the default, then > searching on hash= is probably the right thing to do. Agreed on your points. I think the format of the config file is fine, although addition of the EDID hash key sounds like a nice idea. > Of course, the best option is probably for GCM to expose libgcm > (better names welcome) which would allow you to just call > gcm_device_save() trivially in C. It would mean a compile-time > optional dep on GCM, but it probably the most correct thing to do. That would be nice, then I could let GCM do "the right thing" for me. Dep on GCM is not a problem I think, as I'm probably going to use Python's ctypes then, which can tell me if the library is installed and I can also use it to wrap the C function call. Thanks for the infos so far! > Comments please. :-) > > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 14:13:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 15:13:55 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18BCC2.20107@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: On 16 June 2010 13:00, Florian H?ch wrote: > Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last > resort". Right. The lack of locking makes this a quick fix, but probably not a good idea. > Ah, ok. So then all the naming information is available through the EDID? Right. > Agreed on your points. I think the format of the config file is fine, > although addition of the EDID hash key sounds like a nice idea. commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 Author: Richard Hughes Date: Wed Jun 16 15:04:38 2010 +0100 Save the EDID MD5 hash to device-profiles.conf for xrandr devices > That would be nice, then I could let GCM do "the right thing" for me. Dep on > GCM is not a problem I think, as I'm probably going to use Python's ctypes > then, which can tell me if the library is installed and I can also use it to > wrap the C function call. Right, this is probably the best thing to do. I'll look at librification now, although it's quite a big change, and it might make sense for the gnome3 stuff to settle down first. Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 15:58:35 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 17:58:35 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: <4C18F4AB.50809@hoech.org> Am 16.06.2010 16:13, schrieb Richard Hughes: >> On 16 June 2010 13:00, Florian H?ch wrote: >>> Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last >>> resort". >> >> Right. The lack of locking makes this a quick fix, but probably not a good idea. >> >>> Ah, ok. So then all the naming information is available through the EDID? >> >> Right. >> >>> Agreed on your points. I think the format of the config file is fine, >>> although addition of the EDID hash key sounds like a nice idea. >> >> commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 >> Author: Richard Hughes >> Date: Wed Jun 16 15:04:38 2010 +0100 >> >> Save the EDID MD5 hash to device-profiles.conf for xrandr devices Cool, thanks! >>> That would be nice, then I could let GCM do "the right thing" for me. Dep on >>> GCM is not a problem I think, as I'm probably going to use Python's ctypes >>> then, which can tell me if the library is installed and I can also useit to >>> wrap the C function call. >> >> Right, this is probably the best thing to do. I'll look at >> librification now, although it's quite a big change, and it might make >> sense for the gnome3 stuff to settle down first. >> >> Richard. No need to hurry, I'm glad you're looking into it! :) -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jun 17 14:58:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 Jun 2010 15:58:20 +0100 Subject: Next release tomorrow Message-ID: I'm having to do a new development release of GCM tomorrow. GLib and GTK both changed API this point release, and we're trying to co-ordinate so there isn't breakage for the devel distros. If you've got pending translations, please merge them before tomorrow morning. Thanks. Richard. From lists at hoech.net Fri Jun 18 18:24:16 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 18 Jun 2010 20:24:16 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18F4AB.50809@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> <4C18F4AB.50809@hoech.org> Message-ID: <4C1BB9D0.4070803@hoech.net> I've now added rudimentary support for GCM in the upcoming next release of dispcalGUI (changes are not yet in SVN though). If GCM is installed and XRandR is working, I'm parsing EDID and also device-profiles.conf (only reading) to add necessary/useful info like manufacturer and model to the profile thats going to be installed, before gcm-import is called to bring the profile inside GCM. This way seems to work pretty well and can still be replaced later. -- Florian H?ch http://hoech.net From hughsient at gmail.com Mon Jun 21 08:03:44 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 09:03:44 +0100 Subject: Switching to lcms2? Message-ID: Does anybody have an problems if gnome-color-manager switches to lcms2 later this week? Richard. From pmjdebruijn at pcode.nl Mon Jun 21 08:44:08 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 10:44:08 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: > Does anybody have an problems if gnome-color-manager switches to lcms2 > later this week? Since the GSettings stuff already breaks compatibility with older distro's, I don't see why lcms2 would cause any additional problems... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 10:44:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 11:44:20 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 09:44, Pascal de Bruijn wrote: > On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >> Does anybody have an problems if gnome-color-manager switches to lcms2 >> later this week? > > Since the GSettings stuff already breaks compatibility with older > distro's, I don't see why lcms2 would cause any additional problems... This was my thought too. Richard. From pmjdebruijn at pcode.nl Mon Jun 21 10:52:34 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 12:52:34 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 12:44 PM, Richard Hughes wrote: > On 21 June 2010 09:44, Pascal de Bruijn wrote: >> On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >>> Does anybody have an problems if gnome-color-manager switches to lcms2 >>> later this week? >> >> Since the GSettings stuff already breaks compatibility with older >> distro's, I don't see why lcms2 would cause any additional problems... > > This was my thought too. I did notice LCMS2 hasn't hit the Debian package repo's yet... But it's still early after it's release... So I guess that'll get fixed before (for example) the next Ubuntu is released... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 16:06:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 17:06:35 +0100 Subject: GNOME Color Manager 2.31.3 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.3 ~~~~~~~~~~~~~~ Released: 2010-06-21 * Translations - Added Galician translations (Fran Di?guez) - Added Hebrew translation (Yaron Shahrabani) - Added Norwegian bokm?l translation (Kjartan Maraas) - Updated Indonesian translation (Andika Triwidada) - Updated Italian translation (Francesco Groccia) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Punjabi Translation (A S Alam) - Updated Spanish translation (Jorge Gonz?lez) - Updated Galician translations (Fran Di?guez) - Updated Hebrew translation (Yaron Shahrabani) * New Features: - Require GTK3 as per the GNOME release team announcement (Richard Hughes) - Port to GtkApplication (Richard Hughes) - Port to GDBus (Richard Hughes) - Use the GSetting enum functionality (Richard Hughes) - Make libnotify optional dependency as it relies on gtk-2.0 (Richard Hughes) - Make VTE optional as it relies on gtk-2.0 (Richard Hughes) - Require libcanberra-gtk3 (Richard Hughes) - Require gnome-desktop3 (Richard Hughes) * Bugfix: - Disconnect the VTE callbacks when ending the calibration to prevent a nasty crash (Richard Hughes) - Only emit ::added signals from the main thread, not the coldplug threads (Richard Hughes) - Redo the graph UI in the profiles page to be more HIG friendly (Richard Hughes) - Save the EDID MD5 hash to device-profiles.conf for xrandr devices (Richard Hughes) - Set the calibrate button insensitive if VTE is unavailable (Richard Hughes) - Use the same term 'calibration target' thoughout the UI (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 23 13:06:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:06:32 +0100 Subject: Gray profiles Message-ID: Does anybody actually use gray ICC profiles? Would it make sense to add a UI element for this type of profile? Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:20:47 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:20:47 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: > Does anybody actually use gray ICC profiles? Yes, Photoshop's grey profiles are a must to properly use greyscale images in Scribus. Sad but true. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Wed Jun 23 13:26:30 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:26:30 +0100 Subject: Gray profiles In-Reply-To: References: Message-ID: On 23 June 2010 14:20, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: >> Does anybody actually use gray ICC profiles? > > Yes, Photoshop's grey profiles are a must to properly use greyscale > images in Scribus. Sad but true. Do we have any open source or BSD gray icc profiles in any existing projects? Thanks, Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:29:56 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:29:56 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: >> Yes, Photoshop's grey profiles are a must to properly use greyscale >> images in Scribus. Sad but true. > > Do we have any open source or BSD gray icc profiles in any existing projects? Not that I know of. I was intending to look into it, but never found enough time and I'm currently lacking expertize in profiles creation anyway. Alexandre Prokoudine http://libregraphicsworld.org From pmjdebruijn at pcode.nl Wed Jun 23 16:00:36 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 23 Jun 2010 18:00:36 +0200 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 3:29 PM, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: > >>> Yes, Photoshop's grey profiles are a must to properly use greyscale >>> images in Scribus. Sad but true. >> >> Do we have any open source or BSD gray icc profiles in any existing projects? > > Not that I know of. I was intending to look into it, but never found > enough time and I'm currently lacking expertize in profiles creation > anyway. Maybe it's just me... But it doesn't sound like this would be to hard to do... I mean... You can't get the color wrong :) Regards, Pascal de Bruijn From graeme2 at argyllcms.com Thu Jun 24 03:44:13 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 24 Jun 2010 13:44:13 +1000 Subject: Gray profiles In-Reply-To: References: Message-ID: <4C22D48D.5020901@argyllcms.com> Pascal de Bruijn wrote: > I mean... You can't get the color wrong :) Yes you can. For a cLUT profile the A2B needs to map the colorant value to PCS, and your PCS value could have the wrong color ... Graeme Gill. From hughsient at gmail.com Thu Jun 24 11:08:22 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 12:08:22 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 11:52, Pascal de Bruijn wrote: > I did notice LCMS2 hasn't hit the Debian package repo's yet... But > it's still early after it's release... So I guess that'll get fixed > before (for example) the next Ubuntu is released... Okay, gnome-color-manager in git master now requires lcms2. This also means we can start to write ICC profiles with vcgt tags ourselves, to do things like manual calibration without calibration equipment. Richard. From hughsient at gmail.com Thu Jun 24 12:47:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 13:47:56 +0100 Subject: Photography contest! Message-ID: I need a sample image that will be used in the GNOME Color Manager profile viewer. The image will be changed according to the input and output color spaces, so the user can see what affect the profile has on a typical (example) image. This is an ideal task if you want to help the project, but can't code. So, the image has to be: * GPLv2+ or public domain * 200 pixels high by 400 pixels wide * Brightly colored, with lots of different types of color and shade * Nothing controversial, i.e. no photos of naked ladies or of a BP oil spill... * Interesting, not just a sunset or picture of water * Be saved as sRGB png format (although it's okay if that makes it look a bit odd...) The image has to show clearly what difference sRGB, Adobe and ProPhoto have when importing and exporting, so having some out of sRGB gamut colors would be ideal. Let the contest begin. :-) Richard. From hughsient at gmail.com Tue Jun 29 12:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:05:36 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? Message-ID: I'm pondering adding i2c-encoding functionality to GCM to allow us to reprogram the external panel gamma ramps, rather than using X. Using X has the disadvantage of lowering the number of colors we can display, as we artificially have to limit the gamut range when setting the VCGT tag. Changing this on the monitor itself gives us the advantage of not lowing the gamut range, as it's hopefully operating later in the analog chain. Ideas and feedback welcome. If anyone has ever tried this before, I would appreciate any advice. Thanks. Richard. From graeme2 at argyllcms.com Tue Jun 29 12:32:48 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Tue, 29 Jun 2010 22:32:48 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: Message-ID: <4C29E7F0.2020101@argyllcms.com> Richard Hughes wrote: > Ideas and feedback welcome. If anyone has ever tried this before, I > would appreciate any advice. Thanks. Naturally I've considered this. The problems are: There is no standard X mechanisms for doing this. X accesses the monitors i2c to load the EDID, but doesn't provide a general purpose communication channel. The logical place for it is in XRandR, since it knows about outputs (monitors). Although the i2c might be accessed elsewhere in Linux, there is the problem of figuring out the association between the i2c and the outputs. The above wouldn't have stopped me doing this for MSWin and OS X, but there is the second problem: there is no standard i2c video monitor protocol for this. Each manufacturer can do it their own way, and doesn't publish how they do it. You have to reverse engineer it for each monitor. Without access to a representative set of monitors, the coverage of monitors is likely to be spotty. (I don't have a single monitor with this feature.) Graeme Gill. From hughsient at gmail.com Tue Jun 29 12:59:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:59:48 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: <4C29E7F0.2020101@argyllcms.com> References: <4C29E7F0.2020101@argyllcms.com> Message-ID: On 29 June 2010 13:32, Graeme Gill wrote: > Naturally I've considered this. I had hoped so :-) > ? ? ? ?There is no standard X mechanisms for doing this. X accesses > the monitors i2c to load the EDID, but doesn't provide a general purpose > communication channel. The logical place for it is in XRandR, since it > knows about outputs (monitors). Although the i2c might be accessed elsewhere > in Linux, there is the problem of figuring out the association between > the i2c and the outputs. Right, I've looked at doing this in X (or the kernel, via KMS) and it basically comes down to ic2 being so slow. X can't run threaded, and using i2c means we have to block for huge amounts of time. Doing it in the kernel makes threads possible, although it makes things much harder in other ways. > The above wouldn't have stopped me doing this for MSWin and OS X, > but there is the second problem: there is no standard i2c video monitor > protocol for this. Each manufacturer can do it their own way, and > doesn't publish how they do it. You have to reverse engineer it > for each monitor. Without access to a representative set of > monitors, the coverage of monitors is likely to be spotty. Right, agreed. I've been looking at the database table in ddcontrol and it only supports a few monitors out of the thousands of different kinds ever made. With no agreed standard, I agree this is a classic chicken and egg thing. I've been trying to use the standard (no quirks) mode of ddcontrol and it seems to work kinda-okay, although that could be me getting lucky. > (I don't have a single monitor with this feature.) I've got an LG monitor with this functionality, although I'm only basing all my assumptions of "it'll work fine" on a sample size of 1. Whether it's worth doing, I'm not sure. Maybe effort is better put into putting the color conversion into a GLSL shader rather than poking about with VCGT-type data. Richard. From graeme2 at argyllcms.com Tue Jun 29 14:45:39 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Wed, 30 Jun 2010 00:45:39 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: <4C29E7F0.2020101@argyllcms.com> Message-ID: <4C2A0713.4040206@argyllcms.com> Richard Hughes wrote: > Right, I've looked at doing this in X (or the kernel, via KMS) and it > basically comes down to ic2 being so slow. X can't run threaded, and > using i2c means we have to block for huge amounts of time. Doing it in > the kernel makes threads possible, although it makes things much > harder in other ways. Hmm. A way around this would be to expose the i2c bus at a very low level through X, and rely on the caller to do the timing. (I think that the OS X stuff almost works at this level). > Right, agreed. I've been looking at the database table in ddcontrol > and it only supports a few monitors out of the thousands of different > kinds ever made. With no agreed standard, I agree this is a classic > chicken and egg thing. I've been trying to use the standard (no > quirks) mode of ddcontrol and it seems to work kinda-okay, although > that could be me getting lucky. As I understand it, there isn't LUT access though ddcontrol, since it's not in any VESA standard. There is access to other typical controls (brightness, contrast etc.), but each monitor seems to do that differently too from what I've been told. Some of the higher end monitors use USB to access the LUTs. (One of the display profile vendors offered an VGA breakout cable that allowed the i2c to be accessed via USB, simply because the i2c access via the video drivers on MSWin were so unreliable.) > Whether it's worth doing, I'm not sure. Maybe effort is better put > into putting the color conversion into a GLSL shader rather than > poking about with VCGT-type data. Anything is possible, but without a largish budget for buying and testing monitors, or being so important that they ship them to you for free (as one guesses happens with Microsoft), it's a tough problem to offer a known working piece of code. Graeme Gill. From hughsient at gmail.com Tue Jun 1 11:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 1 Jun 2010 12:44:10 +0100 Subject: GNOME Color Manager 2.30.2 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.30.2 ~~~~~~~~~~~~~~ Released: 2010-06-01 * Translations - Added Japanese translation (Ryo Fujita) - Updated British English translation (Bruce Cowan) * Bugfix: - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not crash when the schema is invalid and GConf reports an error (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed. Fixes rh#590465 (Richard Hughes) - Get the profile permissions from GIO rather than hardcoding a hack (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 2 07:42:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 08:42:39 +0100 Subject: GNOME Color Manager accepted into desktop module for 2.32.x Message-ID: Some great news: The GNOME release team met in May to discuss potential modules to be added to GNOME, and they approved gnome-color-manager into the desktop set. This means that distros that ship GNOME 2.32 will also be shipping gnome-color-manager by default. The release team noted the excellent integration of GCM into the desktop, and did not gather a single negative problem or issue to watch. What this means for GCM: More work, more users and more bugs. * We have to do releases with the GNOME release schedule * We have to fix up any deviations from the Human Interface Guidelines * We have to keep random dependencies like exiv2 and SANE as optional build time deps. * We have to start testing on Solaris, FreeBSD and non-xorg platforms and adding portability fixes and code where required. * We have to remove deprecated module usage (GConf2 and dbus-glib are already gone in master) It's started a good day for me, as this recognizes the importance of color management in the GNOME desktop, and the programming, testing, artwork and translations from me and all you guys and girls. In the coming months I'm going to need more help translating, testing, checking, fixing and triaging bugs, so we can produce a gnome-color-manager-2.32.0 that we're proud of. Thanks. Richard. From hughsient at gmail.com Wed Jun 2 10:25:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 11:25:16 +0100 Subject: GCM and LGM 2010 Message-ID: Not being at LGM 2010 (too little travel budget, and in the middle of buying a house) I missed out on lots of important discussions. Can anybody who went fill in any details? What presentations were relevant to GCM? Was GCM discussed at all? Thanks. Richard. From hughsient at gmail.com Wed Jun 2 11:40:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 12:40:21 +0100 Subject: GNOME Color Manager 2.31.2 Message-ID: Version 2.31.2 ~~~~~~~~~~~~~~ Released: 2010-06-02 * Notes - You'll need Glib 2.25.1 and VTE 0.25.1 to compile now. - Lots of the new functionality is checked for at build time. Ensure you have development packages for cups, sane-backends, libtiff, libexif and exiv2 for full functionality. * Translations - Updated Czech translation (Milan Knizek) - Updated Danish translation (Ask H. Larsen) - Updated Estonian translation (Mattias P?ldaru) - Updated French translation (Claude Paroz) - Updated German doc translation (Mario Bl?ttermann) - Updated German translation (Christian Kirbach) - Updated German translation (Mario Bl?ttermann) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Port to GDBus (Richard Hughes) - Port to GSettings (Richard Hughes) - Port to GTest (Richard Hughes) - Add UI elements to assign multiple profiles for each device (Richard Hughes) - Add GetProfilesForFile() DBus method to get suitable ICC profiles for a given file (Richard Hughes) - Add a GConf to GSettings migration script (Richard Hughes) - Add optional exif2 support so we can get properties of RAW files (Richard Hughes) - Allow the user to just drag an image file onto the window to create a virtual profile (Richard Hughes) - Allow the user to double click a profile to make it default (Richard Hughes) * Bugfix: - Add a message in the help file explaining the drop file action (Richard Hughes) - Add gcm_profile_get_can_delete() and get the permissions from GIO rather than hardcoding a hack (Richard Hughes) - Add gcm_profile_get_checksum() so we can use this as a key to detect duplicates (Richard Hughes) - Add some information labels to the defaults pane (Richard Hughes) - Add two new settings objects 'enable-sane' and 'enable-cups' for in-field debugging (Richard Hughes) - Allow adding saved devices when coldplugging (Richard Hughes) - Allow RAW files to be dragged onto the UI with spaces in the name (Richard Hughes) - Allow virtual devices to have a serial number (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) - Ignore duplicate profiles by the MD5 checksum (Richard Hughes) - Include the serial number in the virtual device ID (Richard Hughes) - Include the trailing colon in translated strings. Fixes #619967 (Richard Hughes) - Migrate the old device-profiles.conf to the new location so the user does not have to do it manually (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed (Richard Hughes) - Do not bother the user with calibration notifications by default (Richard Hughes) - Put a short intent description in the combobox choices (Richard Hughes) - Support version 0.2 of the OpenIccDirectoryProposal (Richard Hughes) - Use the new ARGYLL_NOT_INTERACTIVE environment variable (Richard Hughes) - Use the newer VTE API (Richard Hughes) Richard. From pmjdebruijn at pcode.nl Thu Jun 3 17:18:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 3 Jun 2010 19:18:37 +0200 Subject: GCM and LGM 2010 In-Reply-To: References: Message-ID: On Wed, Jun 2, 2010 at 12:25 PM, Richard Hughes wrote: > Not being at LGM 2010 (too little travel budget, and in the middle of > buying a house) I missed out on lots of important discussions. Can > anybody who went fill in any details? What presentations were relevant > to GCM? Was GCM discussed at all? I was present for at least a day... I attended the OpenICC meeting... Kai-Uwe did a presentation on Oyranos which I sadly mostly missed :( I did talk to Kai-Uwe at the OpenICC meeting though, amongst other things we talked about how color management apps should interface with each other, and I pointed to GCM and it's DBUS API... Nobody present seemed to object to use DBUS for such a purpose... I do think they video'd most talks, so I guess you can still view most talks in a couple of days :) Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jun 10 13:39:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 10 Jun 2010 14:39:40 +0100 Subject: GNOME Color Manager: a question about some terms In-Reply-To: <20100610144011.4f613909@anche.no> References: <20100610144011.4f613909@anche.no> Message-ID: On 10 June 2010 13:40, F. Gr. wrote: > I'm translating GNOME Color Manager for Italian language. Great, thanks! > I would know > the differences among the terms "reference image", "chart type" and > "calibrated target". Have you got any links that explains the ones? Well, if it's unclear, we probably have to include things like that in the translator comments, and it also sounds like we're using different terms for the same thing. I've applied this to git master: commit d08e4ef23f7c50b754f8572ba139bdc2312abd1d Author: Richard Hughes Date: Thu Jun 10 14:38:11 2010 +0100 Use the same term 'calibration target' thoughout the UI Can you git pull from master again please, and then verify things are a bit easier to translate? I would also be interested in any other parts you found difficult. Thanks. Richard. From hughsient at gmail.com Mon Jun 14 16:09:27 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:09:27 +0100 Subject: What I've been up to... Message-ID: It's been a bit quiet from me recently. What I've been doing: * UI cleanups in the prefs widget * Porting everything to GNOME 3 * Working on full screen color management --- Wait. Full screen? Yup. I've been working on the mutter window manager to use GLSL shaders to do color correction on the GPU in hardware. Hopefully, it'll all be native in the window manager and only need a few tweaks to applications. It's early days, but it seems to work very well. I've attached a screenshot for your drooling pleasure. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 178361 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Mon Jun 14 16:36:21 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 18:36:21 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 6:09 PM, Richard Hughes wrote: > It's been a bit quiet from me recently. What I've been doing: > > * UI cleanups in the prefs widget > * Porting everything to GNOME 3 > * Working on full screen color management > > --- Wait. Full screen? > > Yup. I've been working on the mutter window manager to use GLSL > shaders to do color correction on the GPU in hardware. Hopefully, > it'll all be native in the window manager and only need a few tweaks > to applications. It's early days, but it seems to work very well. > > I've attached a screenshot for your drooling pleasure. I was already pretty happy with the current state of affairs... But this will rock severely :) Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 14 16:44:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:44:45 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 17:36, Pascal de Bruijn wrote: > I was already pretty happy with the current state of affairs... But > this will rock severely :) Well, it's early days -- but this should help the eyes of those lucky enough to have large-gamut monitors. Richard. From alexandre.prokoudine at gmail.com Mon Jun 14 17:42:26 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 21:42:26 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Richard Hughes wrote: > Well, it's early days -- but this should help the eyes of those lucky > enough to have large-gamut monitors. Exactly how? Will it make the profile be applied to displays LUT? :) Alexandre From pmjdebruijn at pcode.nl Mon Jun 14 17:50:46 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 19:50:46 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 7:42 PM, Alexandre Prokoudine wrote: > On 6/14/10, Richard Hughes wrote: > >> Well, it's early days -- but this should help the eyes of those lucky >> enough to have large-gamut monitors. > > Exactly how? Will it make the profile be applied to displays LUT? :) It's not... Since most displays don't have a programmable LUT... unless you want to spend 1500USD+ Not even talking about the fact that (as far as I know) there is no standardized way to load a LUT into the different brands of LCDs. Regards, Pascal de Bruijn From alexandre.prokoudine at gmail.com Mon Jun 14 18:20:01 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 22:20:01 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Pascal de Bruijn wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > It's not... Since most displays don't have a programmable LUT... > unless you want to spend 1500USD+ But I did spend it :) > Not even talking about the fact that (as far as I know) there is no > standardized way to load a LUT into the different brands of LCDs. >From what I remember they all used to rely on just two different chips. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jun 14 21:18:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:18:43 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 19:20, Alexandre Prokoudine wrote: >> It's not... Since most displays don't have a programmable LUT... >> unless you want to spend 1500USD+ > > But I did spend it :) Sure, it's very possible using i2c. I've used i2c quite a lot in my last job. The tricky bit is wiring it into Xorg, as i2c is pretty slow (at least in non-high speed mode) and X can't spawn extra threads. I also don't think you need to spend that much money if you want to be able to program the display LUT. I'm pretty sure I can do it on my ?200 LG screen. Richard. From hughsient at gmail.com Mon Jun 14 21:20:33 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:20:33 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 18:42, Alexandre Prokoudine wrote: > Exactly how? Will it make the profile be applied to displays LUT? :) No, but it should be useful for people with profiles without vcgt tags, and also to correct color casts. Richard. From luto at mit.edu Tue Jun 15 06:57:23 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 15 Jun 2010 02:57:23 -0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 5:20 PM, Richard Hughes wrote: > On 14 June 2010 18:42, Alexandre Prokoudine > wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > No, but it should be useful for people with profiles without vcgt > tags, and also to correct color casts. Are you planning on supporting CLUT or just matrix+shaper? And what does this do to vcgt? I'd guess that if we can't program our monitors' LUTs then we're better off not using vcgt and improving our gamut a touch. --Andy From hughsient at gmail.com Tue Jun 15 08:38:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 Jun 2010 09:38:02 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 15 June 2010 07:57, Andrew Lutomirski wrote: > Are you planning on supporting CLUT or just matrix+shaper? Both I guess. > And what does this do to vcgt? ?I'd guess that if we can't program our > monitors' LUTs then we're better off not using vcgt and improving our > gamut a touch. Yes, I'm not sure applying VCGT makes much sense if we're doing a 3d LUT. Richard. From lists+gnome-color-manager at hoech.org Tue Jun 15 15:55:11 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Tue, 15 Jun 2010 17:55:11 +0200 Subject: Installing display profiles/interfacing with gcm Message-ID: <4C17A25F.7060806@hoech.org> Hi, I'm currently looking for a way to install display profiles in a similar way as Argyll's dispwin does. So, I'm either looking for an utility 'gcm-install-display-profile' that would copy the file, do the mapping displayno->device and write the neccessary info to device-profiles.conf (does gcm-install-systemwide do this?). Or for another way to achieve what I just described (DBus?). Reason I'm asking is I'd like to offer profile installation in a GCM-compatible way in dispcalGUI if GCM is also installed, as I'm currently only supporting the Argyll dispwin (UCMM) way. Or is it safe/recommended to write to device-profiles.conf directly? Then, I'd just have to figure out how to do the Argyll displayno -> GCM device mapping (btw, what's the $(ascii) in xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). Pointers welcome :) Thanks in advance and regards -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 10:41:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 11:41:11 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C17A25F.7060806@hoech.org> References: <4C17A25F.7060806@hoech.org> Message-ID: On 15 June 2010 16:55, Florian H?ch wrote: > I'm currently looking for a way to install display profiles in a similar way > as Argyll's dispwin does. So, I'm either looking for an utility > 'gcm-install-display-profile' that would copy the > file, do the mapping displayno->device and write the neccessary info to > device-profiles.conf (does gcm-install-systemwide do this?). No, gcm-install-systemwide just installs the profiles system-wide. It's also pretty fragile the way it works, and probably needs rethinking in the near future. > Or for another way to achieve what I just described (DBus?). I think a DBus call would be okay, but it seems very specific to this use case. GCM also stores other data with the profile entry which would need to be formatted like the others by dispcalGUI. > Or is it safe/recommended to write to device-profiles.conf directly? I guess. If GCM is open at the time then it might cause problems, but I can always add an inotify watch on the config file and reload GCM's in-memory copy if it changes. I'm not sure this is a great idea, as the config file has no locking, and no ABI stability. > Then, I'd just have to figure out how to do the Argyll displayno -> GCM > device mapping (btw, what's the $(ascii) in > xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". I'm fully open to changing the format of the device-profiles.conf file if required. That could mean adding a hash=${md5_of_edid} parameter to the display section, or it could be just making the identifier be xrandr_${md5_of_edid} -- but then we have all the problems of writing the junk data required to display a meaningful device icon when the display is not attached. If the user has already run gcm-prefs and the device was saved, and you just want to change the default, then searching on hash= is probably the right thing to do. Of course, the best option is probably for GCM to expose libgcm (better names welcome) which would allow you to just call gcm_device_save() trivially in C. It would mean a compile-time optional dep on GCM, but it probably the most correct thing to do. Comments please. :-) Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 12:00:02 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 14:00:02 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> Message-ID: <4C18BCC2.20107@hoech.org> Am 16.06.2010 12:41, schrieb Richard Hughes: > On 15 June 2010 16:55, Florian H?ch wrote: >> I'm currently looking for a way to install display profiles in a similar way >> as Argyll's dispwin does. So, I'm either looking for an utility >> 'gcm-install-display-profile' that would copy the >> file, do the mapping displayno->device and write the neccessary info to >> device-profiles.conf (does gcm-install-systemwide do this?). > > No, gcm-install-systemwide just installs the profiles system-wide. > It's also pretty fragile the way it works, and probably needs > rethinking in the near future. Ok. >> Or for another way to achieve what I just described (DBus?). > > I think a DBus call would be okay, but it seems very specific to this > use case. GCM also stores other data with the profile entry which > would need to be formatted like the others by dispcalGUI. > >> Or is it safe/recommended to write to device-profiles.conf directly? > > I guess. If GCM is open at the time then it might cause problems, but > I can always add an inotify watch on the config file and reload GCM's > in-memory copy if it changes. I'm not sure this is a great idea, as > the config file has no locking, and no ABI stability. Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last resort". >> Then, I'd just have to figure out how to do the Argyll displayno -> GCM >> device mapping (btw, what's the $(ascii) in >> xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). > > It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". Ah, ok. So then all the naming information is available through the EDID? That's fine with me. > I'm > fully open to changing the format of the device-profiles.conf file if > required. That could mean adding a hash=${md5_of_edid} parameter to > the display section, or it could be just making the identifier be > xrandr_${md5_of_edid} -- but then we have all the problems of writing > the junk data required to display a meaningful device icon when the > display is not attached. If the user has already run gcm-prefs and the > device was saved, and you just want to change the default, then > searching on hash= is probably the right thing to do. Agreed on your points. I think the format of the config file is fine, although addition of the EDID hash key sounds like a nice idea. > Of course, the best option is probably for GCM to expose libgcm > (better names welcome) which would allow you to just call > gcm_device_save() trivially in C. It would mean a compile-time > optional dep on GCM, but it probably the most correct thing to do. That would be nice, then I could let GCM do "the right thing" for me. Dep on GCM is not a problem I think, as I'm probably going to use Python's ctypes then, which can tell me if the library is installed and I can also use it to wrap the C function call. Thanks for the infos so far! > Comments please. :-) > > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 14:13:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 15:13:55 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18BCC2.20107@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: On 16 June 2010 13:00, Florian H?ch wrote: > Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last > resort". Right. The lack of locking makes this a quick fix, but probably not a good idea. > Ah, ok. So then all the naming information is available through the EDID? Right. > Agreed on your points. I think the format of the config file is fine, > although addition of the EDID hash key sounds like a nice idea. commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 Author: Richard Hughes Date: Wed Jun 16 15:04:38 2010 +0100 Save the EDID MD5 hash to device-profiles.conf for xrandr devices > That would be nice, then I could let GCM do "the right thing" for me. Dep on > GCM is not a problem I think, as I'm probably going to use Python's ctypes > then, which can tell me if the library is installed and I can also use it to > wrap the C function call. Right, this is probably the best thing to do. I'll look at librification now, although it's quite a big change, and it might make sense for the gnome3 stuff to settle down first. Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 15:58:35 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 17:58:35 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: <4C18F4AB.50809@hoech.org> Am 16.06.2010 16:13, schrieb Richard Hughes: >> On 16 June 2010 13:00, Florian H?ch wrote: >>> Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last >>> resort". >> >> Right. The lack of locking makes this a quick fix, but probably not a good idea. >> >>> Ah, ok. So then all the naming information is available through the EDID? >> >> Right. >> >>> Agreed on your points. I think the format of the config file is fine, >>> although addition of the EDID hash key sounds like a nice idea. >> >> commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 >> Author: Richard Hughes >> Date: Wed Jun 16 15:04:38 2010 +0100 >> >> Save the EDID MD5 hash to device-profiles.conf for xrandr devices Cool, thanks! >>> That would be nice, then I could let GCM do "the right thing" for me. Dep on >>> GCM is not a problem I think, as I'm probably going to use Python's ctypes >>> then, which can tell me if the library is installed and I can also useit to >>> wrap the C function call. >> >> Right, this is probably the best thing to do. I'll look at >> librification now, although it's quite a big change, and it might make >> sense for the gnome3 stuff to settle down first. >> >> Richard. No need to hurry, I'm glad you're looking into it! :) -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jun 17 14:58:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 Jun 2010 15:58:20 +0100 Subject: Next release tomorrow Message-ID: I'm having to do a new development release of GCM tomorrow. GLib and GTK both changed API this point release, and we're trying to co-ordinate so there isn't breakage for the devel distros. If you've got pending translations, please merge them before tomorrow morning. Thanks. Richard. From lists at hoech.net Fri Jun 18 18:24:16 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 18 Jun 2010 20:24:16 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18F4AB.50809@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> <4C18F4AB.50809@hoech.org> Message-ID: <4C1BB9D0.4070803@hoech.net> I've now added rudimentary support for GCM in the upcoming next release of dispcalGUI (changes are not yet in SVN though). If GCM is installed and XRandR is working, I'm parsing EDID and also device-profiles.conf (only reading) to add necessary/useful info like manufacturer and model to the profile thats going to be installed, before gcm-import is called to bring the profile inside GCM. This way seems to work pretty well and can still be replaced later. -- Florian H?ch http://hoech.net From hughsient at gmail.com Mon Jun 21 08:03:44 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 09:03:44 +0100 Subject: Switching to lcms2? Message-ID: Does anybody have an problems if gnome-color-manager switches to lcms2 later this week? Richard. From pmjdebruijn at pcode.nl Mon Jun 21 08:44:08 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 10:44:08 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: > Does anybody have an problems if gnome-color-manager switches to lcms2 > later this week? Since the GSettings stuff already breaks compatibility with older distro's, I don't see why lcms2 would cause any additional problems... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 10:44:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 11:44:20 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 09:44, Pascal de Bruijn wrote: > On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >> Does anybody have an problems if gnome-color-manager switches to lcms2 >> later this week? > > Since the GSettings stuff already breaks compatibility with older > distro's, I don't see why lcms2 would cause any additional problems... This was my thought too. Richard. From pmjdebruijn at pcode.nl Mon Jun 21 10:52:34 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 12:52:34 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 12:44 PM, Richard Hughes wrote: > On 21 June 2010 09:44, Pascal de Bruijn wrote: >> On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >>> Does anybody have an problems if gnome-color-manager switches to lcms2 >>> later this week? >> >> Since the GSettings stuff already breaks compatibility with older >> distro's, I don't see why lcms2 would cause any additional problems... > > This was my thought too. I did notice LCMS2 hasn't hit the Debian package repo's yet... But it's still early after it's release... So I guess that'll get fixed before (for example) the next Ubuntu is released... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 16:06:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 17:06:35 +0100 Subject: GNOME Color Manager 2.31.3 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.3 ~~~~~~~~~~~~~~ Released: 2010-06-21 * Translations - Added Galician translations (Fran Di?guez) - Added Hebrew translation (Yaron Shahrabani) - Added Norwegian bokm?l translation (Kjartan Maraas) - Updated Indonesian translation (Andika Triwidada) - Updated Italian translation (Francesco Groccia) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Punjabi Translation (A S Alam) - Updated Spanish translation (Jorge Gonz?lez) - Updated Galician translations (Fran Di?guez) - Updated Hebrew translation (Yaron Shahrabani) * New Features: - Require GTK3 as per the GNOME release team announcement (Richard Hughes) - Port to GtkApplication (Richard Hughes) - Port to GDBus (Richard Hughes) - Use the GSetting enum functionality (Richard Hughes) - Make libnotify optional dependency as it relies on gtk-2.0 (Richard Hughes) - Make VTE optional as it relies on gtk-2.0 (Richard Hughes) - Require libcanberra-gtk3 (Richard Hughes) - Require gnome-desktop3 (Richard Hughes) * Bugfix: - Disconnect the VTE callbacks when ending the calibration to prevent a nasty crash (Richard Hughes) - Only emit ::added signals from the main thread, not the coldplug threads (Richard Hughes) - Redo the graph UI in the profiles page to be more HIG friendly (Richard Hughes) - Save the EDID MD5 hash to device-profiles.conf for xrandr devices (Richard Hughes) - Set the calibrate button insensitive if VTE is unavailable (Richard Hughes) - Use the same term 'calibration target' thoughout the UI (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 23 13:06:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:06:32 +0100 Subject: Gray profiles Message-ID: Does anybody actually use gray ICC profiles? Would it make sense to add a UI element for this type of profile? Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:20:47 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:20:47 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: > Does anybody actually use gray ICC profiles? Yes, Photoshop's grey profiles are a must to properly use greyscale images in Scribus. Sad but true. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Wed Jun 23 13:26:30 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:26:30 +0100 Subject: Gray profiles In-Reply-To: References: Message-ID: On 23 June 2010 14:20, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: >> Does anybody actually use gray ICC profiles? > > Yes, Photoshop's grey profiles are a must to properly use greyscale > images in Scribus. Sad but true. Do we have any open source or BSD gray icc profiles in any existing projects? Thanks, Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:29:56 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:29:56 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: >> Yes, Photoshop's grey profiles are a must to properly use greyscale >> images in Scribus. Sad but true. > > Do we have any open source or BSD gray icc profiles in any existing projects? Not that I know of. I was intending to look into it, but never found enough time and I'm currently lacking expertize in profiles creation anyway. Alexandre Prokoudine http://libregraphicsworld.org From pmjdebruijn at pcode.nl Wed Jun 23 16:00:36 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 23 Jun 2010 18:00:36 +0200 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 3:29 PM, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: > >>> Yes, Photoshop's grey profiles are a must to properly use greyscale >>> images in Scribus. Sad but true. >> >> Do we have any open source or BSD gray icc profiles in any existing projects? > > Not that I know of. I was intending to look into it, but never found > enough time and I'm currently lacking expertize in profiles creation > anyway. Maybe it's just me... But it doesn't sound like this would be to hard to do... I mean... You can't get the color wrong :) Regards, Pascal de Bruijn From graeme2 at argyllcms.com Thu Jun 24 03:44:13 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 24 Jun 2010 13:44:13 +1000 Subject: Gray profiles In-Reply-To: References: Message-ID: <4C22D48D.5020901@argyllcms.com> Pascal de Bruijn wrote: > I mean... You can't get the color wrong :) Yes you can. For a cLUT profile the A2B needs to map the colorant value to PCS, and your PCS value could have the wrong color ... Graeme Gill. From hughsient at gmail.com Thu Jun 24 11:08:22 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 12:08:22 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 11:52, Pascal de Bruijn wrote: > I did notice LCMS2 hasn't hit the Debian package repo's yet... But > it's still early after it's release... So I guess that'll get fixed > before (for example) the next Ubuntu is released... Okay, gnome-color-manager in git master now requires lcms2. This also means we can start to write ICC profiles with vcgt tags ourselves, to do things like manual calibration without calibration equipment. Richard. From hughsient at gmail.com Thu Jun 24 12:47:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 13:47:56 +0100 Subject: Photography contest! Message-ID: I need a sample image that will be used in the GNOME Color Manager profile viewer. The image will be changed according to the input and output color spaces, so the user can see what affect the profile has on a typical (example) image. This is an ideal task if you want to help the project, but can't code. So, the image has to be: * GPLv2+ or public domain * 200 pixels high by 400 pixels wide * Brightly colored, with lots of different types of color and shade * Nothing controversial, i.e. no photos of naked ladies or of a BP oil spill... * Interesting, not just a sunset or picture of water * Be saved as sRGB png format (although it's okay if that makes it look a bit odd...) The image has to show clearly what difference sRGB, Adobe and ProPhoto have when importing and exporting, so having some out of sRGB gamut colors would be ideal. Let the contest begin. :-) Richard. From hughsient at gmail.com Tue Jun 29 12:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:05:36 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? Message-ID: I'm pondering adding i2c-encoding functionality to GCM to allow us to reprogram the external panel gamma ramps, rather than using X. Using X has the disadvantage of lowering the number of colors we can display, as we artificially have to limit the gamut range when setting the VCGT tag. Changing this on the monitor itself gives us the advantage of not lowing the gamut range, as it's hopefully operating later in the analog chain. Ideas and feedback welcome. If anyone has ever tried this before, I would appreciate any advice. Thanks. Richard. From graeme2 at argyllcms.com Tue Jun 29 12:32:48 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Tue, 29 Jun 2010 22:32:48 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: Message-ID: <4C29E7F0.2020101@argyllcms.com> Richard Hughes wrote: > Ideas and feedback welcome. If anyone has ever tried this before, I > would appreciate any advice. Thanks. Naturally I've considered this. The problems are: There is no standard X mechanisms for doing this. X accesses the monitors i2c to load the EDID, but doesn't provide a general purpose communication channel. The logical place for it is in XRandR, since it knows about outputs (monitors). Although the i2c might be accessed elsewhere in Linux, there is the problem of figuring out the association between the i2c and the outputs. The above wouldn't have stopped me doing this for MSWin and OS X, but there is the second problem: there is no standard i2c video monitor protocol for this. Each manufacturer can do it their own way, and doesn't publish how they do it. You have to reverse engineer it for each monitor. Without access to a representative set of monitors, the coverage of monitors is likely to be spotty. (I don't have a single monitor with this feature.) Graeme Gill. From hughsient at gmail.com Tue Jun 29 12:59:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:59:48 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: <4C29E7F0.2020101@argyllcms.com> References: <4C29E7F0.2020101@argyllcms.com> Message-ID: On 29 June 2010 13:32, Graeme Gill wrote: > Naturally I've considered this. I had hoped so :-) > ? ? ? ?There is no standard X mechanisms for doing this. X accesses > the monitors i2c to load the EDID, but doesn't provide a general purpose > communication channel. The logical place for it is in XRandR, since it > knows about outputs (monitors). Although the i2c might be accessed elsewhere > in Linux, there is the problem of figuring out the association between > the i2c and the outputs. Right, I've looked at doing this in X (or the kernel, via KMS) and it basically comes down to ic2 being so slow. X can't run threaded, and using i2c means we have to block for huge amounts of time. Doing it in the kernel makes threads possible, although it makes things much harder in other ways. > The above wouldn't have stopped me doing this for MSWin and OS X, > but there is the second problem: there is no standard i2c video monitor > protocol for this. Each manufacturer can do it their own way, and > doesn't publish how they do it. You have to reverse engineer it > for each monitor. Without access to a representative set of > monitors, the coverage of monitors is likely to be spotty. Right, agreed. I've been looking at the database table in ddcontrol and it only supports a few monitors out of the thousands of different kinds ever made. With no agreed standard, I agree this is a classic chicken and egg thing. I've been trying to use the standard (no quirks) mode of ddcontrol and it seems to work kinda-okay, although that could be me getting lucky. > (I don't have a single monitor with this feature.) I've got an LG monitor with this functionality, although I'm only basing all my assumptions of "it'll work fine" on a sample size of 1. Whether it's worth doing, I'm not sure. Maybe effort is better put into putting the color conversion into a GLSL shader rather than poking about with VCGT-type data. Richard. From graeme2 at argyllcms.com Tue Jun 29 14:45:39 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Wed, 30 Jun 2010 00:45:39 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: <4C29E7F0.2020101@argyllcms.com> Message-ID: <4C2A0713.4040206@argyllcms.com> Richard Hughes wrote: > Right, I've looked at doing this in X (or the kernel, via KMS) and it > basically comes down to ic2 being so slow. X can't run threaded, and > using i2c means we have to block for huge amounts of time. Doing it in > the kernel makes threads possible, although it makes things much > harder in other ways. Hmm. A way around this would be to expose the i2c bus at a very low level through X, and rely on the caller to do the timing. (I think that the OS X stuff almost works at this level). > Right, agreed. I've been looking at the database table in ddcontrol > and it only supports a few monitors out of the thousands of different > kinds ever made. With no agreed standard, I agree this is a classic > chicken and egg thing. I've been trying to use the standard (no > quirks) mode of ddcontrol and it seems to work kinda-okay, although > that could be me getting lucky. As I understand it, there isn't LUT access though ddcontrol, since it's not in any VESA standard. There is access to other typical controls (brightness, contrast etc.), but each monitor seems to do that differently too from what I've been told. Some of the higher end monitors use USB to access the LUTs. (One of the display profile vendors offered an VGA breakout cable that allowed the i2c to be accessed via USB, simply because the i2c access via the video drivers on MSWin were so unreliable.) > Whether it's worth doing, I'm not sure. Maybe effort is better put > into putting the color conversion into a GLSL shader rather than > poking about with VCGT-type data. Anything is possible, but without a largish budget for buying and testing monitors, or being so important that they ship them to you for free (as one guesses happens with Microsoft), it's a tough problem to offer a known working piece of code. Graeme Gill. From hughsient at gmail.com Tue Jun 1 11:44:10 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 1 Jun 2010 12:44:10 +0100 Subject: GNOME Color Manager 2.30.2 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.30.2 ~~~~~~~~~~~~~~ Released: 2010-06-01 * Translations - Added Japanese translation (Ryo Fujita) - Updated British English translation (Bruce Cowan) * Bugfix: - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not crash when the schema is invalid and GConf reports an error (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed. Fixes rh#590465 (Richard Hughes) - Get the profile permissions from GIO rather than hardcoding a hack (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 2 07:42:39 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 08:42:39 +0100 Subject: GNOME Color Manager accepted into desktop module for 2.32.x Message-ID: Some great news: The GNOME release team met in May to discuss potential modules to be added to GNOME, and they approved gnome-color-manager into the desktop set. This means that distros that ship GNOME 2.32 will also be shipping gnome-color-manager by default. The release team noted the excellent integration of GCM into the desktop, and did not gather a single negative problem or issue to watch. What this means for GCM: More work, more users and more bugs. * We have to do releases with the GNOME release schedule * We have to fix up any deviations from the Human Interface Guidelines * We have to keep random dependencies like exiv2 and SANE as optional build time deps. * We have to start testing on Solaris, FreeBSD and non-xorg platforms and adding portability fixes and code where required. * We have to remove deprecated module usage (GConf2 and dbus-glib are already gone in master) It's started a good day for me, as this recognizes the importance of color management in the GNOME desktop, and the programming, testing, artwork and translations from me and all you guys and girls. In the coming months I'm going to need more help translating, testing, checking, fixing and triaging bugs, so we can produce a gnome-color-manager-2.32.0 that we're proud of. Thanks. Richard. From hughsient at gmail.com Wed Jun 2 10:25:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 11:25:16 +0100 Subject: GCM and LGM 2010 Message-ID: Not being at LGM 2010 (too little travel budget, and in the middle of buying a house) I missed out on lots of important discussions. Can anybody who went fill in any details? What presentations were relevant to GCM? Was GCM discussed at all? Thanks. Richard. From hughsient at gmail.com Wed Jun 2 11:40:21 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 2 Jun 2010 12:40:21 +0100 Subject: GNOME Color Manager 2.31.2 Message-ID: Version 2.31.2 ~~~~~~~~~~~~~~ Released: 2010-06-02 * Notes - You'll need Glib 2.25.1 and VTE 0.25.1 to compile now. - Lots of the new functionality is checked for at build time. Ensure you have development packages for cups, sane-backends, libtiff, libexif and exiv2 for full functionality. * Translations - Updated Czech translation (Milan Knizek) - Updated Danish translation (Ask H. Larsen) - Updated Estonian translation (Mattias P?ldaru) - Updated French translation (Claude Paroz) - Updated German doc translation (Mario Bl?ttermann) - Updated German translation (Christian Kirbach) - Updated German translation (Mario Bl?ttermann) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Port to GDBus (Richard Hughes) - Port to GSettings (Richard Hughes) - Port to GTest (Richard Hughes) - Add UI elements to assign multiple profiles for each device (Richard Hughes) - Add GetProfilesForFile() DBus method to get suitable ICC profiles for a given file (Richard Hughes) - Add a GConf to GSettings migration script (Richard Hughes) - Add optional exif2 support so we can get properties of RAW files (Richard Hughes) - Allow the user to just drag an image file onto the window to create a virtual profile (Richard Hughes) - Allow the user to double click a profile to make it default (Richard Hughes) * Bugfix: - Add a message in the help file explaining the drop file action (Richard Hughes) - Add gcm_profile_get_can_delete() and get the permissions from GIO rather than hardcoding a hack (Richard Hughes) - Add gcm_profile_get_checksum() so we can use this as a key to detect duplicates (Richard Hughes) - Add some information labels to the defaults pane (Richard Hughes) - Add two new settings objects 'enable-sane' and 'enable-cups' for in-field debugging (Richard Hughes) - Allow adding saved devices when coldplugging (Richard Hughes) - Allow RAW files to be dragged onto the UI with spaces in the name (Richard Hughes) - Allow virtual devices to have a serial number (Richard Hughes) - At login do not attempt to remove previously set X atoms, which speeds up gcm-apply by 750ms (Richard Hughes) - Ignore duplicate profiles by the MD5 checksum (Richard Hughes) - Include the serial number in the virtual device ID (Richard Hughes) - Include the trailing colon in translated strings. Fixes #619967 (Richard Hughes) - Migrate the old device-profiles.conf to the new location so the user does not have to do it manually (Richard Hughes) - Only connect to SANE and CUPS when the device lists are needed (Richard Hughes) - Do not bother the user with calibration notifications by default (Richard Hughes) - Put a short intent description in the combobox choices (Richard Hughes) - Support version 0.2 of the OpenIccDirectoryProposal (Richard Hughes) - Use the new ARGYLL_NOT_INTERACTIVE environment variable (Richard Hughes) - Use the newer VTE API (Richard Hughes) Richard. From pmjdebruijn at pcode.nl Thu Jun 3 17:18:37 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 3 Jun 2010 19:18:37 +0200 Subject: GCM and LGM 2010 In-Reply-To: References: Message-ID: On Wed, Jun 2, 2010 at 12:25 PM, Richard Hughes wrote: > Not being at LGM 2010 (too little travel budget, and in the middle of > buying a house) I missed out on lots of important discussions. Can > anybody who went fill in any details? What presentations were relevant > to GCM? Was GCM discussed at all? I was present for at least a day... I attended the OpenICC meeting... Kai-Uwe did a presentation on Oyranos which I sadly mostly missed :( I did talk to Kai-Uwe at the OpenICC meeting though, amongst other things we talked about how color management apps should interface with each other, and I pointed to GCM and it's DBUS API... Nobody present seemed to object to use DBUS for such a purpose... I do think they video'd most talks, so I guess you can still view most talks in a couple of days :) Regards, Pascal de Bruijn From hughsient at gmail.com Thu Jun 10 13:39:40 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 10 Jun 2010 14:39:40 +0100 Subject: GNOME Color Manager: a question about some terms In-Reply-To: <20100610144011.4f613909@anche.no> References: <20100610144011.4f613909@anche.no> Message-ID: On 10 June 2010 13:40, F. Gr. wrote: > I'm translating GNOME Color Manager for Italian language. Great, thanks! > I would know > the differences among the terms "reference image", "chart type" and > "calibrated target". Have you got any links that explains the ones? Well, if it's unclear, we probably have to include things like that in the translator comments, and it also sounds like we're using different terms for the same thing. I've applied this to git master: commit d08e4ef23f7c50b754f8572ba139bdc2312abd1d Author: Richard Hughes Date: Thu Jun 10 14:38:11 2010 +0100 Use the same term 'calibration target' thoughout the UI Can you git pull from master again please, and then verify things are a bit easier to translate? I would also be interested in any other parts you found difficult. Thanks. Richard. From hughsient at gmail.com Mon Jun 14 16:09:27 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:09:27 +0100 Subject: What I've been up to... Message-ID: It's been a bit quiet from me recently. What I've been doing: * UI cleanups in the prefs widget * Porting everything to GNOME 3 * Working on full screen color management --- Wait. Full screen? Yup. I've been working on the mutter window manager to use GLSL shaders to do color correction on the GPU in hardware. Hopefully, it'll all be native in the window manager and only need a few tweaks to applications. It's early days, but it seems to work very well. I've attached a screenshot for your drooling pleasure. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 178361 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Mon Jun 14 16:36:21 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 18:36:21 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 6:09 PM, Richard Hughes wrote: > It's been a bit quiet from me recently. What I've been doing: > > * UI cleanups in the prefs widget > * Porting everything to GNOME 3 > * Working on full screen color management > > --- Wait. Full screen? > > Yup. I've been working on the mutter window manager to use GLSL > shaders to do color correction on the GPU in hardware. Hopefully, > it'll all be native in the window manager and only need a few tweaks > to applications. It's early days, but it seems to work very well. > > I've attached a screenshot for your drooling pleasure. I was already pretty happy with the current state of affairs... But this will rock severely :) Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 14 16:44:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 17:44:45 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 17:36, Pascal de Bruijn wrote: > I was already pretty happy with the current state of affairs... But > this will rock severely :) Well, it's early days -- but this should help the eyes of those lucky enough to have large-gamut monitors. Richard. From alexandre.prokoudine at gmail.com Mon Jun 14 17:42:26 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 21:42:26 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Richard Hughes wrote: > Well, it's early days -- but this should help the eyes of those lucky > enough to have large-gamut monitors. Exactly how? Will it make the profile be applied to displays LUT? :) Alexandre From pmjdebruijn at pcode.nl Mon Jun 14 17:50:46 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 14 Jun 2010 19:50:46 +0200 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 7:42 PM, Alexandre Prokoudine wrote: > On 6/14/10, Richard Hughes wrote: > >> Well, it's early days -- but this should help the eyes of those lucky >> enough to have large-gamut monitors. > > Exactly how? Will it make the profile be applied to displays LUT? :) It's not... Since most displays don't have a programmable LUT... unless you want to spend 1500USD+ Not even talking about the fact that (as far as I know) there is no standardized way to load a LUT into the different brands of LCDs. Regards, Pascal de Bruijn From alexandre.prokoudine at gmail.com Mon Jun 14 18:20:01 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Mon, 14 Jun 2010 22:20:01 +0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 6/14/10, Pascal de Bruijn wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > It's not... Since most displays don't have a programmable LUT... > unless you want to spend 1500USD+ But I did spend it :) > Not even talking about the fact that (as far as I know) there is no > standardized way to load a LUT into the different brands of LCDs. >From what I remember they all used to rely on just two different chips. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Mon Jun 14 21:18:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:18:43 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 19:20, Alexandre Prokoudine wrote: >> It's not... Since most displays don't have a programmable LUT... >> unless you want to spend 1500USD+ > > But I did spend it :) Sure, it's very possible using i2c. I've used i2c quite a lot in my last job. The tricky bit is wiring it into Xorg, as i2c is pretty slow (at least in non-high speed mode) and X can't spawn extra threads. I also don't think you need to spend that much money if you want to be able to program the display LUT. I'm pretty sure I can do it on my ?200 LG screen. Richard. From hughsient at gmail.com Mon Jun 14 21:20:33 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jun 2010 22:20:33 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 14 June 2010 18:42, Alexandre Prokoudine wrote: > Exactly how? Will it make the profile be applied to displays LUT? :) No, but it should be useful for people with profiles without vcgt tags, and also to correct color casts. Richard. From luto at mit.edu Tue Jun 15 06:57:23 2010 From: luto at mit.edu (Andrew Lutomirski) Date: Tue, 15 Jun 2010 02:57:23 -0400 Subject: What I've been up to... In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 5:20 PM, Richard Hughes wrote: > On 14 June 2010 18:42, Alexandre Prokoudine > wrote: >> Exactly how? Will it make the profile be applied to displays LUT? :) > > No, but it should be useful for people with profiles without vcgt > tags, and also to correct color casts. Are you planning on supporting CLUT or just matrix+shaper? And what does this do to vcgt? I'd guess that if we can't program our monitors' LUTs then we're better off not using vcgt and improving our gamut a touch. --Andy From hughsient at gmail.com Tue Jun 15 08:38:02 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 Jun 2010 09:38:02 +0100 Subject: What I've been up to... In-Reply-To: References: Message-ID: On 15 June 2010 07:57, Andrew Lutomirski wrote: > Are you planning on supporting CLUT or just matrix+shaper? Both I guess. > And what does this do to vcgt? ?I'd guess that if we can't program our > monitors' LUTs then we're better off not using vcgt and improving our > gamut a touch. Yes, I'm not sure applying VCGT makes much sense if we're doing a 3d LUT. Richard. From lists+gnome-color-manager at hoech.org Tue Jun 15 15:55:11 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Tue, 15 Jun 2010 17:55:11 +0200 Subject: Installing display profiles/interfacing with gcm Message-ID: <4C17A25F.7060806@hoech.org> Hi, I'm currently looking for a way to install display profiles in a similar way as Argyll's dispwin does. So, I'm either looking for an utility 'gcm-install-display-profile' that would copy the file, do the mapping displayno->device and write the neccessary info to device-profiles.conf (does gcm-install-systemwide do this?). Or for another way to achieve what I just described (DBus?). Reason I'm asking is I'd like to offer profile installation in a GCM-compatible way in dispcalGUI if GCM is also installed, as I'm currently only supporting the Argyll dispwin (UCMM) way. Or is it safe/recommended to write to device-profiles.conf directly? Then, I'd just have to figure out how to do the Argyll displayno -> GCM device mapping (btw, what's the $(ascii) in xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). Pointers welcome :) Thanks in advance and regards -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 10:41:11 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 11:41:11 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C17A25F.7060806@hoech.org> References: <4C17A25F.7060806@hoech.org> Message-ID: On 15 June 2010 16:55, Florian H?ch wrote: > I'm currently looking for a way to install display profiles in a similar way > as Argyll's dispwin does. So, I'm either looking for an utility > 'gcm-install-display-profile' that would copy the > file, do the mapping displayno->device and write the neccessary info to > device-profiles.conf (does gcm-install-systemwide do this?). No, gcm-install-systemwide just installs the profiles system-wide. It's also pretty fragile the way it works, and probably needs rethinking in the near future. > Or for another way to achieve what I just described (DBus?). I think a DBus call would be okay, but it seems very specific to this use case. GCM also stores other data with the profile entry which would need to be formatted like the others by dispcalGUI. > Or is it safe/recommended to write to device-profiles.conf directly? I guess. If GCM is open at the time then it might cause problems, but I can always add an inotify watch on the config file and reload GCM's in-memory copy if it changes. I'm not sure this is a great idea, as the config file has no locking, and no ABI stability. > Then, I'd just have to figure out how to do the Argyll displayno -> GCM > device mapping (btw, what's the $(ascii) in > xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". I'm fully open to changing the format of the device-profiles.conf file if required. That could mean adding a hash=${md5_of_edid} parameter to the display section, or it could be just making the identifier be xrandr_${md5_of_edid} -- but then we have all the problems of writing the junk data required to display a meaningful device icon when the display is not attached. If the user has already run gcm-prefs and the device was saved, and you just want to change the default, then searching on hash= is probably the right thing to do. Of course, the best option is probably for GCM to expose libgcm (better names welcome) which would allow you to just call gcm_device_save() trivially in C. It would mean a compile-time optional dep on GCM, but it probably the most correct thing to do. Comments please. :-) Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 12:00:02 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 14:00:02 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> Message-ID: <4C18BCC2.20107@hoech.org> Am 16.06.2010 12:41, schrieb Richard Hughes: > On 15 June 2010 16:55, Florian H?ch wrote: >> I'm currently looking for a way to install display profiles in a similar way >> as Argyll's dispwin does. So, I'm either looking for an utility >> 'gcm-install-display-profile' that would copy the >> file, do the mapping displayno->device and write the neccessary info to >> device-profiles.conf (does gcm-install-systemwide do this?). > > No, gcm-install-systemwide just installs the profiles system-wide. > It's also pretty fragile the way it works, and probably needs > rethinking in the near future. Ok. >> Or for another way to achieve what I just described (DBus?). > > I think a DBus call would be okay, but it seems very specific to this > use case. GCM also stores other data with the profile entry which > would need to be formatted like the others by dispcalGUI. > >> Or is it safe/recommended to write to device-profiles.conf directly? > > I guess. If GCM is open at the time then it might cause problems, but > I can always add an inotify watch on the config file and reload GCM's > in-memory copy if it changes. I'm not sure this is a great idea, as > the config file has no locking, and no ABI stability. Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last resort". >> Then, I'd just have to figure out how to do the Argyll displayno -> GCM >> device mapping (btw, what's the $(ascii) in >> xrandr_$(vendor)_$(name)_$(ascii)_$(serial) mentioned in the GCM wiki?). > > It's the ASCII text returned in the EDID, e.g. "LTN154P2-L05". Ah, ok. So then all the naming information is available through the EDID? That's fine with me. > I'm > fully open to changing the format of the device-profiles.conf file if > required. That could mean adding a hash=${md5_of_edid} parameter to > the display section, or it could be just making the identifier be > xrandr_${md5_of_edid} -- but then we have all the problems of writing > the junk data required to display a meaningful device icon when the > display is not attached. If the user has already run gcm-prefs and the > device was saved, and you just want to change the default, then > searching on hash= is probably the right thing to do. Agreed on your points. I think the format of the config file is fine, although addition of the EDID hash key sounds like a nice idea. > Of course, the best option is probably for GCM to expose libgcm > (better names welcome) which would allow you to just call > gcm_device_save() trivially in C. It would mean a compile-time > optional dep on GCM, but it probably the most correct thing to do. That would be nice, then I could let GCM do "the right thing" for me. Dep on GCM is not a problem I think, as I'm probably going to use Python's ctypes then, which can tell me if the library is installed and I can also use it to wrap the C function call. Thanks for the infos so far! > Comments please. :-) > > Richard. -- Florian H?ch http://hoech.net From hughsient at gmail.com Wed Jun 16 14:13:55 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jun 2010 15:13:55 +0100 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18BCC2.20107@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: On 16 June 2010 13:00, Florian H?ch wrote: > Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last > resort". Right. The lack of locking makes this a quick fix, but probably not a good idea. > Ah, ok. So then all the naming information is available through the EDID? Right. > Agreed on your points. I think the format of the config file is fine, > although addition of the EDID hash key sounds like a nice idea. commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 Author: Richard Hughes Date: Wed Jun 16 15:04:38 2010 +0100 Save the EDID MD5 hash to device-profiles.conf for xrandr devices > That would be nice, then I could let GCM do "the right thing" for me. Dep on > GCM is not a problem I think, as I'm probably going to use Python's ctypes > then, which can tell me if the library is installed and I can also use it to > wrap the C function call. Right, this is probably the best thing to do. I'll look at librification now, although it's quite a big change, and it might make sense for the gnome3 stuff to settle down first. Richard. From lists+gnome-color-manager at hoech.org Wed Jun 16 15:58:35 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Wed, 16 Jun 2010 17:58:35 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> Message-ID: <4C18F4AB.50809@hoech.org> Am 16.06.2010 16:13, schrieb Richard Hughes: >> On 16 June 2010 13:00, Florian H?ch wrote: >>> Hmm, sounds like I'll probably want to avoid it, then ;) Maybe as a "last >>> resort". >> >> Right. The lack of locking makes this a quick fix, but probably not a good idea. >> >>> Ah, ok. So then all the naming information is available through the EDID? >> >> Right. >> >>> Agreed on your points. I think the format of the config file is fine, >>> although addition of the EDID hash key sounds like a nice idea. >> >> commit d22f9c2a567eef04a72cabf1125fe02c3d79efb1 >> Author: Richard Hughes >> Date: Wed Jun 16 15:04:38 2010 +0100 >> >> Save the EDID MD5 hash to device-profiles.conf for xrandr devices Cool, thanks! >>> That would be nice, then I could let GCM do "the right thing" for me. Dep on >>> GCM is not a problem I think, as I'm probably going to use Python's ctypes >>> then, which can tell me if the library is installed and I can also useit to >>> wrap the C function call. >> >> Right, this is probably the best thing to do. I'll look at >> librification now, although it's quite a big change, and it might make >> sense for the gnome3 stuff to settle down first. >> >> Richard. No need to hurry, I'm glad you're looking into it! :) -- Florian H?ch http://hoech.net From hughsient at gmail.com Thu Jun 17 14:58:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 Jun 2010 15:58:20 +0100 Subject: Next release tomorrow Message-ID: I'm having to do a new development release of GCM tomorrow. GLib and GTK both changed API this point release, and we're trying to co-ordinate so there isn't breakage for the devel distros. If you've got pending translations, please merge them before tomorrow morning. Thanks. Richard. From lists at hoech.net Fri Jun 18 18:24:16 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 18 Jun 2010 20:24:16 +0200 Subject: Installing display profiles/interfacing with gcm In-Reply-To: <4C18F4AB.50809@hoech.org> References: <4C17A25F.7060806@hoech.org> <4C18BCC2.20107@hoech.org> <4C18F4AB.50809@hoech.org> Message-ID: <4C1BB9D0.4070803@hoech.net> I've now added rudimentary support for GCM in the upcoming next release of dispcalGUI (changes are not yet in SVN though). If GCM is installed and XRandR is working, I'm parsing EDID and also device-profiles.conf (only reading) to add necessary/useful info like manufacturer and model to the profile thats going to be installed, before gcm-import is called to bring the profile inside GCM. This way seems to work pretty well and can still be replaced later. -- Florian H?ch http://hoech.net From hughsient at gmail.com Mon Jun 21 08:03:44 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 09:03:44 +0100 Subject: Switching to lcms2? Message-ID: Does anybody have an problems if gnome-color-manager switches to lcms2 later this week? Richard. From pmjdebruijn at pcode.nl Mon Jun 21 08:44:08 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 10:44:08 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: > Does anybody have an problems if gnome-color-manager switches to lcms2 > later this week? Since the GSettings stuff already breaks compatibility with older distro's, I don't see why lcms2 would cause any additional problems... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 10:44:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 11:44:20 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 09:44, Pascal de Bruijn wrote: > On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >> Does anybody have an problems if gnome-color-manager switches to lcms2 >> later this week? > > Since the GSettings stuff already breaks compatibility with older > distro's, I don't see why lcms2 would cause any additional problems... This was my thought too. Richard. From pmjdebruijn at pcode.nl Mon Jun 21 10:52:34 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Mon, 21 Jun 2010 12:52:34 +0200 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On Mon, Jun 21, 2010 at 12:44 PM, Richard Hughes wrote: > On 21 June 2010 09:44, Pascal de Bruijn wrote: >> On Mon, Jun 21, 2010 at 10:03 AM, Richard Hughes wrote: >>> Does anybody have an problems if gnome-color-manager switches to lcms2 >>> later this week? >> >> Since the GSettings stuff already breaks compatibility with older >> distro's, I don't see why lcms2 would cause any additional problems... > > This was my thought too. I did notice LCMS2 hasn't hit the Debian package repo's yet... But it's still early after it's release... So I guess that'll get fixed before (for example) the next Ubuntu is released... Regards, Pascal de Bruijn From hughsient at gmail.com Mon Jun 21 16:06:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 21 Jun 2010 17:06:35 +0100 Subject: GNOME Color Manager 2.31.3 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.3 ~~~~~~~~~~~~~~ Released: 2010-06-21 * Translations - Added Galician translations (Fran Di?guez) - Added Hebrew translation (Yaron Shahrabani) - Added Norwegian bokm?l translation (Kjartan Maraas) - Updated Indonesian translation (Andika Triwidada) - Updated Italian translation (Francesco Groccia) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Punjabi Translation (A S Alam) - Updated Spanish translation (Jorge Gonz?lez) - Updated Galician translations (Fran Di?guez) - Updated Hebrew translation (Yaron Shahrabani) * New Features: - Require GTK3 as per the GNOME release team announcement (Richard Hughes) - Port to GtkApplication (Richard Hughes) - Port to GDBus (Richard Hughes) - Use the GSetting enum functionality (Richard Hughes) - Make libnotify optional dependency as it relies on gtk-2.0 (Richard Hughes) - Make VTE optional as it relies on gtk-2.0 (Richard Hughes) - Require libcanberra-gtk3 (Richard Hughes) - Require gnome-desktop3 (Richard Hughes) * Bugfix: - Disconnect the VTE callbacks when ending the calibration to prevent a nasty crash (Richard Hughes) - Only emit ::added signals from the main thread, not the coldplug threads (Richard Hughes) - Redo the graph UI in the profiles page to be more HIG friendly (Richard Hughes) - Save the EDID MD5 hash to device-profiles.conf for xrandr devices (Richard Hughes) - Set the calibrate button insensitive if VTE is unavailable (Richard Hughes) - Use the same term 'calibration target' thoughout the UI (Richard Hughes) Richard. From hughsient at gmail.com Wed Jun 23 13:06:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:06:32 +0100 Subject: Gray profiles Message-ID: Does anybody actually use gray ICC profiles? Would it make sense to add a UI element for this type of profile? Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:20:47 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:20:47 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: > Does anybody actually use gray ICC profiles? Yes, Photoshop's grey profiles are a must to properly use greyscale images in Scribus. Sad but true. Alexandre Prokoudine http://libregraphicsworld.org From hughsient at gmail.com Wed Jun 23 13:26:30 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 23 Jun 2010 14:26:30 +0100 Subject: Gray profiles In-Reply-To: References: Message-ID: On 23 June 2010 14:20, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:06 PM, Richard Hughes wrote: >> Does anybody actually use gray ICC profiles? > > Yes, Photoshop's grey profiles are a must to properly use greyscale > images in Scribus. Sad but true. Do we have any open source or BSD gray icc profiles in any existing projects? Thanks, Richard. From alexandre.prokoudine at gmail.com Wed Jun 23 13:29:56 2010 From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine) Date: Wed, 23 Jun 2010 17:29:56 +0400 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: >> Yes, Photoshop's grey profiles are a must to properly use greyscale >> images in Scribus. Sad but true. > > Do we have any open source or BSD gray icc profiles in any existing projects? Not that I know of. I was intending to look into it, but never found enough time and I'm currently lacking expertize in profiles creation anyway. Alexandre Prokoudine http://libregraphicsworld.org From pmjdebruijn at pcode.nl Wed Jun 23 16:00:36 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 23 Jun 2010 18:00:36 +0200 Subject: Gray profiles In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 3:29 PM, Alexandre Prokoudine wrote: > On Wed, Jun 23, 2010 at 5:26 PM, Richard Hughes wrote: > >>> Yes, Photoshop's grey profiles are a must to properly use greyscale >>> images in Scribus. Sad but true. >> >> Do we have any open source or BSD gray icc profiles in any existing projects? > > Not that I know of. I was intending to look into it, but never found > enough time and I'm currently lacking expertize in profiles creation > anyway. Maybe it's just me... But it doesn't sound like this would be to hard to do... I mean... You can't get the color wrong :) Regards, Pascal de Bruijn From graeme2 at argyllcms.com Thu Jun 24 03:44:13 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Thu, 24 Jun 2010 13:44:13 +1000 Subject: Gray profiles In-Reply-To: References: Message-ID: <4C22D48D.5020901@argyllcms.com> Pascal de Bruijn wrote: > I mean... You can't get the color wrong :) Yes you can. For a cLUT profile the A2B needs to map the colorant value to PCS, and your PCS value could have the wrong color ... Graeme Gill. From hughsient at gmail.com Thu Jun 24 11:08:22 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 12:08:22 +0100 Subject: Switching to lcms2? In-Reply-To: References: Message-ID: On 21 June 2010 11:52, Pascal de Bruijn wrote: > I did notice LCMS2 hasn't hit the Debian package repo's yet... But > it's still early after it's release... So I guess that'll get fixed > before (for example) the next Ubuntu is released... Okay, gnome-color-manager in git master now requires lcms2. This also means we can start to write ICC profiles with vcgt tags ourselves, to do things like manual calibration without calibration equipment. Richard. From hughsient at gmail.com Thu Jun 24 12:47:56 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 24 Jun 2010 13:47:56 +0100 Subject: Photography contest! Message-ID: I need a sample image that will be used in the GNOME Color Manager profile viewer. The image will be changed according to the input and output color spaces, so the user can see what affect the profile has on a typical (example) image. This is an ideal task if you want to help the project, but can't code. So, the image has to be: * GPLv2+ or public domain * 200 pixels high by 400 pixels wide * Brightly colored, with lots of different types of color and shade * Nothing controversial, i.e. no photos of naked ladies or of a BP oil spill... * Interesting, not just a sunset or picture of water * Be saved as sRGB png format (although it's okay if that makes it look a bit odd...) The image has to show clearly what difference sRGB, Adobe and ProPhoto have when importing and exporting, so having some out of sRGB gamut colors would be ideal. Let the contest begin. :-) Richard. From hughsient at gmail.com Tue Jun 29 12:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:05:36 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? Message-ID: I'm pondering adding i2c-encoding functionality to GCM to allow us to reprogram the external panel gamma ramps, rather than using X. Using X has the disadvantage of lowering the number of colors we can display, as we artificially have to limit the gamut range when setting the VCGT tag. Changing this on the monitor itself gives us the advantage of not lowing the gamut range, as it's hopefully operating later in the analog chain. Ideas and feedback welcome. If anyone has ever tried this before, I would appreciate any advice. Thanks. Richard. From graeme2 at argyllcms.com Tue Jun 29 12:32:48 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Tue, 29 Jun 2010 22:32:48 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: Message-ID: <4C29E7F0.2020101@argyllcms.com> Richard Hughes wrote: > Ideas and feedback welcome. If anyone has ever tried this before, I > would appreciate any advice. Thanks. Naturally I've considered this. The problems are: There is no standard X mechanisms for doing this. X accesses the monitors i2c to load the EDID, but doesn't provide a general purpose communication channel. The logical place for it is in XRandR, since it knows about outputs (monitors). Although the i2c might be accessed elsewhere in Linux, there is the problem of figuring out the association between the i2c and the outputs. The above wouldn't have stopped me doing this for MSWin and OS X, but there is the second problem: there is no standard i2c video monitor protocol for this. Each manufacturer can do it their own way, and doesn't publish how they do it. You have to reverse engineer it for each monitor. Without access to a representative set of monitors, the coverage of monitors is likely to be spotty. (I don't have a single monitor with this feature.) Graeme Gill. From hughsient at gmail.com Tue Jun 29 12:59:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Jun 2010 13:59:48 +0100 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: <4C29E7F0.2020101@argyllcms.com> References: <4C29E7F0.2020101@argyllcms.com> Message-ID: On 29 June 2010 13:32, Graeme Gill wrote: > Naturally I've considered this. I had hoped so :-) > ? ? ? ?There is no standard X mechanisms for doing this. X accesses > the monitors i2c to load the EDID, but doesn't provide a general purpose > communication channel. The logical place for it is in XRandR, since it > knows about outputs (monitors). Although the i2c might be accessed elsewhere > in Linux, there is the problem of figuring out the association between > the i2c and the outputs. Right, I've looked at doing this in X (or the kernel, via KMS) and it basically comes down to ic2 being so slow. X can't run threaded, and using i2c means we have to block for huge amounts of time. Doing it in the kernel makes threads possible, although it makes things much harder in other ways. > The above wouldn't have stopped me doing this for MSWin and OS X, > but there is the second problem: there is no standard i2c video monitor > protocol for this. Each manufacturer can do it their own way, and > doesn't publish how they do it. You have to reverse engineer it > for each monitor. Without access to a representative set of > monitors, the coverage of monitors is likely to be spotty. Right, agreed. I've been looking at the database table in ddcontrol and it only supports a few monitors out of the thousands of different kinds ever made. With no agreed standard, I agree this is a classic chicken and egg thing. I've been trying to use the standard (no quirks) mode of ddcontrol and it seems to work kinda-okay, although that could be me getting lucky. > (I don't have a single monitor with this feature.) I've got an LG monitor with this functionality, although I'm only basing all my assumptions of "it'll work fine" on a sample size of 1. Whether it's worth doing, I'm not sure. Maybe effort is better put into putting the color conversion into a GLSL shader rather than poking about with VCGT-type data. Richard. From graeme2 at argyllcms.com Tue Jun 29 14:45:39 2010 From: graeme2 at argyllcms.com (Graeme Gill) Date: Wed, 30 Jun 2010 00:45:39 +1000 Subject: Sending VCGT data to wide gamut monitors using i2c? In-Reply-To: References: <4C29E7F0.2020101@argyllcms.com> Message-ID: <4C2A0713.4040206@argyllcms.com> Richard Hughes wrote: > Right, I've looked at doing this in X (or the kernel, via KMS) and it > basically comes down to ic2 being so slow. X can't run threaded, and > using i2c means we have to block for huge amounts of time. Doing it in > the kernel makes threads possible, although it makes things much > harder in other ways. Hmm. A way around this would be to expose the i2c bus at a very low level through X, and rely on the caller to do the timing. (I think that the OS X stuff almost works at this level). > Right, agreed. I've been looking at the database table in ddcontrol > and it only supports a few monitors out of the thousands of different > kinds ever made. With no agreed standard, I agree this is a classic > chicken and egg thing. I've been trying to use the standard (no > quirks) mode of ddcontrol and it seems to work kinda-okay, although > that could be me getting lucky. As I understand it, there isn't LUT access though ddcontrol, since it's not in any VESA standard. There is access to other typical controls (brightness, contrast etc.), but each monitor seems to do that differently too from what I've been told. Some of the higher end monitors use USB to access the LUTs. (One of the display profile vendors offered an VGA breakout cable that allowed the i2c to be accessed via USB, simply because the i2c access via the video drivers on MSWin were so unreliable.) > Whether it's worth doing, I'm not sure. Maybe effort is better put > into putting the color conversion into a GLSL shader rather than > poking about with VCGT-type data. Anything is possible, but without a largish budget for buying and testing monitors, or being so important that they ship them to you for free (as one guesses happens with Microsoft), it's a tough problem to offer a known working piece of code. Graeme Gill.