From michielwittkampf at gmail.com Wed May 5 07:42:27 2010 From: michielwittkampf at gmail.com (Michiel Wittkampf) Date: Wed, 5 May 2010 09:42:27 +0200 Subject: GCM and digiKam - how to configure? Message-ID: Hi GCM developers / enthousiasts, I have a question which I could not find the answer for in fora, manuals, color management theorie, etc. Can I use GCM and digiKam succesfully on the same computer, with good colors? And how? Should I enable color management on both, or on one of them? And which suboptions? I looked at the results of switching the folowing options, but didn't figure it out. digiKam: - Enable Color Management - Use color managed view (in editor / for previews and thumbnails) GCM: - Apply display correction - (Set profile for color managed applications.) According tot the digiKam manual Xcalib / Argyll are alternatives to the option 'Use color managed view' in digiKam.* So I supose CGM is too. Yet, when using CGM's 'Apply display correction' makes the screen darker, and using digiKam? 'Use color managed view' gives a brighter picture, while using the same profile. So I am confused. Can you please help me? Greetings, Michiel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Wed May 5 08:00:03 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 5 May 2010 09:00:03 +0100 Subject: GCM and digiKam - how to configure? In-Reply-To: References: Message-ID: On 5 May 2010 08:42, Michiel Wittkampf wrote: > Can you please help me? Well, you certainly want to enable color management in digikam. This means the image source profile is used and is converted to the screen profile, as long as you set the profile for color managed applications in GCM. By setting the source profile you're really just setting a X atom on the root window which digikam can detect and use. If digikam works as a ICC profile in X compatible client, you just have to enable both options in GCM and both options in digikam. Are you using the vendor profile for our screen or are you using a calibrated generated version? Without come sort of calibration you don't know whether the lighter or darker image is the "correct" image. Richard. From hughsient at gmail.com Thu May 6 14:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 6 May 2010 15:05:36 +0100 Subject: GNOME Color Manager 2.31.1 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.1 ~~~~~~~~~~~~~~ Released: 2010-05-06 * Translations - Added Japanese translation (Ryo Fujita) - Added Punjabi Translation (A S Alam) - Added Ukrainian translation (Maxim V. Dziumanenko) - Updated British English translation (Bruce Cowan) - Updated German translation (Mario Bl?ttermann) - Updated Italian translation (Francesco Groccia) - Updated Lithuanian translation (Aurimas ?ernius) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Polish translation (Piotr Dr?g) - Updated Portuguese translation (Ant?nio Lima) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Use a new application icon (Hylke Bons) - Add an experimental gcm-picker program to read spot colors (Richard Hughes) - Show much more detail in the color picker UI and allow the user to choose a RGB colorspace (Richard Hughes) - Show the EISA ID in the devices tab. Fixes rh#581837 (Richard Hughes) * Bugfix: - Clean up the temporary file created by cupsGetPPD2(). Fixes rh#582202 (Tim Waugh) - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not explode when viewing the details of a CMYK profile (Richard Hughes) - Do not rely on an argyllcms specially patched to fix the arg[0] problem (Richard Hughes) - Don't prompt the user to calibrate the device again if we are re-using the GcmCalibrate instance (Richard Hughes) - Fix up the argyll install dialog. Fixes #616106 (Richard Hughes) - Fix up the profile precision dialog. Fixes #583398 (Richard Hughes) - Make gcm-fix-profile open the profile from memory, as then we can catch common access permission errors (Richard Hughes) - Make SANE support configurable at compile time. Fixes #616826 (Richard Hughes) - Offer to install shared-color-profiles-extra if it is not yet installed (Richard Hughes) Richard. From lists+gnome-color-manager at hoech.org Fri May 7 13:13:41 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:13:41 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: Message-ID: <4BE41205.6080301@hoech.org> Hi, recently I switched from the proprietary nvidia driver to noveau, so I could try the latest GCM :) I noticed that for screen calibration, always a quality of 'low' is used and a shaper+matrix profile is created from varying colorpatch amounts and quality parameter. Looking at the code, the 100-500 colorpatches used for the screen profiling really seem overkill for a simple matrix profile. So the first thing I'd suggest, is to always use a lower, fixed-amount colorpatch set: targen -d3 -e4 -g9 -m3, this yields 36 patches that most other profilers out there also seem to use and should give very good results with matrix profiles (of course YMMV, but imho it would be a good default. This is what I use in dispcalGUI atm). Then, I'd suggest colprof -qh for matrix profiles (lower quality levels will smooth the trc curves more, but I think high quality could model the device response more accurately). This shouldn't come at any speed penalty at the new low suggested colorpatch count. And, as GCM always does a calibration+profile, I'd use colprof -aS (single shaper+matrix) instead of -as (per channel shaper+matrix), as we can rely on the calibration already having established gray balance, thus no need to risk the per channel curves introducing banding or shimmering. These changes would remove the need for the current three profile 'precision' choices for screen calibration/profiling, so the last suggestion from me is to instead present the user with a choice for the calibration (dispcal) quality instead, or to get rid of the choice altogether (only for screen calibration/profiling ofcourse). What do you think? Am 06.05.2010 16:05, schrieb Richard Hughes: > 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.1 Regards -- Florian H?ch http://hoech.net From lists+gnome-color-manager at hoech.org Fri May 7 13:36:12 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:36:12 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE4174C.1050903@hoech.org> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From lists at hoech.net Fri May 7 13:33:36 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:33:36 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE416B0.6050309@hoech.net> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From pmjdebruijn at pcode.nl Fri May 7 15:48:54 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 7 May 2010 17:48:54 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE416B0.6050309@hoech.net> References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: > (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) > > Am 07.05.2010 15:13, schrieb Florian H?ch: >> >> targen -d3 -e4 -g9 -m3 I do agree 500 patches is a bit overkill... But the time it takes to measure a few extra patch is usually not that much, so I don't really see the point of measuring as few as possible patches... Is there any particularly reason why you're using -m3 instead of -f3? I think we need to trust Graeme a bit on the defaults... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Fri May 7 16:47:39 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 18:47:39 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: <4BE4442B.5060804@hoech.org> Am 07.05.2010 17:48, schrieb Pascal de Bruijn: > On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: >> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) >> >> Am 07.05.2010 15:13, schrieb Florian H?ch: >>> >>> targen -d3 -e4 -g9 -m3 > > I do agree 500 patches is a bit overkill... But the time it takes to > measure a few extra patch is usually not that much, so I don't really > see the point of measuring as few as possible patches... Well, for 'shaper+matrix' profiles, when a certain amount of patches is reached, it doesn't seem to increase the accuracy of the curves perceptibly (atleast in my experience). > Is there any particularly reason why you're using -m3 instead of -f3? > I think we need to trust Graeme a bit on the defaults... Yes, agreed (actually I didn't know those were Graeme's defaults). And the default optimized farthest point sampling is working really great for LUT-type profiles and subtractive devices like printers. But I always found that when using additive devices like screens, shaper+matrix, and decreasing the number of patches, the simpler device grid spacing seemed to work as good (also note that -f3 will only add three ofps patches, while -m3 will generate 27 device grid patches). My own testing showed negligible difference in the resulting tone curves when comparing -f500 and -g9 -m3 -f0 (see attached, and ignore the jumping dot, thats just the point I was hovering when taking the screenshots). You could always increase the amount of grayscale patches for a 'single shaper+matrix' profile if increased curve accuracy is desired, but I would go as far as saying this is probably not even neccesary in most cases. Of course, YMMV. I can only talk about the few screens I've available, which is two cheap TN (one in a laptop), a PVA and an IPS panel, and some screens of other people I've tested so far (mostly PVA, some IPS). > Regards, > Pascal de Bruijn > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list -- Florian H?ch http://hoech.net -------------- next part -------------- A non-text attachment was scrubbed... Name: TRC.gif Type: image/gif Size: 10661 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Sun May 9 00:21:26 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Sun, 9 May 2010 02:21:26 +0200 Subject: gcm-git gio dependancy Message-ID: Hi, The latest git checkout seems to require a newer version of gio than usual... /build/buildd/gnome-color-manager-2.31.2~git20100508/./configure: line 12841: GLIB_GSETTINGS: command not found checking for GLIB... configure: error: Package requirements (glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.0) were not met: Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 I'm assuming this is intentional, for GSettings? Regards, Pascal de Bruijn From hughsient at gmail.com Sun May 9 09:39:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 9 May 2010 10:39:34 +0100 Subject: gcm-git gio dependancy In-Reply-To: References: Message-ID: On 9 May 2010 01:21, Pascal de Bruijn wrote: > The latest git checkout seems to require a newer version of gio than usual... > Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 > I'm assuming this is intentional, for GSettings? Sure. As GNOME Color Manager is a proposed module for 2.31.x I've been encouraged to push the GSettings code into master for wider testing. To get a good chance of "blessed" by GNOME we need to adhere to all the goals, and one of those is GSettings. You can use gnome-2-30 if you just want to use GCM on a stable system as I'm going to be quite aggressive backporting fixes. Richard. From hughsient at gmail.com Thu May 20 11:40:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 12:40:32 +0100 Subject: Adding device profiles Message-ID: In GCM, you can currently add "virtual" devices which you manually populate the fields then assign a profile. This sucks monkey balls. What I really want is to be able to point GCM at a RAW file (or TIFF, or PNG, or JPG) and for it to read out the metadata (EXIF data) and populate those text fields for me, and then autoselecting a profile if you've got one that matches. This allows us to provide the feature on the DBus interface too. To do this, I either need to depend on exiftool (perl, ick) or exifinfo (python, ick) or I can just decode the headers myself like I'm already doing for TIFF files. Assuming I do the latter, I really need a raw decoder, and the only one that looks sane from a packaging point of view is libopenraw -- which looks pretty easy to use. I can always make this a conditional build-time dep if this is not available in all distros. So, comments? Better ideas? Richard. From pmjdebruijn at pcode.nl Thu May 20 17:12:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 20 May 2010 19:12:41 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 1:40 PM, Richard Hughes wrote: > In GCM, you can currently add "virtual" devices which you manually > populate the fields then assign a profile. This sucks monkey balls. You forgot hairy :) > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Schweet! > To do this, I either need to depend on exiftool (perl, ick) or > exifinfo (python, ick) or I can just decode the headers myself like > I'm already doing for TIFF files. Well, since Nautilus already depends on libexif12 and libexempi, those would be the obvious candidates. That way GCM won't pull in extra dependancies... > Assuming I do the latter, I really need a raw decoder, and the only > one that looks sane from a packaging point of view is libopenraw -- > which looks pretty easy to use. I can always make this a conditional > build-time dep if this is not available in all distros. Well, I could be mistaken but libopenraw is extremely unfinished and doesn't support half of the fileformats dcraw does... Again, I haven't checked it recently so I could be mistaken! Maybe LibRaw is a workable solution? Regards, Pascal de Bruijn From knizek.confy at volny.cz Thu May 20 17:44:07 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 20 May 2010 19:44:07 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: <1274377447.6560.13.camel@athlon> Richard Hughes p??e v ?t 20. 05. 2010 v 12:40 +0100: > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Will there be a provision for the situation "one camera" : "various profiles"? I usually use a single "universal" profile for my camera, however, there may be users with more variants - e.g. per type of scene light or a photo shooting session. regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 20 19:06:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 20:06:24 +0100 Subject: Adding device profiles In-Reply-To: <1274377447.6560.13.camel@athlon> References: <1274377447.6560.13.camel@athlon> Message-ID: On 20 May 2010 18:44, Milan Kn??ek wrote: > Will there be a provision for the situation "one camera" : "various > profiles"? Sure. It's already supported in the DBus API and in the configuration file, somebody (me?) has to add the required UI parts. I'm not sure what it should look like, so ideas welcome. Richard. From hughsient at gmail.com Fri May 21 08:14:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 09:14:09 +0100 Subject: Help! I need a test RAW file Message-ID: Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of course, I could just take a picture with my D60, but I really don't want to add a huge 9Mb NEF file to git master just so I can test getting metadata in make check. Does anybody know how I can export or resize a RAW file with metadata so that it's only a few pixels in size? In git I have data/test/test.{png|jpg|tif} as test cases that are only a fex pixels across and thus are a few tens of K in size. I can promise beer in return. Thanks. Richard. From liw at liw.fi Fri May 21 08:17:22 2010 From: liw at liw.fi (Lars Wirzenius) Date: Fri, 21 May 2010 20:17:22 +1200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: <1274429842.27529.216.camel@havelock> On pe, 2010-05-21 at 09:14 +0100, Richard Hughes wrote: > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? If DNG format works, that would probably be your best bet. The proprietary, undocumented formats are read-only with all the tools I know of. Not that I know of a way to generate a DNG either. From pmjdebruijn at pcode.nl Fri May 21 08:34:39 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 21 May 2010 10:34:39 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. It might be a longshot, but maybe it's an idea to contact Dave Coffin? Regards, Pascal de Bruijn From lars.tore at mulebakken.net Fri May 21 09:04:53 2010 From: lars.tore at mulebakken.net (Lars Tore Gustavsen) Date: Fri, 21 May 2010 11:04:53 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. The rawsamples site have a Kodak DC50 raw file at 91kb http://www.rawsamples.ch/index_en.php From hughsient at gmail.com Fri May 21 10:43:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 11:43:45 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 20 May 2010 18:12, Pascal de Bruijn wrote: > Well, since Nautilus already depends on libexif12 and libexempi, those > would be the obvious candidates. > > That way GCM won't pull in extra dependancies... Sure, libexif gets us jpeg files working. I've added that just now, thanks. libexempi looks less useful unless you can parse the XMP data out of the RAW files, see below... > Well, I could be mistaken but libopenraw is extremely unfinished and > doesn't support half of the fileformats dcraw does... Again, I haven't > checked it recently so I could be mistaken! Sure, I'm not so interested in the output formats, just the XMP metadata in the file. Neither libraw or libopenraw seem to be able to extract the metadata from the raw file. Rawstudio and ufraw seem to use exiv2 which is written in C++, which is less than ideal (c++ compiler needed to compile GCM...). I'm not apposed to calling an external executable for this data, but exiftool with it's huge trail of perl deps isn't really on my wishlist. Richard. From hughsient at gmail.com Fri May 21 13:35:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:35:09 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() Message-ID: Now the functionality for assigning profiles to images is nearly finished (just drag the image file onto the virtual device dialog) -- I've also added a new DBus method: GetProfilesForFile() The idea is you feed it a image filename and out pops an array of profile filenames. Typically they'll be one entry in the array, in which case applications like Shotwell and GIMP should probably use the ICC profile in the main viewer. If there is more than one item in the array, then it's up to the application whether it wants to use the default (the first entry) or show a popup asking what profile to use. For the curious, I've also added this functionality to gcm-inspect. [hughsie at hughsie-t61 src]$ ./gcm-inspect --file ../data/tests/test.jpg Suitable profiles for: ../data/tests/test.jpg 1. /home/hughsie/.color/icc/GCM - NIKON - NIKON DSC D60 - NIKON NIKON DSC D60 7457338 (2010-02-08).icc Pascal de Bruijn, NIKON - NIKON DSC D60 (2010-02-08) All code is in git master. Richard. From andy at luto.us Fri May 21 13:52:26 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:52:26 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: I don't know if this counts for the beer, but I took the most compressible picture I could think of with my D40 (the sky, on a bright sunny day here in Boston, overexposed by quite a few stops). bzip2 gets it to 13K, attached. (bzip2 beats xz -9 by a bit and gzip quite handily). --Andy On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: overexposed.NEF.bz2 Type: application/x-bzip2 Size: 13187 bytes Desc: not available URL: From andy at luto.us Fri May 21 13:56:55 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:56:55 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 9:52 AM, Andrew Lutomirski wrote: > I don't know if this counts for the beer, but I took the most > compressible picture I could think of with my D40 (the sky, on a > bright sunny day here in Boston, overexposed by quite a few stops). > > bzip2 gets it to 13K, attached. ?(bzip2 beats xz -9 by a bit and gzip > quite handily). That attachment is released under the CC0 license, available here: http://creativecommons.org/publicdomain/zero/1.0/legalcode --Andy > > --Andy > > On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: >> Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of >> course, I could just take a picture with my D60, but I really don't >> want to add a huge 9Mb NEF file to git master just so I can test >> getting metadata in make check. >> >> Does anybody know how I can export or resize a RAW file with metadata >> so that it's only a few pixels in size? In git I have >> data/test/test.{png|jpg|tif} as test cases that are only a fex pixels >> across and thus are a few tens of K in size. I can promise beer in >> return. Thanks. >> >> Richard. >> _______________________________________________ >> gnome-color-manager-list mailing list >> gnome-color-manager-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list >> > From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Sat May 22 08:42:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:42:34 +0100 Subject: GNOME Color Manager wiki Message-ID: Some of you guys may not be aware of the GCM wiki page. That's fair enough, as until yesterday the content was tiny, and the page uninteresting. So, two late night later, I present http://live.gnome.org/GnomeColorManager It's quite a bit of a brain dump, and expect more content as I get more time. Hopefully you can see from the page what we're trying to achieve and the direction GCM is going in. It's a wiki, so if you see any spelling errors or glaring omissions, just jump in an make changes. Please don't move/delete/restructure vast swathes of content without asking first. Thanks. Richard From hughsient at gmail.com Sat May 22 08:47:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:47:36 +0100 Subject: Supporting OpenIccDirectoryProposal Message-ID: OpenIccDirectoryProposal is a proposal to make the main CMMs in Linux and UNIX adhere to a common directory spec. I stumbled on it this morning, and agree with what it's trying to achieve. As such, I've committed two changes to GCM in git master (not gnome-2-30) to adhere to this spec: commit fef750d4bed38fa68d7b07b1963758f5d8d73210 Author: Richard Hughes Date: Sat May 22 08:36:09 2010 +0100 Use the common data path from OpenIccDirectoryProposal No migration is required, the old location is searched as well. :100644 100644 50f9001... 806fa26... M src/gcm-import.c :100644 100644 a0bd735... 882fc53... M src/gcm-profile-store.c :100644 100644 2760b75... 10e3367... M src/gcm-utils.c :100644 100644 3f9e5e0... 7c1c380... M src/gcm-utils.h commit 784a617285b82f4d2276cd8d7ce03d883066e10f Author: Richard Hughes Date: Sat May 22 08:24:58 2010 +0100 Use the common configuration path from OpenIccDirectoryProposal You will need to rename ~/.config/gnome-color-manager to ~/.config/color if you want to re-use your old configuration :100644 100644 2da35ed... 2760b75... M src/gcm-utils.c You can see from the last commit a rename is required if you don't want to re-assign all your profiles. I might do that automatically closer to the 2.31.2 release if there are people that file bugs, although it would be upsetting to run a GCM from a checkout which made your system GCM stop working. Maybe I can just put it in the release notes. Richard. From hughsient at gmail.com Mon May 24 07:40:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 08:40:16 +0100 Subject: Supporting OpenIccDirectoryProposal In-Reply-To: References: Message-ID: On 22 May 2010 09:47, Richard Hughes wrote: > You can see from the last commit a rename is required if you don't > want to re-assign all your profiles. I might do that automatically > closer to the 2.31.2 release if there are people that file bugs, > although it would be upsetting to run a GCM from a checkout which made > your system GCM stop working. Okay, I got sun-burnt on Sunday and had to sit inside for a few hours: commit a6c63ded454a8cde43ed9559c8b329da645e406e Author: Richard Hughes Date: Sun May 23 11:01:39 2010 +0100 Migrate the old device-profiles.conf to the new location so the user does not have to do it manually :100644 100644 ce2c1fb... b31f9bb... M data/org.gnome.color-manager.gschema.xml :100644 100644 962a7dd... 1327bae... M src/gcm-client.c :100644 100644 10e3367... 16be031... M src/gcm-utils.c :100644 100644 7c1c380... 384572f... M src/gcm-utils.h Richard. From hughsient at gmail.com Mon May 24 12:49:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 13:49:23 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 21 May 2010 11:43, Richard Hughes wrote: > Rawstudio and ufraw seem to use exiv2 which is written in C++ commit 926ecf7a8f086dd0f2f2c63b1ba0b9f3700d8cdc Author: Richard Hughes Date: Mon May 24 13:44:19 2010 +0100 Add optional exif2 support so we can get properties of RAW files too Note: This is implemented as a separate executable that is used to avoid either compiling GCM with g++ and to avoid weird linker errors on random platforms :100644 100644 4cbdaa7... 1812054... M configure.ac :100644 100644 a79decd... 08f3786... M contrib/gnome-color-manager.spec.in :100644 100644 a745113... 451b0ab... M data/tests/Makefile.am :000000 100644 0000000... 3235462... A data/tests/test.kdc :100644 100644 55d7092... ef822fc... M src/.gitignore :100644 100644 684b583... 61e0173... M src/Makefile.am :100644 100644 a985383... 532084f... M src/gcm-exif.c :000000 100644 0000000... 6385d5b... A src/gcm-helper-exiv.cpp :100644 100644 8077a4a... 587be3e... M src/gcm-self-test.c Richard. From hughsient at gmail.com Wed May 26 08:29:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 09:29:47 +0100 Subject: Multiple profile device support Message-ID: Why might we want more than one profile for a device? * A monitor has two selectable modes, sRGB and wide gamut * A printer has different profiles depending on the media and inks * A camera has different profiles depending on whether it's shot in the studio or outside What situations still require 1:1 device profile mapping: * Scanners, where nothing can be altered Now, the DBus interface and the device-profiles configuration already supports multiple profiles for each device, just not the UI. If you guys have any other use cases for more than one profile for a device then I'm interested. So, if we decide we need prefs UI to choose between studio and outside camera profiles, what should it looks like? ___________________________________ | Nikon D60 Studio (default) |#Nikon#D60#Outside################ |__________________________________ [ Make default for device ] [ Assign another profile ] [ Unassign this profile ] Or we just have the buttons [ Add ] [ Remove ] and [ Make default ] Although then we have two "Add" and "Remove" buttons on the same tab. Or do we have hypertext entries in the cellview itself: __________________________________________________________ | Nikon D60 Studio (default) | /Remove/ |#Nikon#D60#Outside#############| /Make default/, /Remove/ |_______________________________|_/Add another profile/___ Or do we just let the user drag the profiles up and down to select the order? Double click to make default? Is this discoverable enough? How do users add profiles from the existing combobox? ASCII art welcome. :-) Thanks, Richard From paul at fincc.com Wed May 26 08:57:46 2010 From: paul at fincc.com (Paul Finnigan) Date: Wed, 26 May 2010 09:57:46 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274864266.2467.11.camel@localhost> Richard On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? ... > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. I have one to think about. I am racking my tiny mind to see how this would fit in with gcm! My camera profile is associated with an image! I have a Nikon D700, I thought other Nikon cameras took similar views. Each image has a profile associated with it according to the conditions under which the photograph was taken. I agree that five or six profiles will probably cover me for most of my work. But each image has a profile built in it. Do I need this or should the application be using this as a offset to a base profile? I have to say that currently most applications appear to show colour very well, once I have gcm setup. I just thought I would ask the question as to what should happen. -- Paul Finnigan From dan at berrange.com Wed May 26 08:56:54 2010 From: dan at berrange.com (Daniel P. Berrange) Date: Wed, 26 May 2010 09:56:54 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <20100526085654.GA25454@berrange.com> On Wed, May 26, 2010 at 09:29:47AM +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut > * A printer has different profiles depending on the media and inks > * A camera has different profiles depending on whether it's shot in > the studio or outside > * A scanner can be in reflective media (paper) or transparent media (film / slides) mode. Each mode has potential for multiple profiles particularly for type of film > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. > > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ > > [ Make default for device ] > [ Assign another profile ] > [ Unassign this profile ] > > Or we just have the buttons > > [ Add ] [ Remove ] and [ Make default ] > > Although then we have two "Add" and "Remove" buttons on the same tab. > > Or do we have hypertext entries in the cellview itself: > __________________________________________________________ > | Nikon D60 Studio (default) | /Remove/ > |#Nikon#D60#Outside#############| /Make default/, /Remove/ > |_______________________________|_/Add another profile/___ > > Or do we just let the user drag the profiles up and down to select the > order? Double click to make default? Is this discoverable enough? How > do users add profiles from the existing combobox? NB, for scanners you can have 2 defaults. Since the scanner program knows whether its doing transparencies or reflective media, it will want a default profile for each mode, along with other non-default choices for each. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From hughsient at gmail.com Wed May 26 09:24:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:24:35 +0100 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On 26 May 2010 09:57, Paul Finnigan wrote: > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Right, but the GetProfilesForFile returns a list of profiles (by design) so you can easily ask GCM for the list of profiles for a specific image. > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Well, if the image has an embedded profile then we don't need to ask GCM anything. Richard. From hughsient at gmail.com Wed May 26 09:26:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:26:48 +0100 Subject: Multiple profile device support In-Reply-To: <20100526085654.GA25454@berrange.com> References: <20100526085654.GA25454@berrange.com> Message-ID: On 26 May 2010 09:56, Daniel P. Berrange wrote: > ?* A scanner can be in reflective media (paper) or transparent > ? media (film / slides) mode. Each mode has potential for multiple > ? profiles particularly for type of film Point taken. So it does make sense to have the multiple-profile / device selector for all device types. > NB, for scanners you can have 2 defaults. Since the scanner program > knows whether its doing transparencies or reflective media, it will > want a default profile for each mode, along with other non-default > choices for each. Sure, that's exactly what the "options" hint is supposed to allow. We've not specified the allowed values for the hint, although sticking in something like "transparency" should probably change the /order/ (and thus also the default) of the profiles returned. Richard. From pmjdebruijn at pcode.nl Wed May 26 15:50:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:50:41 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 10:29 AM, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut Does this actually make sense? Not really.... You profile your monitor, and then the CMS convert sRGB into the screens RGB... A display profile will always be about a display's native gamut (within a certain set of display settings). But again here, for the display settings, there is usually only way correct way to set them. > * A printer has different profiles depending on the media and inks Profiles galore! > * A camera has different profiles depending on whether it's shot in > the studio or outside Indeed... Though this is often very much exaggerated... A single profile well-made against daylight or a strobe can usually cover 80/90% of your usage scenario's, unless you're really anal retentive... > * Scanners, where nothing can be altered Think of negative/positive scanning as well, which could mean a profile per type of negative. > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ This makes very little sense! At least if I'm getting this right (big IF) :) When developing RAWs: Which profile to apply is a decision you make on-the-fly when working with a RAW converter... When printing: Which profile to apply is a decision you make on-the-fly when loading the printer with paper before printing... This could very well be per 1 sheet... When scanning: To set a generic scanner profile this make sense... but for negatives/transparancies this is something you would apply on-the-fly using the scanning tool... So I'm not sure to what extent it is useful for GCM to get involved here... Except for setting the default profile :) Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Wed May 26 15:58:03 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:58:03 +0200 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On Wed, May 26, 2010 at 10:57 AM, Paul Finnigan wrote: > Richard > > On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: >> Why might we want more than one profile for a device? > ... >> Now, the DBus interface and the device-profiles configuration already >> supports multiple profiles for each device, just not the UI. If you >> guys have any other use cases for more than one profile for a device >> then I'm interested. > > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Really? Thus far I've never seen any camera profile RAW files with embedded profiles... Or am I misunderstanding? > I have a Nikon D700, I thought other Nikon cameras took similar views. > Each image has a profile associated with it according to the conditions > under which the photograph was taken. How do you figure this? > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Please don't confuse an actual color profile, for other color post-processing options... For example I think CaptureNX actually generates ICC files on-the-fly for the processing settings selected in the app, and seems to do the full image transform in the CMS... At least as far as I heard (I never personally investigated this properly, HEARSAY WARNING). It's a pretty creative approach, though not how color management is intended nor how it should be used... If you profile your camera yourself, usually a few profiles should do very well... I tend to get by very well with only a single matrix only profile), and a decent basecurve. Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 16:02:01 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 17:02:01 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 16:50, Pascal de Bruijn wrote: > Does this actually make sense? Not really.... There are wide-gamut monitors that allow different "modes" so you artificially lower the gamut range so you don't blow your eyes when you try to view uncorrected content. It turns out HP have a large number of those monitors "in the field" so to speak, and they are quite keen on getting them to work correctly. > A single profile well-made against daylight or a strobe can usually > cover 80/90% of your usage scenario's, unless you're really anal > retentive... Sure, but people that care about color management and anally retentive people are very co-morbid :-) >> * Scanners, where nothing can be altered > > Think of negative/positive scanning as well, which could mean a > profile per type of negative. Right, makes sense. > This makes very little sense! At least if I'm getting this right (big IF) :) > > When developing RAWs: > Which profile to apply is a decision you make on-the-fly when working > with a RAW converter... Yes, that's how it used to be. The RAW converter has to be "set" manually with the ICC profile to use, which is gobbledygook that nobody will do. That's something I want to automate, see http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ for details. The idea is that the RAW converter (darktable, f-spot, whatever) calls into GCM to find out the ICC profile that should be used for each file. > When printing: > Which profile to apply is a decision you make on-the-fly when loading > the printer with paper before printing... This could very well be per > 1 sheet... Sure. The CUPS parts are very much still up in the air and are being worked on. We don't have a very good story there yet. > When scanning: > To set a generic scanner profile this make sense... but for > negatives/transparancies this is something you would apply on-the-fly > using the scanning tool... Right, but presumably one wants to be used by default? For something like simple scan we can just tell it the default profile and there is no UI to configure. > So I'm not sure to what extent it is useful for GCM to get involved > here... Except for setting the default profile :) I'm really pushing GCM into the CMM role, where the defaults are got from GCM rather than set in each and every application. Richard. From pmjdebruijn at pcode.nl Wed May 26 16:45:50 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 18:45:50 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > On 26 May 2010 16:50, Pascal de Bruijn wrote: >> Does this actually make sense? Not really.... > > There are wide-gamut monitors that allow different "modes" so you > artificially lower the gamut range so you don't blow your eyes when > you try to view uncorrected content. It turns out HP have a large > number of those monitors "in the field" so to speak, and they are > quite keen on getting them to work correctly. I actually have a HP screen, it does have an sRGB mode indeed... But this means the screen fiddles with it's internal LUT a bit to fake this... It's not really a great idea... The extra saturation because of the wide gamut usually is not that much of a problem... It's usually the high brightness combined with the extra saturation that is the problem... High brightness is usually frowned upon in color management anyways. When I turn up my brightness to 100% I need sunscreen to sit behind my screen for prolonged periods... That's why I set my brightness to a value that correlates to ~200cm/m2. >> A single profile well-made against daylight or a strobe can usually >> cover 80/90% of your usage scenario's, unless you're really anal >> retentive... > > Sure, but people that care about color management and anally retentive > people are very co-morbid :-) Hard to argue with that. >>> * Scanners, where nothing can be altered >> >> Think of negative/positive scanning as well, which could mean a >> profile per type of negative. > > Right, makes sense. > >> This makes very little sense! At least if I'm getting this right (big IF) :) >> >> When developing RAWs: >> Which profile to apply is a decision you make on-the-fly when working >> with a RAW converter... > > Yes, that's how it used to be. The RAW converter has to be "set" > manually with the ICC profile to use, which is gobbledygook that > nobody will do. That's something I want to automate, see > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > for details. And that's how it should be in the future... GCM can only help by not providing any irrelevant profiles... So if I have a 400D, it could provide 400D profiles only so if I have a 5D as well, I won't see those profiles... But GCM cannot tell whether a picture needs the "daylight" profile or the "studio" profile... Obviously this is where the default comes in... But the user still needs to be easy-able to make a last minute decision about this, without having to start gcm-prefs. > The idea is that the RAW converter (darktable, f-spot, whatever) calls > into GCM to find out the ICC profile that should be used for each > file. > >> When printing: >> Which profile to apply is a decision you make on-the-fly when loading >> the printer with paper before printing... This could very well be per >> 1 sheet... > > Sure. The CUPS parts are very much still up in the air and are being > worked on. We don't have a very good story there yet. Boatload of work... :( >> When scanning: >> To set a generic scanner profile this make sense... but for >> negatives/transparancies this is something you would apply on-the-fly >> using the scanning tool... > > Right, but presumably one wants to be used by default? For something > like simple scan we can just tell it the default profile and there is > no UI to configure. Again the scanning app doesn't know whether I'm scanning a transparancy or not... For an application like simple-scan this could be omitted because it's _not_ intended as a scanner's swiss-army-knife... But for say XSane (if anybody is still working on that, god forbid), it would still be the end-user that need to select which exact profile he needs to apply to his image... Obviously profiles for completely different scanner types could be omitted. > >> So I'm not sure to what extent it is useful for GCM to get involved >> here... Except for setting the default profile :) > > I'm really pushing GCM into the CMM role, where the defaults are got > from GCM rather than set in each and every application. That's good... Centralised defaults are VERY good :) Though there is another thing you need to keep track of... Profiles are not per-se interchangeable between different applications... For example UFRaw does not output 100% true linear RGB RAW before applying the profile... DCRAW/Darktable do at least as far as I know... Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 17:56:57 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 18:56:57 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 17:45, Pascal de Bruijn wrote: > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... Sure, I don't disagree. > That's why I set my brightness to a value that correlates to ~200cm/m2. Out of interest, how did you measure that? > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > > So if I have a 400D, it could provide 400D profiles only so if I have > a 5D as well, I won't see those profiles... Sure at the moment it matches against make, model and camera serial number. > But GCM cannot tell whether a picture needs the "daylight" profile or > the "studio" profile... Correct. In the absence of hints GCM provides both profiles, well, it actually provides the filename and the description ready formatted, so applications like GIMP can easy populate a combobox if there are more than one entry and they don't just want the default. It's the reason we have the complicated a(ss) return type so applications don't have to parse the profile themselves to get the localized description value. > Again the scanning app doesn't know whether I'm scanning a > transparancy or not... It might, cleverer HP scanners can detect what accessories they have inserted. In general I agree tho. > But for say XSane (if anybody is still working on that, god forbid), > it would still be the end-user that need to select which exact profile > he needs to apply to his image... Obviously profiles for completely > different scanner types could be omitted. At the moment GCM just sets up the XSane default profile with the default profile for the device. I know for sure it can't support more than one profile, and I also know that XSane struggles with filenames with spaces in them... > Profiles are not per-se interchangeable between different > applications... For example UFRaw does not output 100% true linear RGB > RAW before applying the profile... DCRAW/Darktable do at least as far > as I know... Surely that's a UFRaw bug then? Richard. From hughsient at gmail.com Wed May 26 19:00:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 20:00:34 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 09:29, Richard Hughes wrote: > ASCII art welcome. :-) The attached screenshot is what's in git master. Feedback welcome. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Color Management.png Type: image/png Size: 53028 bytes Desc: not available URL: From knizek.confy at volny.cz Wed May 26 18:45:31 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:45:31 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274899531.19315.33.camel@athlon> Pascal de Bruijn p??e v St 26. 05. 2010 v 18:45 +0200: > On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > > On 26 May 2010 16:50, Pascal de Bruijn wrote: > >> Does this actually make sense? Not really.... > > > > There are wide-gamut monitors that allow different "modes" so you > > artificially lower the gamut range so you don't blow your eyes when > > you try to view uncorrected content. It turns out HP have a large > > number of those monitors "in the field" so to speak, and they are > > quite keen on getting them to work correctly. > > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... > It is not a best solution, but until the complete desktop is colour managed, it is needed to have a chance to switch to sRGB emulation. Otherwise, the window decorations and images in non-colour managed apps look unrealistic. > > Yes, that's how it used to be. The RAW converter has to be "set" > > manually with the ICC profile to use, which is gobbledygook that > > nobody will do. That's something I want to automate, see > > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > > for details. > > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > I agree. GCM would not only provide a default profile for each device type (one for 5D, another for D200, etc.) but also a list of potentially usable profiles, which were previously assigned by the user for the particular device. The advantage is that the list of available profiles gets shorter. >From the work-flow viewpoint, it would be really slow to start GCM UI only to change the profile or rendering intent for a single photo. This option must be available directly in the app (RAW converter, editor). Regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From knizek at volny.cz Wed May 26 18:54:59 2010 From: knizek at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:54:59 +0200 Subject: Interoperability of GCM? Message-ID: <1274900099.19315.40.camel@athlon> Hello, since GCM is getting more into business of the central repository of ICC profiles for other applications, how does it stand from the viewpoint of interoperability between various desktop environments? I use mainly Gnome or GTK based apps (EoG, UFRaw, GIMP, CinePaint) but also digiKam (KDE) for archive management. If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers will be willing to implement support for GCM. Regards, Milan Kn??ek knizek (na) volny (te?ka) cz http://www.milan-knizek.net - O linuxu a fotografov?n? From hughsient at gmail.com Wed May 26 22:16:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 23:16:43 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274900099.19315.40.camel@athlon> References: <1274900099.19315.40.camel@athlon> Message-ID: On 26 May 2010 19:54, Milan Kn??ek wrote: > since GCM is getting more into business of the central repository of ICC > profiles for other applications, how does it stand from the viewpoint of > interoperability between various desktop environments? Well, GCM exposes a DBus interface that applications to use, rather than a shared library like other CMS solutions have tried to do. Being a DBus interface it means that applications written in any language can access the interface at runtime, rather than build time. This also means that if the interface is not available (either disabled, or just not installed) then the application can fall back to defaults or asking the user. It's like a soft run-time dep, rather than an implicit hard build-time dep. > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > will be willing to implement support for GCM. Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core access objects just depend on Glib (rather than GTK and random stuff like libnotify) so it would be very easy to write a program to expose the DBus interface without any of the other deps which applications like digiKam could use. Glib is already part of the LSB so it'll be installed on pretty much any system regardless of desktop environment. Are you worried specifically about the interface name (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) or are you just interested in discussion? :) Richard From knizek.confy at volny.cz Thu May 27 09:35:11 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 27 May 2010 11:35:11 +0200 Subject: Interoperability of GCM? In-Reply-To: References: <1274900099.19315.40.camel@athlon> Message-ID: <1274952911.3401.168.camel@athlon> Richard Hughes p??e v St 26. 05. 2010 v 23:16 +0100: > On 26 May 2010 19:54, Milan Kn??ek wrote: > > since GCM is getting more into business of the central repository of ICC > > profiles for other applications, how does it stand from the viewpoint of > > interoperability between various desktop environments? > > Well, GCM exposes a DBus interface that applications to use, rather > than a shared library like other CMS solutions have tried to do. Being > a DBus interface it means that applications written in any language > can access the interface at runtime, rather than build time. This also > means that if the interface is not available (either disabled, or just > not installed) then the application can fall back to defaults or > asking the user. It's like a soft run-time dep, rather than an > implicit hard build-time dep. > Okay, thanks for info. > > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > > will be willing to implement support for GCM. > > Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core > access objects just depend on Glib (rather than GTK and random stuff > like libnotify) so it would be very easy to write a program to expose > the DBus interface without any of the other deps which applications > like digiKam could use. Glib is already part of the LSB so it'll be > installed on pretty much any system regardless of desktop environment. > > Are you worried specifically about the interface name > (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) > or are you just interested in discussion? :) On many other forums, there is a lot of flame wars about KDE/GNOME/whatever by both users and developers and hence I assume that proposing to digiKam developers to add a DBus interface to a GNOME application could result in unnecessary refusal or at least a heated discussion. I personally do not care much and rather try to use applications which fulfil my needs. Having a standardise interface (open file dialog, etc) would be a benefit, but Linux is not there yet. I assume that a politically feasible way for digiKam would be to have a KDE GUI (equivalent to GCM GUI) above the core access objects, and org.gnome.SomeThing might make it a bit more difficult. Anyway, I guess we (users) will have to wait some time until it gets standardised and things will then settle themselves. The worst solution would be to have GCM and "KCM" running at the same moment and fighting for screen calibration... P.S. I have briefly read the OpenICC mailing list discussion recently. Best regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 27 09:44:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 27 May 2010 10:44:19 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274952911.3401.168.camel@athlon> References: <1274900099.19315.40.camel@athlon> <1274952911.3401.168.camel@athlon> Message-ID: On 27 May 2010 10:35, Milan Kn??ek wrote: > On many other forums, there is a lot of flame wars about > KDE/GNOME/whatever by both users and developers and hence I assume that > proposing to digiKam developers to add a DBus interface to a GNOME > application could result in unnecessary refusal or at least a heated > discussion. Sure. I'm not that bothered about the name of the interface I'm using. I'm not sure making the dbus interface org.hughsie.ColorManager is any more cross desktop than org.gnome.ColorManager -- but I do understand the perception. > I assume that a politically feasible way for digiKam would be to have a > KDE GUI (equivalent to GCM GUI) above the core access objects, and > org.gnome.SomeThing might make it a bit more difficult. Yes. Ideally KDE could do a simple KCM which also wrote to ~/.config/device-profiles.conf and also provided the same interface. Note: If this was a viable option, I would have no hesitation to changing the DBus name to something non-gnome and working the KDE guys to get something working. > Anyway, I guess we (users) will have to wait some time until it gets > standardised and things will then settle themselves. The worst solution > would be to have GCM and "KCM" running at the same moment and fighting > for screen calibration... Sure. GCM or the mythical KCM would only be started by the correct desktop, and if they share a same name, then the correct one would be autostarted at session login. Note, a simple KCM would probably only take a few days worth of programming to put together. Richard. From hughsient at gmail.com Fri May 28 16:59:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 28 May 2010 17:59:20 +0100 Subject: New gnome-color-manager release next Monday Message-ID: I'm planning a new release of gnome-color-manager unstable to become 2.31.2 -- if you have any translations to update and push, please do them this weekend. Any broken spelling or grammar (or anything that's just hard to translate) please email me. Thanks. Richard. From bruce at bcowan.me.uk Fri May 28 18:10:05 2010 From: bruce at bcowan.me.uk (Bruce Cowan) Date: Fri, 28 May 2010 19:10:05 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: References: Message-ID: <1275070205.4469.1.camel@Scooby-Dum> On Fri, 2010-05-28 at 17:59 +0100, Richard Hughes wrote: > I'm planning a new release of gnome-color-manager unstable to become > 2.31.2 -- if you have any translations to update and push, please do > them this weekend. > > Any broken spelling or grammar (or anything that's just hard to > translate) please email me. > > Thanks. After a rather limited review (by looking at the new strings in the en_GB translation), here's a fix: ../data/gcm-prefs.ui.h:82 "Reset the sliders to thier default values" -- Bruce Cowan From hughsient at gmail.com Sat May 29 07:27:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 29 May 2010 08:27:24 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: <1275070205.4469.1.camel@Scooby-Dum> References: <1275070205.4469.1.camel@Scooby-Dum> Message-ID: On 28 May 2010 19:10, Bruce Cowan wrote: > Reset the sliders to thier default values Fixed, thanks. Richard. From michielwittkampf at gmail.com Wed May 5 07:42:27 2010 From: michielwittkampf at gmail.com (Michiel Wittkampf) Date: Wed, 5 May 2010 09:42:27 +0200 Subject: GCM and digiKam - how to configure? Message-ID: Hi GCM developers / enthousiasts, I have a question which I could not find the answer for in fora, manuals, color management theorie, etc. Can I use GCM and digiKam succesfully on the same computer, with good colors? And how? Should I enable color management on both, or on one of them? And which suboptions? I looked at the results of switching the folowing options, but didn't figure it out. digiKam: - Enable Color Management - Use color managed view (in editor / for previews and thumbnails) GCM: - Apply display correction - (Set profile for color managed applications.) According tot the digiKam manual Xcalib / Argyll are alternatives to the option 'Use color managed view' in digiKam.* So I supose CGM is too. Yet, when using CGM's 'Apply display correction' makes the screen darker, and using digiKam? 'Use color managed view' gives a brighter picture, while using the same profile. So I am confused. Can you please help me? Greetings, Michiel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Wed May 5 08:00:03 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 5 May 2010 09:00:03 +0100 Subject: GCM and digiKam - how to configure? In-Reply-To: References: Message-ID: On 5 May 2010 08:42, Michiel Wittkampf wrote: > Can you please help me? Well, you certainly want to enable color management in digikam. This means the image source profile is used and is converted to the screen profile, as long as you set the profile for color managed applications in GCM. By setting the source profile you're really just setting a X atom on the root window which digikam can detect and use. If digikam works as a ICC profile in X compatible client, you just have to enable both options in GCM and both options in digikam. Are you using the vendor profile for our screen or are you using a calibrated generated version? Without come sort of calibration you don't know whether the lighter or darker image is the "correct" image. Richard. From hughsient at gmail.com Thu May 6 14:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 6 May 2010 15:05:36 +0100 Subject: GNOME Color Manager 2.31.1 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.1 ~~~~~~~~~~~~~~ Released: 2010-05-06 * Translations - Added Japanese translation (Ryo Fujita) - Added Punjabi Translation (A S Alam) - Added Ukrainian translation (Maxim V. Dziumanenko) - Updated British English translation (Bruce Cowan) - Updated German translation (Mario Bl?ttermann) - Updated Italian translation (Francesco Groccia) - Updated Lithuanian translation (Aurimas ?ernius) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Polish translation (Piotr Dr?g) - Updated Portuguese translation (Ant?nio Lima) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Use a new application icon (Hylke Bons) - Add an experimental gcm-picker program to read spot colors (Richard Hughes) - Show much more detail in the color picker UI and allow the user to choose a RGB colorspace (Richard Hughes) - Show the EISA ID in the devices tab. Fixes rh#581837 (Richard Hughes) * Bugfix: - Clean up the temporary file created by cupsGetPPD2(). Fixes rh#582202 (Tim Waugh) - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not explode when viewing the details of a CMYK profile (Richard Hughes) - Do not rely on an argyllcms specially patched to fix the arg[0] problem (Richard Hughes) - Don't prompt the user to calibrate the device again if we are re-using the GcmCalibrate instance (Richard Hughes) - Fix up the argyll install dialog. Fixes #616106 (Richard Hughes) - Fix up the profile precision dialog. Fixes #583398 (Richard Hughes) - Make gcm-fix-profile open the profile from memory, as then we can catch common access permission errors (Richard Hughes) - Make SANE support configurable at compile time. Fixes #616826 (Richard Hughes) - Offer to install shared-color-profiles-extra if it is not yet installed (Richard Hughes) Richard. From lists+gnome-color-manager at hoech.org Fri May 7 13:13:41 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:13:41 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: Message-ID: <4BE41205.6080301@hoech.org> Hi, recently I switched from the proprietary nvidia driver to noveau, so I could try the latest GCM :) I noticed that for screen calibration, always a quality of 'low' is used and a shaper+matrix profile is created from varying colorpatch amounts and quality parameter. Looking at the code, the 100-500 colorpatches used for the screen profiling really seem overkill for a simple matrix profile. So the first thing I'd suggest, is to always use a lower, fixed-amount colorpatch set: targen -d3 -e4 -g9 -m3, this yields 36 patches that most other profilers out there also seem to use and should give very good results with matrix profiles (of course YMMV, but imho it would be a good default. This is what I use in dispcalGUI atm). Then, I'd suggest colprof -qh for matrix profiles (lower quality levels will smooth the trc curves more, but I think high quality could model the device response more accurately). This shouldn't come at any speed penalty at the new low suggested colorpatch count. And, as GCM always does a calibration+profile, I'd use colprof -aS (single shaper+matrix) instead of -as (per channel shaper+matrix), as we can rely on the calibration already having established gray balance, thus no need to risk the per channel curves introducing banding or shimmering. These changes would remove the need for the current three profile 'precision' choices for screen calibration/profiling, so the last suggestion from me is to instead present the user with a choice for the calibration (dispcal) quality instead, or to get rid of the choice altogether (only for screen calibration/profiling ofcourse). What do you think? Am 06.05.2010 16:05, schrieb Richard Hughes: > 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.1 Regards -- Florian H?ch http://hoech.net From lists+gnome-color-manager at hoech.org Fri May 7 13:36:12 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:36:12 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE4174C.1050903@hoech.org> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From lists at hoech.net Fri May 7 13:33:36 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:33:36 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE416B0.6050309@hoech.net> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From pmjdebruijn at pcode.nl Fri May 7 15:48:54 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 7 May 2010 17:48:54 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE416B0.6050309@hoech.net> References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: > (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) > > Am 07.05.2010 15:13, schrieb Florian H?ch: >> >> targen -d3 -e4 -g9 -m3 I do agree 500 patches is a bit overkill... But the time it takes to measure a few extra patch is usually not that much, so I don't really see the point of measuring as few as possible patches... Is there any particularly reason why you're using -m3 instead of -f3? I think we need to trust Graeme a bit on the defaults... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Fri May 7 16:47:39 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 18:47:39 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: <4BE4442B.5060804@hoech.org> Am 07.05.2010 17:48, schrieb Pascal de Bruijn: > On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: >> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) >> >> Am 07.05.2010 15:13, schrieb Florian H?ch: >>> >>> targen -d3 -e4 -g9 -m3 > > I do agree 500 patches is a bit overkill... But the time it takes to > measure a few extra patch is usually not that much, so I don't really > see the point of measuring as few as possible patches... Well, for 'shaper+matrix' profiles, when a certain amount of patches is reached, it doesn't seem to increase the accuracy of the curves perceptibly (atleast in my experience). > Is there any particularly reason why you're using -m3 instead of -f3? > I think we need to trust Graeme a bit on the defaults... Yes, agreed (actually I didn't know those were Graeme's defaults). And the default optimized farthest point sampling is working really great for LUT-type profiles and subtractive devices like printers. But I always found that when using additive devices like screens, shaper+matrix, and decreasing the number of patches, the simpler device grid spacing seemed to work as good (also note that -f3 will only add three ofps patches, while -m3 will generate 27 device grid patches). My own testing showed negligible difference in the resulting tone curves when comparing -f500 and -g9 -m3 -f0 (see attached, and ignore the jumping dot, thats just the point I was hovering when taking the screenshots). You could always increase the amount of grayscale patches for a 'single shaper+matrix' profile if increased curve accuracy is desired, but I would go as far as saying this is probably not even neccesary in most cases. Of course, YMMV. I can only talk about the few screens I've available, which is two cheap TN (one in a laptop), a PVA and an IPS panel, and some screens of other people I've tested so far (mostly PVA, some IPS). > Regards, > Pascal de Bruijn > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list -- Florian H?ch http://hoech.net -------------- next part -------------- A non-text attachment was scrubbed... Name: TRC.gif Type: image/gif Size: 10661 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Sun May 9 00:21:26 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Sun, 9 May 2010 02:21:26 +0200 Subject: gcm-git gio dependancy Message-ID: Hi, The latest git checkout seems to require a newer version of gio than usual... /build/buildd/gnome-color-manager-2.31.2~git20100508/./configure: line 12841: GLIB_GSETTINGS: command not found checking for GLIB... configure: error: Package requirements (glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.0) were not met: Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 I'm assuming this is intentional, for GSettings? Regards, Pascal de Bruijn From hughsient at gmail.com Sun May 9 09:39:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 9 May 2010 10:39:34 +0100 Subject: gcm-git gio dependancy In-Reply-To: References: Message-ID: On 9 May 2010 01:21, Pascal de Bruijn wrote: > The latest git checkout seems to require a newer version of gio than usual... > Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 > I'm assuming this is intentional, for GSettings? Sure. As GNOME Color Manager is a proposed module for 2.31.x I've been encouraged to push the GSettings code into master for wider testing. To get a good chance of "blessed" by GNOME we need to adhere to all the goals, and one of those is GSettings. You can use gnome-2-30 if you just want to use GCM on a stable system as I'm going to be quite aggressive backporting fixes. Richard. From hughsient at gmail.com Thu May 20 11:40:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 12:40:32 +0100 Subject: Adding device profiles Message-ID: In GCM, you can currently add "virtual" devices which you manually populate the fields then assign a profile. This sucks monkey balls. What I really want is to be able to point GCM at a RAW file (or TIFF, or PNG, or JPG) and for it to read out the metadata (EXIF data) and populate those text fields for me, and then autoselecting a profile if you've got one that matches. This allows us to provide the feature on the DBus interface too. To do this, I either need to depend on exiftool (perl, ick) or exifinfo (python, ick) or I can just decode the headers myself like I'm already doing for TIFF files. Assuming I do the latter, I really need a raw decoder, and the only one that looks sane from a packaging point of view is libopenraw -- which looks pretty easy to use. I can always make this a conditional build-time dep if this is not available in all distros. So, comments? Better ideas? Richard. From pmjdebruijn at pcode.nl Thu May 20 17:12:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 20 May 2010 19:12:41 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 1:40 PM, Richard Hughes wrote: > In GCM, you can currently add "virtual" devices which you manually > populate the fields then assign a profile. This sucks monkey balls. You forgot hairy :) > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Schweet! > To do this, I either need to depend on exiftool (perl, ick) or > exifinfo (python, ick) or I can just decode the headers myself like > I'm already doing for TIFF files. Well, since Nautilus already depends on libexif12 and libexempi, those would be the obvious candidates. That way GCM won't pull in extra dependancies... > Assuming I do the latter, I really need a raw decoder, and the only > one that looks sane from a packaging point of view is libopenraw -- > which looks pretty easy to use. I can always make this a conditional > build-time dep if this is not available in all distros. Well, I could be mistaken but libopenraw is extremely unfinished and doesn't support half of the fileformats dcraw does... Again, I haven't checked it recently so I could be mistaken! Maybe LibRaw is a workable solution? Regards, Pascal de Bruijn From knizek.confy at volny.cz Thu May 20 17:44:07 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 20 May 2010 19:44:07 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: <1274377447.6560.13.camel@athlon> Richard Hughes p??e v ?t 20. 05. 2010 v 12:40 +0100: > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Will there be a provision for the situation "one camera" : "various profiles"? I usually use a single "universal" profile for my camera, however, there may be users with more variants - e.g. per type of scene light or a photo shooting session. regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 20 19:06:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 20:06:24 +0100 Subject: Adding device profiles In-Reply-To: <1274377447.6560.13.camel@athlon> References: <1274377447.6560.13.camel@athlon> Message-ID: On 20 May 2010 18:44, Milan Kn??ek wrote: > Will there be a provision for the situation "one camera" : "various > profiles"? Sure. It's already supported in the DBus API and in the configuration file, somebody (me?) has to add the required UI parts. I'm not sure what it should look like, so ideas welcome. Richard. From hughsient at gmail.com Fri May 21 08:14:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 09:14:09 +0100 Subject: Help! I need a test RAW file Message-ID: Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of course, I could just take a picture with my D60, but I really don't want to add a huge 9Mb NEF file to git master just so I can test getting metadata in make check. Does anybody know how I can export or resize a RAW file with metadata so that it's only a few pixels in size? In git I have data/test/test.{png|jpg|tif} as test cases that are only a fex pixels across and thus are a few tens of K in size. I can promise beer in return. Thanks. Richard. From liw at liw.fi Fri May 21 08:17:22 2010 From: liw at liw.fi (Lars Wirzenius) Date: Fri, 21 May 2010 20:17:22 +1200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: <1274429842.27529.216.camel@havelock> On pe, 2010-05-21 at 09:14 +0100, Richard Hughes wrote: > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? If DNG format works, that would probably be your best bet. The proprietary, undocumented formats are read-only with all the tools I know of. Not that I know of a way to generate a DNG either. From pmjdebruijn at pcode.nl Fri May 21 08:34:39 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 21 May 2010 10:34:39 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. It might be a longshot, but maybe it's an idea to contact Dave Coffin? Regards, Pascal de Bruijn From lars.tore at mulebakken.net Fri May 21 09:04:53 2010 From: lars.tore at mulebakken.net (Lars Tore Gustavsen) Date: Fri, 21 May 2010 11:04:53 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. The rawsamples site have a Kodak DC50 raw file at 91kb http://www.rawsamples.ch/index_en.php From hughsient at gmail.com Fri May 21 10:43:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 11:43:45 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 20 May 2010 18:12, Pascal de Bruijn wrote: > Well, since Nautilus already depends on libexif12 and libexempi, those > would be the obvious candidates. > > That way GCM won't pull in extra dependancies... Sure, libexif gets us jpeg files working. I've added that just now, thanks. libexempi looks less useful unless you can parse the XMP data out of the RAW files, see below... > Well, I could be mistaken but libopenraw is extremely unfinished and > doesn't support half of the fileformats dcraw does... Again, I haven't > checked it recently so I could be mistaken! Sure, I'm not so interested in the output formats, just the XMP metadata in the file. Neither libraw or libopenraw seem to be able to extract the metadata from the raw file. Rawstudio and ufraw seem to use exiv2 which is written in C++, which is less than ideal (c++ compiler needed to compile GCM...). I'm not apposed to calling an external executable for this data, but exiftool with it's huge trail of perl deps isn't really on my wishlist. Richard. From hughsient at gmail.com Fri May 21 13:35:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:35:09 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() Message-ID: Now the functionality for assigning profiles to images is nearly finished (just drag the image file onto the virtual device dialog) -- I've also added a new DBus method: GetProfilesForFile() The idea is you feed it a image filename and out pops an array of profile filenames. Typically they'll be one entry in the array, in which case applications like Shotwell and GIMP should probably use the ICC profile in the main viewer. If there is more than one item in the array, then it's up to the application whether it wants to use the default (the first entry) or show a popup asking what profile to use. For the curious, I've also added this functionality to gcm-inspect. [hughsie at hughsie-t61 src]$ ./gcm-inspect --file ../data/tests/test.jpg Suitable profiles for: ../data/tests/test.jpg 1. /home/hughsie/.color/icc/GCM - NIKON - NIKON DSC D60 - NIKON NIKON DSC D60 7457338 (2010-02-08).icc Pascal de Bruijn, NIKON - NIKON DSC D60 (2010-02-08) All code is in git master. Richard. From andy at luto.us Fri May 21 13:52:26 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:52:26 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: I don't know if this counts for the beer, but I took the most compressible picture I could think of with my D40 (the sky, on a bright sunny day here in Boston, overexposed by quite a few stops). bzip2 gets it to 13K, attached. (bzip2 beats xz -9 by a bit and gzip quite handily). --Andy On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: overexposed.NEF.bz2 Type: application/x-bzip2 Size: 13187 bytes Desc: not available URL: From andy at luto.us Fri May 21 13:56:55 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:56:55 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 9:52 AM, Andrew Lutomirski wrote: > I don't know if this counts for the beer, but I took the most > compressible picture I could think of with my D40 (the sky, on a > bright sunny day here in Boston, overexposed by quite a few stops). > > bzip2 gets it to 13K, attached. ?(bzip2 beats xz -9 by a bit and gzip > quite handily). That attachment is released under the CC0 license, available here: http://creativecommons.org/publicdomain/zero/1.0/legalcode --Andy > > --Andy > > On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: >> Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of >> course, I could just take a picture with my D60, but I really don't >> want to add a huge 9Mb NEF file to git master just so I can test >> getting metadata in make check. >> >> Does anybody know how I can export or resize a RAW file with metadata >> so that it's only a few pixels in size? In git I have >> data/test/test.{png|jpg|tif} as test cases that are only a fex pixels >> across and thus are a few tens of K in size. I can promise beer in >> return. Thanks. >> >> Richard. >> _______________________________________________ >> gnome-color-manager-list mailing list >> gnome-color-manager-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list >> > From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Sat May 22 08:42:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:42:34 +0100 Subject: GNOME Color Manager wiki Message-ID: Some of you guys may not be aware of the GCM wiki page. That's fair enough, as until yesterday the content was tiny, and the page uninteresting. So, two late night later, I present http://live.gnome.org/GnomeColorManager It's quite a bit of a brain dump, and expect more content as I get more time. Hopefully you can see from the page what we're trying to achieve and the direction GCM is going in. It's a wiki, so if you see any spelling errors or glaring omissions, just jump in an make changes. Please don't move/delete/restructure vast swathes of content without asking first. Thanks. Richard From hughsient at gmail.com Sat May 22 08:47:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:47:36 +0100 Subject: Supporting OpenIccDirectoryProposal Message-ID: OpenIccDirectoryProposal is a proposal to make the main CMMs in Linux and UNIX adhere to a common directory spec. I stumbled on it this morning, and agree with what it's trying to achieve. As such, I've committed two changes to GCM in git master (not gnome-2-30) to adhere to this spec: commit fef750d4bed38fa68d7b07b1963758f5d8d73210 Author: Richard Hughes Date: Sat May 22 08:36:09 2010 +0100 Use the common data path from OpenIccDirectoryProposal No migration is required, the old location is searched as well. :100644 100644 50f9001... 806fa26... M src/gcm-import.c :100644 100644 a0bd735... 882fc53... M src/gcm-profile-store.c :100644 100644 2760b75... 10e3367... M src/gcm-utils.c :100644 100644 3f9e5e0... 7c1c380... M src/gcm-utils.h commit 784a617285b82f4d2276cd8d7ce03d883066e10f Author: Richard Hughes Date: Sat May 22 08:24:58 2010 +0100 Use the common configuration path from OpenIccDirectoryProposal You will need to rename ~/.config/gnome-color-manager to ~/.config/color if you want to re-use your old configuration :100644 100644 2da35ed... 2760b75... M src/gcm-utils.c You can see from the last commit a rename is required if you don't want to re-assign all your profiles. I might do that automatically closer to the 2.31.2 release if there are people that file bugs, although it would be upsetting to run a GCM from a checkout which made your system GCM stop working. Maybe I can just put it in the release notes. Richard. From hughsient at gmail.com Mon May 24 07:40:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 08:40:16 +0100 Subject: Supporting OpenIccDirectoryProposal In-Reply-To: References: Message-ID: On 22 May 2010 09:47, Richard Hughes wrote: > You can see from the last commit a rename is required if you don't > want to re-assign all your profiles. I might do that automatically > closer to the 2.31.2 release if there are people that file bugs, > although it would be upsetting to run a GCM from a checkout which made > your system GCM stop working. Okay, I got sun-burnt on Sunday and had to sit inside for a few hours: commit a6c63ded454a8cde43ed9559c8b329da645e406e Author: Richard Hughes Date: Sun May 23 11:01:39 2010 +0100 Migrate the old device-profiles.conf to the new location so the user does not have to do it manually :100644 100644 ce2c1fb... b31f9bb... M data/org.gnome.color-manager.gschema.xml :100644 100644 962a7dd... 1327bae... M src/gcm-client.c :100644 100644 10e3367... 16be031... M src/gcm-utils.c :100644 100644 7c1c380... 384572f... M src/gcm-utils.h Richard. From hughsient at gmail.com Mon May 24 12:49:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 13:49:23 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 21 May 2010 11:43, Richard Hughes wrote: > Rawstudio and ufraw seem to use exiv2 which is written in C++ commit 926ecf7a8f086dd0f2f2c63b1ba0b9f3700d8cdc Author: Richard Hughes Date: Mon May 24 13:44:19 2010 +0100 Add optional exif2 support so we can get properties of RAW files too Note: This is implemented as a separate executable that is used to avoid either compiling GCM with g++ and to avoid weird linker errors on random platforms :100644 100644 4cbdaa7... 1812054... M configure.ac :100644 100644 a79decd... 08f3786... M contrib/gnome-color-manager.spec.in :100644 100644 a745113... 451b0ab... M data/tests/Makefile.am :000000 100644 0000000... 3235462... A data/tests/test.kdc :100644 100644 55d7092... ef822fc... M src/.gitignore :100644 100644 684b583... 61e0173... M src/Makefile.am :100644 100644 a985383... 532084f... M src/gcm-exif.c :000000 100644 0000000... 6385d5b... A src/gcm-helper-exiv.cpp :100644 100644 8077a4a... 587be3e... M src/gcm-self-test.c Richard. From hughsient at gmail.com Wed May 26 08:29:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 09:29:47 +0100 Subject: Multiple profile device support Message-ID: Why might we want more than one profile for a device? * A monitor has two selectable modes, sRGB and wide gamut * A printer has different profiles depending on the media and inks * A camera has different profiles depending on whether it's shot in the studio or outside What situations still require 1:1 device profile mapping: * Scanners, where nothing can be altered Now, the DBus interface and the device-profiles configuration already supports multiple profiles for each device, just not the UI. If you guys have any other use cases for more than one profile for a device then I'm interested. So, if we decide we need prefs UI to choose between studio and outside camera profiles, what should it looks like? ___________________________________ | Nikon D60 Studio (default) |#Nikon#D60#Outside################ |__________________________________ [ Make default for device ] [ Assign another profile ] [ Unassign this profile ] Or we just have the buttons [ Add ] [ Remove ] and [ Make default ] Although then we have two "Add" and "Remove" buttons on the same tab. Or do we have hypertext entries in the cellview itself: __________________________________________________________ | Nikon D60 Studio (default) | /Remove/ |#Nikon#D60#Outside#############| /Make default/, /Remove/ |_______________________________|_/Add another profile/___ Or do we just let the user drag the profiles up and down to select the order? Double click to make default? Is this discoverable enough? How do users add profiles from the existing combobox? ASCII art welcome. :-) Thanks, Richard From paul at fincc.com Wed May 26 08:57:46 2010 From: paul at fincc.com (Paul Finnigan) Date: Wed, 26 May 2010 09:57:46 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274864266.2467.11.camel@localhost> Richard On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? ... > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. I have one to think about. I am racking my tiny mind to see how this would fit in with gcm! My camera profile is associated with an image! I have a Nikon D700, I thought other Nikon cameras took similar views. Each image has a profile associated with it according to the conditions under which the photograph was taken. I agree that five or six profiles will probably cover me for most of my work. But each image has a profile built in it. Do I need this or should the application be using this as a offset to a base profile? I have to say that currently most applications appear to show colour very well, once I have gcm setup. I just thought I would ask the question as to what should happen. -- Paul Finnigan From dan at berrange.com Wed May 26 08:56:54 2010 From: dan at berrange.com (Daniel P. Berrange) Date: Wed, 26 May 2010 09:56:54 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <20100526085654.GA25454@berrange.com> On Wed, May 26, 2010 at 09:29:47AM +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut > * A printer has different profiles depending on the media and inks > * A camera has different profiles depending on whether it's shot in > the studio or outside > * A scanner can be in reflective media (paper) or transparent media (film / slides) mode. Each mode has potential for multiple profiles particularly for type of film > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. > > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ > > [ Make default for device ] > [ Assign another profile ] > [ Unassign this profile ] > > Or we just have the buttons > > [ Add ] [ Remove ] and [ Make default ] > > Although then we have two "Add" and "Remove" buttons on the same tab. > > Or do we have hypertext entries in the cellview itself: > __________________________________________________________ > | Nikon D60 Studio (default) | /Remove/ > |#Nikon#D60#Outside#############| /Make default/, /Remove/ > |_______________________________|_/Add another profile/___ > > Or do we just let the user drag the profiles up and down to select the > order? Double click to make default? Is this discoverable enough? How > do users add profiles from the existing combobox? NB, for scanners you can have 2 defaults. Since the scanner program knows whether its doing transparencies or reflective media, it will want a default profile for each mode, along with other non-default choices for each. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From hughsient at gmail.com Wed May 26 09:24:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:24:35 +0100 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On 26 May 2010 09:57, Paul Finnigan wrote: > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Right, but the GetProfilesForFile returns a list of profiles (by design) so you can easily ask GCM for the list of profiles for a specific image. > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Well, if the image has an embedded profile then we don't need to ask GCM anything. Richard. From hughsient at gmail.com Wed May 26 09:26:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:26:48 +0100 Subject: Multiple profile device support In-Reply-To: <20100526085654.GA25454@berrange.com> References: <20100526085654.GA25454@berrange.com> Message-ID: On 26 May 2010 09:56, Daniel P. Berrange wrote: > ?* A scanner can be in reflective media (paper) or transparent > ? media (film / slides) mode. Each mode has potential for multiple > ? profiles particularly for type of film Point taken. So it does make sense to have the multiple-profile / device selector for all device types. > NB, for scanners you can have 2 defaults. Since the scanner program > knows whether its doing transparencies or reflective media, it will > want a default profile for each mode, along with other non-default > choices for each. Sure, that's exactly what the "options" hint is supposed to allow. We've not specified the allowed values for the hint, although sticking in something like "transparency" should probably change the /order/ (and thus also the default) of the profiles returned. Richard. From pmjdebruijn at pcode.nl Wed May 26 15:50:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:50:41 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 10:29 AM, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut Does this actually make sense? Not really.... You profile your monitor, and then the CMS convert sRGB into the screens RGB... A display profile will always be about a display's native gamut (within a certain set of display settings). But again here, for the display settings, there is usually only way correct way to set them. > * A printer has different profiles depending on the media and inks Profiles galore! > * A camera has different profiles depending on whether it's shot in > the studio or outside Indeed... Though this is often very much exaggerated... A single profile well-made against daylight or a strobe can usually cover 80/90% of your usage scenario's, unless you're really anal retentive... > * Scanners, where nothing can be altered Think of negative/positive scanning as well, which could mean a profile per type of negative. > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ This makes very little sense! At least if I'm getting this right (big IF) :) When developing RAWs: Which profile to apply is a decision you make on-the-fly when working with a RAW converter... When printing: Which profile to apply is a decision you make on-the-fly when loading the printer with paper before printing... This could very well be per 1 sheet... When scanning: To set a generic scanner profile this make sense... but for negatives/transparancies this is something you would apply on-the-fly using the scanning tool... So I'm not sure to what extent it is useful for GCM to get involved here... Except for setting the default profile :) Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Wed May 26 15:58:03 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:58:03 +0200 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On Wed, May 26, 2010 at 10:57 AM, Paul Finnigan wrote: > Richard > > On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: >> Why might we want more than one profile for a device? > ... >> Now, the DBus interface and the device-profiles configuration already >> supports multiple profiles for each device, just not the UI. If you >> guys have any other use cases for more than one profile for a device >> then I'm interested. > > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Really? Thus far I've never seen any camera profile RAW files with embedded profiles... Or am I misunderstanding? > I have a Nikon D700, I thought other Nikon cameras took similar views. > Each image has a profile associated with it according to the conditions > under which the photograph was taken. How do you figure this? > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Please don't confuse an actual color profile, for other color post-processing options... For example I think CaptureNX actually generates ICC files on-the-fly for the processing settings selected in the app, and seems to do the full image transform in the CMS... At least as far as I heard (I never personally investigated this properly, HEARSAY WARNING). It's a pretty creative approach, though not how color management is intended nor how it should be used... If you profile your camera yourself, usually a few profiles should do very well... I tend to get by very well with only a single matrix only profile), and a decent basecurve. Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 16:02:01 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 17:02:01 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 16:50, Pascal de Bruijn wrote: > Does this actually make sense? Not really.... There are wide-gamut monitors that allow different "modes" so you artificially lower the gamut range so you don't blow your eyes when you try to view uncorrected content. It turns out HP have a large number of those monitors "in the field" so to speak, and they are quite keen on getting them to work correctly. > A single profile well-made against daylight or a strobe can usually > cover 80/90% of your usage scenario's, unless you're really anal > retentive... Sure, but people that care about color management and anally retentive people are very co-morbid :-) >> * Scanners, where nothing can be altered > > Think of negative/positive scanning as well, which could mean a > profile per type of negative. Right, makes sense. > This makes very little sense! At least if I'm getting this right (big IF) :) > > When developing RAWs: > Which profile to apply is a decision you make on-the-fly when working > with a RAW converter... Yes, that's how it used to be. The RAW converter has to be "set" manually with the ICC profile to use, which is gobbledygook that nobody will do. That's something I want to automate, see http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ for details. The idea is that the RAW converter (darktable, f-spot, whatever) calls into GCM to find out the ICC profile that should be used for each file. > When printing: > Which profile to apply is a decision you make on-the-fly when loading > the printer with paper before printing... This could very well be per > 1 sheet... Sure. The CUPS parts are very much still up in the air and are being worked on. We don't have a very good story there yet. > When scanning: > To set a generic scanner profile this make sense... but for > negatives/transparancies this is something you would apply on-the-fly > using the scanning tool... Right, but presumably one wants to be used by default? For something like simple scan we can just tell it the default profile and there is no UI to configure. > So I'm not sure to what extent it is useful for GCM to get involved > here... Except for setting the default profile :) I'm really pushing GCM into the CMM role, where the defaults are got from GCM rather than set in each and every application. Richard. From pmjdebruijn at pcode.nl Wed May 26 16:45:50 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 18:45:50 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > On 26 May 2010 16:50, Pascal de Bruijn wrote: >> Does this actually make sense? Not really.... > > There are wide-gamut monitors that allow different "modes" so you > artificially lower the gamut range so you don't blow your eyes when > you try to view uncorrected content. It turns out HP have a large > number of those monitors "in the field" so to speak, and they are > quite keen on getting them to work correctly. I actually have a HP screen, it does have an sRGB mode indeed... But this means the screen fiddles with it's internal LUT a bit to fake this... It's not really a great idea... The extra saturation because of the wide gamut usually is not that much of a problem... It's usually the high brightness combined with the extra saturation that is the problem... High brightness is usually frowned upon in color management anyways. When I turn up my brightness to 100% I need sunscreen to sit behind my screen for prolonged periods... That's why I set my brightness to a value that correlates to ~200cm/m2. >> A single profile well-made against daylight or a strobe can usually >> cover 80/90% of your usage scenario's, unless you're really anal >> retentive... > > Sure, but people that care about color management and anally retentive > people are very co-morbid :-) Hard to argue with that. >>> * Scanners, where nothing can be altered >> >> Think of negative/positive scanning as well, which could mean a >> profile per type of negative. > > Right, makes sense. > >> This makes very little sense! At least if I'm getting this right (big IF) :) >> >> When developing RAWs: >> Which profile to apply is a decision you make on-the-fly when working >> with a RAW converter... > > Yes, that's how it used to be. The RAW converter has to be "set" > manually with the ICC profile to use, which is gobbledygook that > nobody will do. That's something I want to automate, see > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > for details. And that's how it should be in the future... GCM can only help by not providing any irrelevant profiles... So if I have a 400D, it could provide 400D profiles only so if I have a 5D as well, I won't see those profiles... But GCM cannot tell whether a picture needs the "daylight" profile or the "studio" profile... Obviously this is where the default comes in... But the user still needs to be easy-able to make a last minute decision about this, without having to start gcm-prefs. > The idea is that the RAW converter (darktable, f-spot, whatever) calls > into GCM to find out the ICC profile that should be used for each > file. > >> When printing: >> Which profile to apply is a decision you make on-the-fly when loading >> the printer with paper before printing... This could very well be per >> 1 sheet... > > Sure. The CUPS parts are very much still up in the air and are being > worked on. We don't have a very good story there yet. Boatload of work... :( >> When scanning: >> To set a generic scanner profile this make sense... but for >> negatives/transparancies this is something you would apply on-the-fly >> using the scanning tool... > > Right, but presumably one wants to be used by default? For something > like simple scan we can just tell it the default profile and there is > no UI to configure. Again the scanning app doesn't know whether I'm scanning a transparancy or not... For an application like simple-scan this could be omitted because it's _not_ intended as a scanner's swiss-army-knife... But for say XSane (if anybody is still working on that, god forbid), it would still be the end-user that need to select which exact profile he needs to apply to his image... Obviously profiles for completely different scanner types could be omitted. > >> So I'm not sure to what extent it is useful for GCM to get involved >> here... Except for setting the default profile :) > > I'm really pushing GCM into the CMM role, where the defaults are got > from GCM rather than set in each and every application. That's good... Centralised defaults are VERY good :) Though there is another thing you need to keep track of... Profiles are not per-se interchangeable between different applications... For example UFRaw does not output 100% true linear RGB RAW before applying the profile... DCRAW/Darktable do at least as far as I know... Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 17:56:57 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 18:56:57 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 17:45, Pascal de Bruijn wrote: > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... Sure, I don't disagree. > That's why I set my brightness to a value that correlates to ~200cm/m2. Out of interest, how did you measure that? > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > > So if I have a 400D, it could provide 400D profiles only so if I have > a 5D as well, I won't see those profiles... Sure at the moment it matches against make, model and camera serial number. > But GCM cannot tell whether a picture needs the "daylight" profile or > the "studio" profile... Correct. In the absence of hints GCM provides both profiles, well, it actually provides the filename and the description ready formatted, so applications like GIMP can easy populate a combobox if there are more than one entry and they don't just want the default. It's the reason we have the complicated a(ss) return type so applications don't have to parse the profile themselves to get the localized description value. > Again the scanning app doesn't know whether I'm scanning a > transparancy or not... It might, cleverer HP scanners can detect what accessories they have inserted. In general I agree tho. > But for say XSane (if anybody is still working on that, god forbid), > it would still be the end-user that need to select which exact profile > he needs to apply to his image... Obviously profiles for completely > different scanner types could be omitted. At the moment GCM just sets up the XSane default profile with the default profile for the device. I know for sure it can't support more than one profile, and I also know that XSane struggles with filenames with spaces in them... > Profiles are not per-se interchangeable between different > applications... For example UFRaw does not output 100% true linear RGB > RAW before applying the profile... DCRAW/Darktable do at least as far > as I know... Surely that's a UFRaw bug then? Richard. From hughsient at gmail.com Wed May 26 19:00:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 20:00:34 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 09:29, Richard Hughes wrote: > ASCII art welcome. :-) The attached screenshot is what's in git master. Feedback welcome. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Color Management.png Type: image/png Size: 53028 bytes Desc: not available URL: From knizek.confy at volny.cz Wed May 26 18:45:31 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:45:31 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274899531.19315.33.camel@athlon> Pascal de Bruijn p??e v St 26. 05. 2010 v 18:45 +0200: > On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > > On 26 May 2010 16:50, Pascal de Bruijn wrote: > >> Does this actually make sense? Not really.... > > > > There are wide-gamut monitors that allow different "modes" so you > > artificially lower the gamut range so you don't blow your eyes when > > you try to view uncorrected content. It turns out HP have a large > > number of those monitors "in the field" so to speak, and they are > > quite keen on getting them to work correctly. > > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... > It is not a best solution, but until the complete desktop is colour managed, it is needed to have a chance to switch to sRGB emulation. Otherwise, the window decorations and images in non-colour managed apps look unrealistic. > > Yes, that's how it used to be. The RAW converter has to be "set" > > manually with the ICC profile to use, which is gobbledygook that > > nobody will do. That's something I want to automate, see > > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > > for details. > > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > I agree. GCM would not only provide a default profile for each device type (one for 5D, another for D200, etc.) but also a list of potentially usable profiles, which were previously assigned by the user for the particular device. The advantage is that the list of available profiles gets shorter. >From the work-flow viewpoint, it would be really slow to start GCM UI only to change the profile or rendering intent for a single photo. This option must be available directly in the app (RAW converter, editor). Regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From knizek at volny.cz Wed May 26 18:54:59 2010 From: knizek at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:54:59 +0200 Subject: Interoperability of GCM? Message-ID: <1274900099.19315.40.camel@athlon> Hello, since GCM is getting more into business of the central repository of ICC profiles for other applications, how does it stand from the viewpoint of interoperability between various desktop environments? I use mainly Gnome or GTK based apps (EoG, UFRaw, GIMP, CinePaint) but also digiKam (KDE) for archive management. If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers will be willing to implement support for GCM. Regards, Milan Kn??ek knizek (na) volny (te?ka) cz http://www.milan-knizek.net - O linuxu a fotografov?n? From hughsient at gmail.com Wed May 26 22:16:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 23:16:43 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274900099.19315.40.camel@athlon> References: <1274900099.19315.40.camel@athlon> Message-ID: On 26 May 2010 19:54, Milan Kn??ek wrote: > since GCM is getting more into business of the central repository of ICC > profiles for other applications, how does it stand from the viewpoint of > interoperability between various desktop environments? Well, GCM exposes a DBus interface that applications to use, rather than a shared library like other CMS solutions have tried to do. Being a DBus interface it means that applications written in any language can access the interface at runtime, rather than build time. This also means that if the interface is not available (either disabled, or just not installed) then the application can fall back to defaults or asking the user. It's like a soft run-time dep, rather than an implicit hard build-time dep. > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > will be willing to implement support for GCM. Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core access objects just depend on Glib (rather than GTK and random stuff like libnotify) so it would be very easy to write a program to expose the DBus interface without any of the other deps which applications like digiKam could use. Glib is already part of the LSB so it'll be installed on pretty much any system regardless of desktop environment. Are you worried specifically about the interface name (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) or are you just interested in discussion? :) Richard From knizek.confy at volny.cz Thu May 27 09:35:11 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 27 May 2010 11:35:11 +0200 Subject: Interoperability of GCM? In-Reply-To: References: <1274900099.19315.40.camel@athlon> Message-ID: <1274952911.3401.168.camel@athlon> Richard Hughes p??e v St 26. 05. 2010 v 23:16 +0100: > On 26 May 2010 19:54, Milan Kn??ek wrote: > > since GCM is getting more into business of the central repository of ICC > > profiles for other applications, how does it stand from the viewpoint of > > interoperability between various desktop environments? > > Well, GCM exposes a DBus interface that applications to use, rather > than a shared library like other CMS solutions have tried to do. Being > a DBus interface it means that applications written in any language > can access the interface at runtime, rather than build time. This also > means that if the interface is not available (either disabled, or just > not installed) then the application can fall back to defaults or > asking the user. It's like a soft run-time dep, rather than an > implicit hard build-time dep. > Okay, thanks for info. > > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > > will be willing to implement support for GCM. > > Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core > access objects just depend on Glib (rather than GTK and random stuff > like libnotify) so it would be very easy to write a program to expose > the DBus interface without any of the other deps which applications > like digiKam could use. Glib is already part of the LSB so it'll be > installed on pretty much any system regardless of desktop environment. > > Are you worried specifically about the interface name > (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) > or are you just interested in discussion? :) On many other forums, there is a lot of flame wars about KDE/GNOME/whatever by both users and developers and hence I assume that proposing to digiKam developers to add a DBus interface to a GNOME application could result in unnecessary refusal or at least a heated discussion. I personally do not care much and rather try to use applications which fulfil my needs. Having a standardise interface (open file dialog, etc) would be a benefit, but Linux is not there yet. I assume that a politically feasible way for digiKam would be to have a KDE GUI (equivalent to GCM GUI) above the core access objects, and org.gnome.SomeThing might make it a bit more difficult. Anyway, I guess we (users) will have to wait some time until it gets standardised and things will then settle themselves. The worst solution would be to have GCM and "KCM" running at the same moment and fighting for screen calibration... P.S. I have briefly read the OpenICC mailing list discussion recently. Best regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 27 09:44:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 27 May 2010 10:44:19 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274952911.3401.168.camel@athlon> References: <1274900099.19315.40.camel@athlon> <1274952911.3401.168.camel@athlon> Message-ID: On 27 May 2010 10:35, Milan Kn??ek wrote: > On many other forums, there is a lot of flame wars about > KDE/GNOME/whatever by both users and developers and hence I assume that > proposing to digiKam developers to add a DBus interface to a GNOME > application could result in unnecessary refusal or at least a heated > discussion. Sure. I'm not that bothered about the name of the interface I'm using. I'm not sure making the dbus interface org.hughsie.ColorManager is any more cross desktop than org.gnome.ColorManager -- but I do understand the perception. > I assume that a politically feasible way for digiKam would be to have a > KDE GUI (equivalent to GCM GUI) above the core access objects, and > org.gnome.SomeThing might make it a bit more difficult. Yes. Ideally KDE could do a simple KCM which also wrote to ~/.config/device-profiles.conf and also provided the same interface. Note: If this was a viable option, I would have no hesitation to changing the DBus name to something non-gnome and working the KDE guys to get something working. > Anyway, I guess we (users) will have to wait some time until it gets > standardised and things will then settle themselves. The worst solution > would be to have GCM and "KCM" running at the same moment and fighting > for screen calibration... Sure. GCM or the mythical KCM would only be started by the correct desktop, and if they share a same name, then the correct one would be autostarted at session login. Note, a simple KCM would probably only take a few days worth of programming to put together. Richard. From hughsient at gmail.com Fri May 28 16:59:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 28 May 2010 17:59:20 +0100 Subject: New gnome-color-manager release next Monday Message-ID: I'm planning a new release of gnome-color-manager unstable to become 2.31.2 -- if you have any translations to update and push, please do them this weekend. Any broken spelling or grammar (or anything that's just hard to translate) please email me. Thanks. Richard. From bruce at bcowan.me.uk Fri May 28 18:10:05 2010 From: bruce at bcowan.me.uk (Bruce Cowan) Date: Fri, 28 May 2010 19:10:05 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: References: Message-ID: <1275070205.4469.1.camel@Scooby-Dum> On Fri, 2010-05-28 at 17:59 +0100, Richard Hughes wrote: > I'm planning a new release of gnome-color-manager unstable to become > 2.31.2 -- if you have any translations to update and push, please do > them this weekend. > > Any broken spelling or grammar (or anything that's just hard to > translate) please email me. > > Thanks. After a rather limited review (by looking at the new strings in the en_GB translation), here's a fix: ../data/gcm-prefs.ui.h:82 "Reset the sliders to thier default values" -- Bruce Cowan From hughsient at gmail.com Sat May 29 07:27:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 29 May 2010 08:27:24 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: <1275070205.4469.1.camel@Scooby-Dum> References: <1275070205.4469.1.camel@Scooby-Dum> Message-ID: On 28 May 2010 19:10, Bruce Cowan wrote: > Reset the sliders to thier default values Fixed, thanks. Richard. From michielwittkampf at gmail.com Wed May 5 07:42:27 2010 From: michielwittkampf at gmail.com (Michiel Wittkampf) Date: Wed, 5 May 2010 09:42:27 +0200 Subject: GCM and digiKam - how to configure? Message-ID: Hi GCM developers / enthousiasts, I have a question which I could not find the answer for in fora, manuals, color management theorie, etc. Can I use GCM and digiKam succesfully on the same computer, with good colors? And how? Should I enable color management on both, or on one of them? And which suboptions? I looked at the results of switching the folowing options, but didn't figure it out. digiKam: - Enable Color Management - Use color managed view (in editor / for previews and thumbnails) GCM: - Apply display correction - (Set profile for color managed applications.) According tot the digiKam manual Xcalib / Argyll are alternatives to the option 'Use color managed view' in digiKam.* So I supose CGM is too. Yet, when using CGM's 'Apply display correction' makes the screen darker, and using digiKam? 'Use color managed view' gives a brighter picture, while using the same profile. So I am confused. Can you please help me? Greetings, Michiel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Wed May 5 08:00:03 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 5 May 2010 09:00:03 +0100 Subject: GCM and digiKam - how to configure? In-Reply-To: References: Message-ID: On 5 May 2010 08:42, Michiel Wittkampf wrote: > Can you please help me? Well, you certainly want to enable color management in digikam. This means the image source profile is used and is converted to the screen profile, as long as you set the profile for color managed applications in GCM. By setting the source profile you're really just setting a X atom on the root window which digikam can detect and use. If digikam works as a ICC profile in X compatible client, you just have to enable both options in GCM and both options in digikam. Are you using the vendor profile for our screen or are you using a calibrated generated version? Without come sort of calibration you don't know whether the lighter or darker image is the "correct" image. Richard. From hughsient at gmail.com Thu May 6 14:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 6 May 2010 15:05:36 +0100 Subject: GNOME Color Manager 2.31.1 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.1 ~~~~~~~~~~~~~~ Released: 2010-05-06 * Translations - Added Japanese translation (Ryo Fujita) - Added Punjabi Translation (A S Alam) - Added Ukrainian translation (Maxim V. Dziumanenko) - Updated British English translation (Bruce Cowan) - Updated German translation (Mario Bl?ttermann) - Updated Italian translation (Francesco Groccia) - Updated Lithuanian translation (Aurimas ?ernius) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Polish translation (Piotr Dr?g) - Updated Portuguese translation (Ant?nio Lima) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Use a new application icon (Hylke Bons) - Add an experimental gcm-picker program to read spot colors (Richard Hughes) - Show much more detail in the color picker UI and allow the user to choose a RGB colorspace (Richard Hughes) - Show the EISA ID in the devices tab. Fixes rh#581837 (Richard Hughes) * Bugfix: - Clean up the temporary file created by cupsGetPPD2(). Fixes rh#582202 (Tim Waugh) - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not explode when viewing the details of a CMYK profile (Richard Hughes) - Do not rely on an argyllcms specially patched to fix the arg[0] problem (Richard Hughes) - Don't prompt the user to calibrate the device again if we are re-using the GcmCalibrate instance (Richard Hughes) - Fix up the argyll install dialog. Fixes #616106 (Richard Hughes) - Fix up the profile precision dialog. Fixes #583398 (Richard Hughes) - Make gcm-fix-profile open the profile from memory, as then we can catch common access permission errors (Richard Hughes) - Make SANE support configurable at compile time. Fixes #616826 (Richard Hughes) - Offer to install shared-color-profiles-extra if it is not yet installed (Richard Hughes) Richard. From lists+gnome-color-manager at hoech.org Fri May 7 13:13:41 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:13:41 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: Message-ID: <4BE41205.6080301@hoech.org> Hi, recently I switched from the proprietary nvidia driver to noveau, so I could try the latest GCM :) I noticed that for screen calibration, always a quality of 'low' is used and a shaper+matrix profile is created from varying colorpatch amounts and quality parameter. Looking at the code, the 100-500 colorpatches used for the screen profiling really seem overkill for a simple matrix profile. So the first thing I'd suggest, is to always use a lower, fixed-amount colorpatch set: targen -d3 -e4 -g9 -m3, this yields 36 patches that most other profilers out there also seem to use and should give very good results with matrix profiles (of course YMMV, but imho it would be a good default. This is what I use in dispcalGUI atm). Then, I'd suggest colprof -qh for matrix profiles (lower quality levels will smooth the trc curves more, but I think high quality could model the device response more accurately). This shouldn't come at any speed penalty at the new low suggested colorpatch count. And, as GCM always does a calibration+profile, I'd use colprof -aS (single shaper+matrix) instead of -as (per channel shaper+matrix), as we can rely on the calibration already having established gray balance, thus no need to risk the per channel curves introducing banding or shimmering. These changes would remove the need for the current three profile 'precision' choices for screen calibration/profiling, so the last suggestion from me is to instead present the user with a choice for the calibration (dispcal) quality instead, or to get rid of the choice altogether (only for screen calibration/profiling ofcourse). What do you think? Am 06.05.2010 16:05, schrieb Richard Hughes: > 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.1 Regards -- Florian H?ch http://hoech.net From lists+gnome-color-manager at hoech.org Fri May 7 13:36:12 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:36:12 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE4174C.1050903@hoech.org> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From lists at hoech.net Fri May 7 13:33:36 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:33:36 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE416B0.6050309@hoech.net> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From pmjdebruijn at pcode.nl Fri May 7 15:48:54 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 7 May 2010 17:48:54 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE416B0.6050309@hoech.net> References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: > (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) > > Am 07.05.2010 15:13, schrieb Florian H?ch: >> >> targen -d3 -e4 -g9 -m3 I do agree 500 patches is a bit overkill... But the time it takes to measure a few extra patch is usually not that much, so I don't really see the point of measuring as few as possible patches... Is there any particularly reason why you're using -m3 instead of -f3? I think we need to trust Graeme a bit on the defaults... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Fri May 7 16:47:39 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 18:47:39 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: <4BE4442B.5060804@hoech.org> Am 07.05.2010 17:48, schrieb Pascal de Bruijn: > On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: >> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) >> >> Am 07.05.2010 15:13, schrieb Florian H?ch: >>> >>> targen -d3 -e4 -g9 -m3 > > I do agree 500 patches is a bit overkill... But the time it takes to > measure a few extra patch is usually not that much, so I don't really > see the point of measuring as few as possible patches... Well, for 'shaper+matrix' profiles, when a certain amount of patches is reached, it doesn't seem to increase the accuracy of the curves perceptibly (atleast in my experience). > Is there any particularly reason why you're using -m3 instead of -f3? > I think we need to trust Graeme a bit on the defaults... Yes, agreed (actually I didn't know those were Graeme's defaults). And the default optimized farthest point sampling is working really great for LUT-type profiles and subtractive devices like printers. But I always found that when using additive devices like screens, shaper+matrix, and decreasing the number of patches, the simpler device grid spacing seemed to work as good (also note that -f3 will only add three ofps patches, while -m3 will generate 27 device grid patches). My own testing showed negligible difference in the resulting tone curves when comparing -f500 and -g9 -m3 -f0 (see attached, and ignore the jumping dot, thats just the point I was hovering when taking the screenshots). You could always increase the amount of grayscale patches for a 'single shaper+matrix' profile if increased curve accuracy is desired, but I would go as far as saying this is probably not even neccesary in most cases. Of course, YMMV. I can only talk about the few screens I've available, which is two cheap TN (one in a laptop), a PVA and an IPS panel, and some screens of other people I've tested so far (mostly PVA, some IPS). > Regards, > Pascal de Bruijn > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list -- Florian H?ch http://hoech.net -------------- next part -------------- A non-text attachment was scrubbed... Name: TRC.gif Type: image/gif Size: 10661 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Sun May 9 00:21:26 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Sun, 9 May 2010 02:21:26 +0200 Subject: gcm-git gio dependancy Message-ID: Hi, The latest git checkout seems to require a newer version of gio than usual... /build/buildd/gnome-color-manager-2.31.2~git20100508/./configure: line 12841: GLIB_GSETTINGS: command not found checking for GLIB... configure: error: Package requirements (glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.0) were not met: Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 I'm assuming this is intentional, for GSettings? Regards, Pascal de Bruijn From hughsient at gmail.com Sun May 9 09:39:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 9 May 2010 10:39:34 +0100 Subject: gcm-git gio dependancy In-Reply-To: References: Message-ID: On 9 May 2010 01:21, Pascal de Bruijn wrote: > The latest git checkout seems to require a newer version of gio than usual... > Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 > I'm assuming this is intentional, for GSettings? Sure. As GNOME Color Manager is a proposed module for 2.31.x I've been encouraged to push the GSettings code into master for wider testing. To get a good chance of "blessed" by GNOME we need to adhere to all the goals, and one of those is GSettings. You can use gnome-2-30 if you just want to use GCM on a stable system as I'm going to be quite aggressive backporting fixes. Richard. From hughsient at gmail.com Thu May 20 11:40:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 12:40:32 +0100 Subject: Adding device profiles Message-ID: In GCM, you can currently add "virtual" devices which you manually populate the fields then assign a profile. This sucks monkey balls. What I really want is to be able to point GCM at a RAW file (or TIFF, or PNG, or JPG) and for it to read out the metadata (EXIF data) and populate those text fields for me, and then autoselecting a profile if you've got one that matches. This allows us to provide the feature on the DBus interface too. To do this, I either need to depend on exiftool (perl, ick) or exifinfo (python, ick) or I can just decode the headers myself like I'm already doing for TIFF files. Assuming I do the latter, I really need a raw decoder, and the only one that looks sane from a packaging point of view is libopenraw -- which looks pretty easy to use. I can always make this a conditional build-time dep if this is not available in all distros. So, comments? Better ideas? Richard. From pmjdebruijn at pcode.nl Thu May 20 17:12:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 20 May 2010 19:12:41 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 1:40 PM, Richard Hughes wrote: > In GCM, you can currently add "virtual" devices which you manually > populate the fields then assign a profile. This sucks monkey balls. You forgot hairy :) > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Schweet! > To do this, I either need to depend on exiftool (perl, ick) or > exifinfo (python, ick) or I can just decode the headers myself like > I'm already doing for TIFF files. Well, since Nautilus already depends on libexif12 and libexempi, those would be the obvious candidates. That way GCM won't pull in extra dependancies... > Assuming I do the latter, I really need a raw decoder, and the only > one that looks sane from a packaging point of view is libopenraw -- > which looks pretty easy to use. I can always make this a conditional > build-time dep if this is not available in all distros. Well, I could be mistaken but libopenraw is extremely unfinished and doesn't support half of the fileformats dcraw does... Again, I haven't checked it recently so I could be mistaken! Maybe LibRaw is a workable solution? Regards, Pascal de Bruijn From knizek.confy at volny.cz Thu May 20 17:44:07 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 20 May 2010 19:44:07 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: <1274377447.6560.13.camel@athlon> Richard Hughes p??e v ?t 20. 05. 2010 v 12:40 +0100: > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Will there be a provision for the situation "one camera" : "various profiles"? I usually use a single "universal" profile for my camera, however, there may be users with more variants - e.g. per type of scene light or a photo shooting session. regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 20 19:06:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 20:06:24 +0100 Subject: Adding device profiles In-Reply-To: <1274377447.6560.13.camel@athlon> References: <1274377447.6560.13.camel@athlon> Message-ID: On 20 May 2010 18:44, Milan Kn??ek wrote: > Will there be a provision for the situation "one camera" : "various > profiles"? Sure. It's already supported in the DBus API and in the configuration file, somebody (me?) has to add the required UI parts. I'm not sure what it should look like, so ideas welcome. Richard. From hughsient at gmail.com Fri May 21 08:14:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 09:14:09 +0100 Subject: Help! I need a test RAW file Message-ID: Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of course, I could just take a picture with my D60, but I really don't want to add a huge 9Mb NEF file to git master just so I can test getting metadata in make check. Does anybody know how I can export or resize a RAW file with metadata so that it's only a few pixels in size? In git I have data/test/test.{png|jpg|tif} as test cases that are only a fex pixels across and thus are a few tens of K in size. I can promise beer in return. Thanks. Richard. From liw at liw.fi Fri May 21 08:17:22 2010 From: liw at liw.fi (Lars Wirzenius) Date: Fri, 21 May 2010 20:17:22 +1200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: <1274429842.27529.216.camel@havelock> On pe, 2010-05-21 at 09:14 +0100, Richard Hughes wrote: > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? If DNG format works, that would probably be your best bet. The proprietary, undocumented formats are read-only with all the tools I know of. Not that I know of a way to generate a DNG either. From pmjdebruijn at pcode.nl Fri May 21 08:34:39 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 21 May 2010 10:34:39 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. It might be a longshot, but maybe it's an idea to contact Dave Coffin? Regards, Pascal de Bruijn From lars.tore at mulebakken.net Fri May 21 09:04:53 2010 From: lars.tore at mulebakken.net (Lars Tore Gustavsen) Date: Fri, 21 May 2010 11:04:53 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. The rawsamples site have a Kodak DC50 raw file at 91kb http://www.rawsamples.ch/index_en.php From hughsient at gmail.com Fri May 21 10:43:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 11:43:45 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 20 May 2010 18:12, Pascal de Bruijn wrote: > Well, since Nautilus already depends on libexif12 and libexempi, those > would be the obvious candidates. > > That way GCM won't pull in extra dependancies... Sure, libexif gets us jpeg files working. I've added that just now, thanks. libexempi looks less useful unless you can parse the XMP data out of the RAW files, see below... > Well, I could be mistaken but libopenraw is extremely unfinished and > doesn't support half of the fileformats dcraw does... Again, I haven't > checked it recently so I could be mistaken! Sure, I'm not so interested in the output formats, just the XMP metadata in the file. Neither libraw or libopenraw seem to be able to extract the metadata from the raw file. Rawstudio and ufraw seem to use exiv2 which is written in C++, which is less than ideal (c++ compiler needed to compile GCM...). I'm not apposed to calling an external executable for this data, but exiftool with it's huge trail of perl deps isn't really on my wishlist. Richard. From hughsient at gmail.com Fri May 21 13:35:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:35:09 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() Message-ID: Now the functionality for assigning profiles to images is nearly finished (just drag the image file onto the virtual device dialog) -- I've also added a new DBus method: GetProfilesForFile() The idea is you feed it a image filename and out pops an array of profile filenames. Typically they'll be one entry in the array, in which case applications like Shotwell and GIMP should probably use the ICC profile in the main viewer. If there is more than one item in the array, then it's up to the application whether it wants to use the default (the first entry) or show a popup asking what profile to use. For the curious, I've also added this functionality to gcm-inspect. [hughsie at hughsie-t61 src]$ ./gcm-inspect --file ../data/tests/test.jpg Suitable profiles for: ../data/tests/test.jpg 1. /home/hughsie/.color/icc/GCM - NIKON - NIKON DSC D60 - NIKON NIKON DSC D60 7457338 (2010-02-08).icc Pascal de Bruijn, NIKON - NIKON DSC D60 (2010-02-08) All code is in git master. Richard. From andy at luto.us Fri May 21 13:52:26 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:52:26 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: I don't know if this counts for the beer, but I took the most compressible picture I could think of with my D40 (the sky, on a bright sunny day here in Boston, overexposed by quite a few stops). bzip2 gets it to 13K, attached. (bzip2 beats xz -9 by a bit and gzip quite handily). --Andy On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: overexposed.NEF.bz2 Type: application/x-bzip2 Size: 13187 bytes Desc: not available URL: From andy at luto.us Fri May 21 13:56:55 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:56:55 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 9:52 AM, Andrew Lutomirski wrote: > I don't know if this counts for the beer, but I took the most > compressible picture I could think of with my D40 (the sky, on a > bright sunny day here in Boston, overexposed by quite a few stops). > > bzip2 gets it to 13K, attached. ?(bzip2 beats xz -9 by a bit and gzip > quite handily). That attachment is released under the CC0 license, available here: http://creativecommons.org/publicdomain/zero/1.0/legalcode --Andy > > --Andy > > On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: >> Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of >> course, I could just take a picture with my D60, but I really don't >> want to add a huge 9Mb NEF file to git master just so I can test >> getting metadata in make check. >> >> Does anybody know how I can export or resize a RAW file with metadata >> so that it's only a few pixels in size? In git I have >> data/test/test.{png|jpg|tif} as test cases that are only a fex pixels >> across and thus are a few tens of K in size. I can promise beer in >> return. Thanks. >> >> Richard. >> _______________________________________________ >> gnome-color-manager-list mailing list >> gnome-color-manager-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list >> > From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Sat May 22 08:42:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:42:34 +0100 Subject: GNOME Color Manager wiki Message-ID: Some of you guys may not be aware of the GCM wiki page. That's fair enough, as until yesterday the content was tiny, and the page uninteresting. So, two late night later, I present http://live.gnome.org/GnomeColorManager It's quite a bit of a brain dump, and expect more content as I get more time. Hopefully you can see from the page what we're trying to achieve and the direction GCM is going in. It's a wiki, so if you see any spelling errors or glaring omissions, just jump in an make changes. Please don't move/delete/restructure vast swathes of content without asking first. Thanks. Richard From hughsient at gmail.com Sat May 22 08:47:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:47:36 +0100 Subject: Supporting OpenIccDirectoryProposal Message-ID: OpenIccDirectoryProposal is a proposal to make the main CMMs in Linux and UNIX adhere to a common directory spec. I stumbled on it this morning, and agree with what it's trying to achieve. As such, I've committed two changes to GCM in git master (not gnome-2-30) to adhere to this spec: commit fef750d4bed38fa68d7b07b1963758f5d8d73210 Author: Richard Hughes Date: Sat May 22 08:36:09 2010 +0100 Use the common data path from OpenIccDirectoryProposal No migration is required, the old location is searched as well. :100644 100644 50f9001... 806fa26... M src/gcm-import.c :100644 100644 a0bd735... 882fc53... M src/gcm-profile-store.c :100644 100644 2760b75... 10e3367... M src/gcm-utils.c :100644 100644 3f9e5e0... 7c1c380... M src/gcm-utils.h commit 784a617285b82f4d2276cd8d7ce03d883066e10f Author: Richard Hughes Date: Sat May 22 08:24:58 2010 +0100 Use the common configuration path from OpenIccDirectoryProposal You will need to rename ~/.config/gnome-color-manager to ~/.config/color if you want to re-use your old configuration :100644 100644 2da35ed... 2760b75... M src/gcm-utils.c You can see from the last commit a rename is required if you don't want to re-assign all your profiles. I might do that automatically closer to the 2.31.2 release if there are people that file bugs, although it would be upsetting to run a GCM from a checkout which made your system GCM stop working. Maybe I can just put it in the release notes. Richard. From hughsient at gmail.com Mon May 24 07:40:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 08:40:16 +0100 Subject: Supporting OpenIccDirectoryProposal In-Reply-To: References: Message-ID: On 22 May 2010 09:47, Richard Hughes wrote: > You can see from the last commit a rename is required if you don't > want to re-assign all your profiles. I might do that automatically > closer to the 2.31.2 release if there are people that file bugs, > although it would be upsetting to run a GCM from a checkout which made > your system GCM stop working. Okay, I got sun-burnt on Sunday and had to sit inside for a few hours: commit a6c63ded454a8cde43ed9559c8b329da645e406e Author: Richard Hughes Date: Sun May 23 11:01:39 2010 +0100 Migrate the old device-profiles.conf to the new location so the user does not have to do it manually :100644 100644 ce2c1fb... b31f9bb... M data/org.gnome.color-manager.gschema.xml :100644 100644 962a7dd... 1327bae... M src/gcm-client.c :100644 100644 10e3367... 16be031... M src/gcm-utils.c :100644 100644 7c1c380... 384572f... M src/gcm-utils.h Richard. From hughsient at gmail.com Mon May 24 12:49:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 13:49:23 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 21 May 2010 11:43, Richard Hughes wrote: > Rawstudio and ufraw seem to use exiv2 which is written in C++ commit 926ecf7a8f086dd0f2f2c63b1ba0b9f3700d8cdc Author: Richard Hughes Date: Mon May 24 13:44:19 2010 +0100 Add optional exif2 support so we can get properties of RAW files too Note: This is implemented as a separate executable that is used to avoid either compiling GCM with g++ and to avoid weird linker errors on random platforms :100644 100644 4cbdaa7... 1812054... M configure.ac :100644 100644 a79decd... 08f3786... M contrib/gnome-color-manager.spec.in :100644 100644 a745113... 451b0ab... M data/tests/Makefile.am :000000 100644 0000000... 3235462... A data/tests/test.kdc :100644 100644 55d7092... ef822fc... M src/.gitignore :100644 100644 684b583... 61e0173... M src/Makefile.am :100644 100644 a985383... 532084f... M src/gcm-exif.c :000000 100644 0000000... 6385d5b... A src/gcm-helper-exiv.cpp :100644 100644 8077a4a... 587be3e... M src/gcm-self-test.c Richard. From hughsient at gmail.com Wed May 26 08:29:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 09:29:47 +0100 Subject: Multiple profile device support Message-ID: Why might we want more than one profile for a device? * A monitor has two selectable modes, sRGB and wide gamut * A printer has different profiles depending on the media and inks * A camera has different profiles depending on whether it's shot in the studio or outside What situations still require 1:1 device profile mapping: * Scanners, where nothing can be altered Now, the DBus interface and the device-profiles configuration already supports multiple profiles for each device, just not the UI. If you guys have any other use cases for more than one profile for a device then I'm interested. So, if we decide we need prefs UI to choose between studio and outside camera profiles, what should it looks like? ___________________________________ | Nikon D60 Studio (default) |#Nikon#D60#Outside################ |__________________________________ [ Make default for device ] [ Assign another profile ] [ Unassign this profile ] Or we just have the buttons [ Add ] [ Remove ] and [ Make default ] Although then we have two "Add" and "Remove" buttons on the same tab. Or do we have hypertext entries in the cellview itself: __________________________________________________________ | Nikon D60 Studio (default) | /Remove/ |#Nikon#D60#Outside#############| /Make default/, /Remove/ |_______________________________|_/Add another profile/___ Or do we just let the user drag the profiles up and down to select the order? Double click to make default? Is this discoverable enough? How do users add profiles from the existing combobox? ASCII art welcome. :-) Thanks, Richard From paul at fincc.com Wed May 26 08:57:46 2010 From: paul at fincc.com (Paul Finnigan) Date: Wed, 26 May 2010 09:57:46 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274864266.2467.11.camel@localhost> Richard On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? ... > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. I have one to think about. I am racking my tiny mind to see how this would fit in with gcm! My camera profile is associated with an image! I have a Nikon D700, I thought other Nikon cameras took similar views. Each image has a profile associated with it according to the conditions under which the photograph was taken. I agree that five or six profiles will probably cover me for most of my work. But each image has a profile built in it. Do I need this or should the application be using this as a offset to a base profile? I have to say that currently most applications appear to show colour very well, once I have gcm setup. I just thought I would ask the question as to what should happen. -- Paul Finnigan From dan at berrange.com Wed May 26 08:56:54 2010 From: dan at berrange.com (Daniel P. Berrange) Date: Wed, 26 May 2010 09:56:54 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <20100526085654.GA25454@berrange.com> On Wed, May 26, 2010 at 09:29:47AM +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut > * A printer has different profiles depending on the media and inks > * A camera has different profiles depending on whether it's shot in > the studio or outside > * A scanner can be in reflective media (paper) or transparent media (film / slides) mode. Each mode has potential for multiple profiles particularly for type of film > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. > > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ > > [ Make default for device ] > [ Assign another profile ] > [ Unassign this profile ] > > Or we just have the buttons > > [ Add ] [ Remove ] and [ Make default ] > > Although then we have two "Add" and "Remove" buttons on the same tab. > > Or do we have hypertext entries in the cellview itself: > __________________________________________________________ > | Nikon D60 Studio (default) | /Remove/ > |#Nikon#D60#Outside#############| /Make default/, /Remove/ > |_______________________________|_/Add another profile/___ > > Or do we just let the user drag the profiles up and down to select the > order? Double click to make default? Is this discoverable enough? How > do users add profiles from the existing combobox? NB, for scanners you can have 2 defaults. Since the scanner program knows whether its doing transparencies or reflective media, it will want a default profile for each mode, along with other non-default choices for each. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From hughsient at gmail.com Wed May 26 09:24:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:24:35 +0100 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On 26 May 2010 09:57, Paul Finnigan wrote: > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Right, but the GetProfilesForFile returns a list of profiles (by design) so you can easily ask GCM for the list of profiles for a specific image. > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Well, if the image has an embedded profile then we don't need to ask GCM anything. Richard. From hughsient at gmail.com Wed May 26 09:26:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:26:48 +0100 Subject: Multiple profile device support In-Reply-To: <20100526085654.GA25454@berrange.com> References: <20100526085654.GA25454@berrange.com> Message-ID: On 26 May 2010 09:56, Daniel P. Berrange wrote: > ?* A scanner can be in reflective media (paper) or transparent > ? media (film / slides) mode. Each mode has potential for multiple > ? profiles particularly for type of film Point taken. So it does make sense to have the multiple-profile / device selector for all device types. > NB, for scanners you can have 2 defaults. Since the scanner program > knows whether its doing transparencies or reflective media, it will > want a default profile for each mode, along with other non-default > choices for each. Sure, that's exactly what the "options" hint is supposed to allow. We've not specified the allowed values for the hint, although sticking in something like "transparency" should probably change the /order/ (and thus also the default) of the profiles returned. Richard. From pmjdebruijn at pcode.nl Wed May 26 15:50:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:50:41 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 10:29 AM, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut Does this actually make sense? Not really.... You profile your monitor, and then the CMS convert sRGB into the screens RGB... A display profile will always be about a display's native gamut (within a certain set of display settings). But again here, for the display settings, there is usually only way correct way to set them. > * A printer has different profiles depending on the media and inks Profiles galore! > * A camera has different profiles depending on whether it's shot in > the studio or outside Indeed... Though this is often very much exaggerated... A single profile well-made against daylight or a strobe can usually cover 80/90% of your usage scenario's, unless you're really anal retentive... > * Scanners, where nothing can be altered Think of negative/positive scanning as well, which could mean a profile per type of negative. > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ This makes very little sense! At least if I'm getting this right (big IF) :) When developing RAWs: Which profile to apply is a decision you make on-the-fly when working with a RAW converter... When printing: Which profile to apply is a decision you make on-the-fly when loading the printer with paper before printing... This could very well be per 1 sheet... When scanning: To set a generic scanner profile this make sense... but for negatives/transparancies this is something you would apply on-the-fly using the scanning tool... So I'm not sure to what extent it is useful for GCM to get involved here... Except for setting the default profile :) Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Wed May 26 15:58:03 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:58:03 +0200 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On Wed, May 26, 2010 at 10:57 AM, Paul Finnigan wrote: > Richard > > On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: >> Why might we want more than one profile for a device? > ... >> Now, the DBus interface and the device-profiles configuration already >> supports multiple profiles for each device, just not the UI. If you >> guys have any other use cases for more than one profile for a device >> then I'm interested. > > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Really? Thus far I've never seen any camera profile RAW files with embedded profiles... Or am I misunderstanding? > I have a Nikon D700, I thought other Nikon cameras took similar views. > Each image has a profile associated with it according to the conditions > under which the photograph was taken. How do you figure this? > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Please don't confuse an actual color profile, for other color post-processing options... For example I think CaptureNX actually generates ICC files on-the-fly for the processing settings selected in the app, and seems to do the full image transform in the CMS... At least as far as I heard (I never personally investigated this properly, HEARSAY WARNING). It's a pretty creative approach, though not how color management is intended nor how it should be used... If you profile your camera yourself, usually a few profiles should do very well... I tend to get by very well with only a single matrix only profile), and a decent basecurve. Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 16:02:01 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 17:02:01 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 16:50, Pascal de Bruijn wrote: > Does this actually make sense? Not really.... There are wide-gamut monitors that allow different "modes" so you artificially lower the gamut range so you don't blow your eyes when you try to view uncorrected content. It turns out HP have a large number of those monitors "in the field" so to speak, and they are quite keen on getting them to work correctly. > A single profile well-made against daylight or a strobe can usually > cover 80/90% of your usage scenario's, unless you're really anal > retentive... Sure, but people that care about color management and anally retentive people are very co-morbid :-) >> * Scanners, where nothing can be altered > > Think of negative/positive scanning as well, which could mean a > profile per type of negative. Right, makes sense. > This makes very little sense! At least if I'm getting this right (big IF) :) > > When developing RAWs: > Which profile to apply is a decision you make on-the-fly when working > with a RAW converter... Yes, that's how it used to be. The RAW converter has to be "set" manually with the ICC profile to use, which is gobbledygook that nobody will do. That's something I want to automate, see http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ for details. The idea is that the RAW converter (darktable, f-spot, whatever) calls into GCM to find out the ICC profile that should be used for each file. > When printing: > Which profile to apply is a decision you make on-the-fly when loading > the printer with paper before printing... This could very well be per > 1 sheet... Sure. The CUPS parts are very much still up in the air and are being worked on. We don't have a very good story there yet. > When scanning: > To set a generic scanner profile this make sense... but for > negatives/transparancies this is something you would apply on-the-fly > using the scanning tool... Right, but presumably one wants to be used by default? For something like simple scan we can just tell it the default profile and there is no UI to configure. > So I'm not sure to what extent it is useful for GCM to get involved > here... Except for setting the default profile :) I'm really pushing GCM into the CMM role, where the defaults are got from GCM rather than set in each and every application. Richard. From pmjdebruijn at pcode.nl Wed May 26 16:45:50 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 18:45:50 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > On 26 May 2010 16:50, Pascal de Bruijn wrote: >> Does this actually make sense? Not really.... > > There are wide-gamut monitors that allow different "modes" so you > artificially lower the gamut range so you don't blow your eyes when > you try to view uncorrected content. It turns out HP have a large > number of those monitors "in the field" so to speak, and they are > quite keen on getting them to work correctly. I actually have a HP screen, it does have an sRGB mode indeed... But this means the screen fiddles with it's internal LUT a bit to fake this... It's not really a great idea... The extra saturation because of the wide gamut usually is not that much of a problem... It's usually the high brightness combined with the extra saturation that is the problem... High brightness is usually frowned upon in color management anyways. When I turn up my brightness to 100% I need sunscreen to sit behind my screen for prolonged periods... That's why I set my brightness to a value that correlates to ~200cm/m2. >> A single profile well-made against daylight or a strobe can usually >> cover 80/90% of your usage scenario's, unless you're really anal >> retentive... > > Sure, but people that care about color management and anally retentive > people are very co-morbid :-) Hard to argue with that. >>> * Scanners, where nothing can be altered >> >> Think of negative/positive scanning as well, which could mean a >> profile per type of negative. > > Right, makes sense. > >> This makes very little sense! At least if I'm getting this right (big IF) :) >> >> When developing RAWs: >> Which profile to apply is a decision you make on-the-fly when working >> with a RAW converter... > > Yes, that's how it used to be. The RAW converter has to be "set" > manually with the ICC profile to use, which is gobbledygook that > nobody will do. That's something I want to automate, see > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > for details. And that's how it should be in the future... GCM can only help by not providing any irrelevant profiles... So if I have a 400D, it could provide 400D profiles only so if I have a 5D as well, I won't see those profiles... But GCM cannot tell whether a picture needs the "daylight" profile or the "studio" profile... Obviously this is where the default comes in... But the user still needs to be easy-able to make a last minute decision about this, without having to start gcm-prefs. > The idea is that the RAW converter (darktable, f-spot, whatever) calls > into GCM to find out the ICC profile that should be used for each > file. > >> When printing: >> Which profile to apply is a decision you make on-the-fly when loading >> the printer with paper before printing... This could very well be per >> 1 sheet... > > Sure. The CUPS parts are very much still up in the air and are being > worked on. We don't have a very good story there yet. Boatload of work... :( >> When scanning: >> To set a generic scanner profile this make sense... but for >> negatives/transparancies this is something you would apply on-the-fly >> using the scanning tool... > > Right, but presumably one wants to be used by default? For something > like simple scan we can just tell it the default profile and there is > no UI to configure. Again the scanning app doesn't know whether I'm scanning a transparancy or not... For an application like simple-scan this could be omitted because it's _not_ intended as a scanner's swiss-army-knife... But for say XSane (if anybody is still working on that, god forbid), it would still be the end-user that need to select which exact profile he needs to apply to his image... Obviously profiles for completely different scanner types could be omitted. > >> So I'm not sure to what extent it is useful for GCM to get involved >> here... Except for setting the default profile :) > > I'm really pushing GCM into the CMM role, where the defaults are got > from GCM rather than set in each and every application. That's good... Centralised defaults are VERY good :) Though there is another thing you need to keep track of... Profiles are not per-se interchangeable between different applications... For example UFRaw does not output 100% true linear RGB RAW before applying the profile... DCRAW/Darktable do at least as far as I know... Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 17:56:57 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 18:56:57 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 17:45, Pascal de Bruijn wrote: > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... Sure, I don't disagree. > That's why I set my brightness to a value that correlates to ~200cm/m2. Out of interest, how did you measure that? > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > > So if I have a 400D, it could provide 400D profiles only so if I have > a 5D as well, I won't see those profiles... Sure at the moment it matches against make, model and camera serial number. > But GCM cannot tell whether a picture needs the "daylight" profile or > the "studio" profile... Correct. In the absence of hints GCM provides both profiles, well, it actually provides the filename and the description ready formatted, so applications like GIMP can easy populate a combobox if there are more than one entry and they don't just want the default. It's the reason we have the complicated a(ss) return type so applications don't have to parse the profile themselves to get the localized description value. > Again the scanning app doesn't know whether I'm scanning a > transparancy or not... It might, cleverer HP scanners can detect what accessories they have inserted. In general I agree tho. > But for say XSane (if anybody is still working on that, god forbid), > it would still be the end-user that need to select which exact profile > he needs to apply to his image... Obviously profiles for completely > different scanner types could be omitted. At the moment GCM just sets up the XSane default profile with the default profile for the device. I know for sure it can't support more than one profile, and I also know that XSane struggles with filenames with spaces in them... > Profiles are not per-se interchangeable between different > applications... For example UFRaw does not output 100% true linear RGB > RAW before applying the profile... DCRAW/Darktable do at least as far > as I know... Surely that's a UFRaw bug then? Richard. From hughsient at gmail.com Wed May 26 19:00:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 20:00:34 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 09:29, Richard Hughes wrote: > ASCII art welcome. :-) The attached screenshot is what's in git master. Feedback welcome. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Color Management.png Type: image/png Size: 53028 bytes Desc: not available URL: From knizek.confy at volny.cz Wed May 26 18:45:31 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:45:31 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274899531.19315.33.camel@athlon> Pascal de Bruijn p??e v St 26. 05. 2010 v 18:45 +0200: > On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > > On 26 May 2010 16:50, Pascal de Bruijn wrote: > >> Does this actually make sense? Not really.... > > > > There are wide-gamut monitors that allow different "modes" so you > > artificially lower the gamut range so you don't blow your eyes when > > you try to view uncorrected content. It turns out HP have a large > > number of those monitors "in the field" so to speak, and they are > > quite keen on getting them to work correctly. > > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... > It is not a best solution, but until the complete desktop is colour managed, it is needed to have a chance to switch to sRGB emulation. Otherwise, the window decorations and images in non-colour managed apps look unrealistic. > > Yes, that's how it used to be. The RAW converter has to be "set" > > manually with the ICC profile to use, which is gobbledygook that > > nobody will do. That's something I want to automate, see > > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > > for details. > > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > I agree. GCM would not only provide a default profile for each device type (one for 5D, another for D200, etc.) but also a list of potentially usable profiles, which were previously assigned by the user for the particular device. The advantage is that the list of available profiles gets shorter. >From the work-flow viewpoint, it would be really slow to start GCM UI only to change the profile or rendering intent for a single photo. This option must be available directly in the app (RAW converter, editor). Regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From knizek at volny.cz Wed May 26 18:54:59 2010 From: knizek at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:54:59 +0200 Subject: Interoperability of GCM? Message-ID: <1274900099.19315.40.camel@athlon> Hello, since GCM is getting more into business of the central repository of ICC profiles for other applications, how does it stand from the viewpoint of interoperability between various desktop environments? I use mainly Gnome or GTK based apps (EoG, UFRaw, GIMP, CinePaint) but also digiKam (KDE) for archive management. If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers will be willing to implement support for GCM. Regards, Milan Kn??ek knizek (na) volny (te?ka) cz http://www.milan-knizek.net - O linuxu a fotografov?n? From hughsient at gmail.com Wed May 26 22:16:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 23:16:43 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274900099.19315.40.camel@athlon> References: <1274900099.19315.40.camel@athlon> Message-ID: On 26 May 2010 19:54, Milan Kn??ek wrote: > since GCM is getting more into business of the central repository of ICC > profiles for other applications, how does it stand from the viewpoint of > interoperability between various desktop environments? Well, GCM exposes a DBus interface that applications to use, rather than a shared library like other CMS solutions have tried to do. Being a DBus interface it means that applications written in any language can access the interface at runtime, rather than build time. This also means that if the interface is not available (either disabled, or just not installed) then the application can fall back to defaults or asking the user. It's like a soft run-time dep, rather than an implicit hard build-time dep. > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > will be willing to implement support for GCM. Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core access objects just depend on Glib (rather than GTK and random stuff like libnotify) so it would be very easy to write a program to expose the DBus interface without any of the other deps which applications like digiKam could use. Glib is already part of the LSB so it'll be installed on pretty much any system regardless of desktop environment. Are you worried specifically about the interface name (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) or are you just interested in discussion? :) Richard From knizek.confy at volny.cz Thu May 27 09:35:11 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 27 May 2010 11:35:11 +0200 Subject: Interoperability of GCM? In-Reply-To: References: <1274900099.19315.40.camel@athlon> Message-ID: <1274952911.3401.168.camel@athlon> Richard Hughes p??e v St 26. 05. 2010 v 23:16 +0100: > On 26 May 2010 19:54, Milan Kn??ek wrote: > > since GCM is getting more into business of the central repository of ICC > > profiles for other applications, how does it stand from the viewpoint of > > interoperability between various desktop environments? > > Well, GCM exposes a DBus interface that applications to use, rather > than a shared library like other CMS solutions have tried to do. Being > a DBus interface it means that applications written in any language > can access the interface at runtime, rather than build time. This also > means that if the interface is not available (either disabled, or just > not installed) then the application can fall back to defaults or > asking the user. It's like a soft run-time dep, rather than an > implicit hard build-time dep. > Okay, thanks for info. > > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > > will be willing to implement support for GCM. > > Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core > access objects just depend on Glib (rather than GTK and random stuff > like libnotify) so it would be very easy to write a program to expose > the DBus interface without any of the other deps which applications > like digiKam could use. Glib is already part of the LSB so it'll be > installed on pretty much any system regardless of desktop environment. > > Are you worried specifically about the interface name > (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) > or are you just interested in discussion? :) On many other forums, there is a lot of flame wars about KDE/GNOME/whatever by both users and developers and hence I assume that proposing to digiKam developers to add a DBus interface to a GNOME application could result in unnecessary refusal or at least a heated discussion. I personally do not care much and rather try to use applications which fulfil my needs. Having a standardise interface (open file dialog, etc) would be a benefit, but Linux is not there yet. I assume that a politically feasible way for digiKam would be to have a KDE GUI (equivalent to GCM GUI) above the core access objects, and org.gnome.SomeThing might make it a bit more difficult. Anyway, I guess we (users) will have to wait some time until it gets standardised and things will then settle themselves. The worst solution would be to have GCM and "KCM" running at the same moment and fighting for screen calibration... P.S. I have briefly read the OpenICC mailing list discussion recently. Best regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 27 09:44:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 27 May 2010 10:44:19 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274952911.3401.168.camel@athlon> References: <1274900099.19315.40.camel@athlon> <1274952911.3401.168.camel@athlon> Message-ID: On 27 May 2010 10:35, Milan Kn??ek wrote: > On many other forums, there is a lot of flame wars about > KDE/GNOME/whatever by both users and developers and hence I assume that > proposing to digiKam developers to add a DBus interface to a GNOME > application could result in unnecessary refusal or at least a heated > discussion. Sure. I'm not that bothered about the name of the interface I'm using. I'm not sure making the dbus interface org.hughsie.ColorManager is any more cross desktop than org.gnome.ColorManager -- but I do understand the perception. > I assume that a politically feasible way for digiKam would be to have a > KDE GUI (equivalent to GCM GUI) above the core access objects, and > org.gnome.SomeThing might make it a bit more difficult. Yes. Ideally KDE could do a simple KCM which also wrote to ~/.config/device-profiles.conf and also provided the same interface. Note: If this was a viable option, I would have no hesitation to changing the DBus name to something non-gnome and working the KDE guys to get something working. > Anyway, I guess we (users) will have to wait some time until it gets > standardised and things will then settle themselves. The worst solution > would be to have GCM and "KCM" running at the same moment and fighting > for screen calibration... Sure. GCM or the mythical KCM would only be started by the correct desktop, and if they share a same name, then the correct one would be autostarted at session login. Note, a simple KCM would probably only take a few days worth of programming to put together. Richard. From hughsient at gmail.com Fri May 28 16:59:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 28 May 2010 17:59:20 +0100 Subject: New gnome-color-manager release next Monday Message-ID: I'm planning a new release of gnome-color-manager unstable to become 2.31.2 -- if you have any translations to update and push, please do them this weekend. Any broken spelling or grammar (or anything that's just hard to translate) please email me. Thanks. Richard. From bruce at bcowan.me.uk Fri May 28 18:10:05 2010 From: bruce at bcowan.me.uk (Bruce Cowan) Date: Fri, 28 May 2010 19:10:05 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: References: Message-ID: <1275070205.4469.1.camel@Scooby-Dum> On Fri, 2010-05-28 at 17:59 +0100, Richard Hughes wrote: > I'm planning a new release of gnome-color-manager unstable to become > 2.31.2 -- if you have any translations to update and push, please do > them this weekend. > > Any broken spelling or grammar (or anything that's just hard to > translate) please email me. > > Thanks. After a rather limited review (by looking at the new strings in the en_GB translation), here's a fix: ../data/gcm-prefs.ui.h:82 "Reset the sliders to thier default values" -- Bruce Cowan From hughsient at gmail.com Sat May 29 07:27:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 29 May 2010 08:27:24 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: <1275070205.4469.1.camel@Scooby-Dum> References: <1275070205.4469.1.camel@Scooby-Dum> Message-ID: On 28 May 2010 19:10, Bruce Cowan wrote: > Reset the sliders to thier default values Fixed, thanks. Richard. From michielwittkampf at gmail.com Wed May 5 07:42:27 2010 From: michielwittkampf at gmail.com (Michiel Wittkampf) Date: Wed, 5 May 2010 09:42:27 +0200 Subject: GCM and digiKam - how to configure? Message-ID: Hi GCM developers / enthousiasts, I have a question which I could not find the answer for in fora, manuals, color management theorie, etc. Can I use GCM and digiKam succesfully on the same computer, with good colors? And how? Should I enable color management on both, or on one of them? And which suboptions? I looked at the results of switching the folowing options, but didn't figure it out. digiKam: - Enable Color Management - Use color managed view (in editor / for previews and thumbnails) GCM: - Apply display correction - (Set profile for color managed applications.) According tot the digiKam manual Xcalib / Argyll are alternatives to the option 'Use color managed view' in digiKam.* So I supose CGM is too. Yet, when using CGM's 'Apply display correction' makes the screen darker, and using digiKam? 'Use color managed view' gives a brighter picture, while using the same profile. So I am confused. Can you please help me? Greetings, Michiel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Wed May 5 08:00:03 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 5 May 2010 09:00:03 +0100 Subject: GCM and digiKam - how to configure? In-Reply-To: References: Message-ID: On 5 May 2010 08:42, Michiel Wittkampf wrote: > Can you please help me? Well, you certainly want to enable color management in digikam. This means the image source profile is used and is converted to the screen profile, as long as you set the profile for color managed applications in GCM. By setting the source profile you're really just setting a X atom on the root window which digikam can detect and use. If digikam works as a ICC profile in X compatible client, you just have to enable both options in GCM and both options in digikam. Are you using the vendor profile for our screen or are you using a calibrated generated version? Without come sort of calibration you don't know whether the lighter or darker image is the "correct" image. Richard. From hughsient at gmail.com Thu May 6 14:05:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 6 May 2010 15:05:36 +0100 Subject: GNOME Color Manager 2.31.1 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.1 ~~~~~~~~~~~~~~ Released: 2010-05-06 * Translations - Added Japanese translation (Ryo Fujita) - Added Punjabi Translation (A S Alam) - Added Ukrainian translation (Maxim V. Dziumanenko) - Updated British English translation (Bruce Cowan) - Updated German translation (Mario Bl?ttermann) - Updated Italian translation (Francesco Groccia) - Updated Lithuanian translation (Aurimas ?ernius) - Updated Norwegian bokm?l translation (Kjartan Maraas) - Updated Polish translation (Piotr Dr?g) - Updated Portuguese translation (Ant?nio Lima) - Updated Slovenian translation (Andrej ?nidar?i?) - Updated Spanish translation (Jorge Gonz?lez) * New Features: - Use a new application icon (Hylke Bons) - Add an experimental gcm-picker program to read spot colors (Richard Hughes) - Show much more detail in the color picker UI and allow the user to choose a RGB colorspace (Richard Hughes) - Show the EISA ID in the devices tab. Fixes rh#581837 (Richard Hughes) * Bugfix: - Clean up the temporary file created by cupsGetPPD2(). Fixes rh#582202 (Tim Waugh) - Do not connect to sane in gcm-apply, we only need XRandR devices. Fixes rh#585723 (Richard Hughes) - Do not explode when viewing the details of a CMYK profile (Richard Hughes) - Do not rely on an argyllcms specially patched to fix the arg[0] problem (Richard Hughes) - Don't prompt the user to calibrate the device again if we are re-using the GcmCalibrate instance (Richard Hughes) - Fix up the argyll install dialog. Fixes #616106 (Richard Hughes) - Fix up the profile precision dialog. Fixes #583398 (Richard Hughes) - Make gcm-fix-profile open the profile from memory, as then we can catch common access permission errors (Richard Hughes) - Make SANE support configurable at compile time. Fixes #616826 (Richard Hughes) - Offer to install shared-color-profiles-extra if it is not yet installed (Richard Hughes) Richard. From lists+gnome-color-manager at hoech.org Fri May 7 13:13:41 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:13:41 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: Message-ID: <4BE41205.6080301@hoech.org> Hi, recently I switched from the proprietary nvidia driver to noveau, so I could try the latest GCM :) I noticed that for screen calibration, always a quality of 'low' is used and a shaper+matrix profile is created from varying colorpatch amounts and quality parameter. Looking at the code, the 100-500 colorpatches used for the screen profiling really seem overkill for a simple matrix profile. So the first thing I'd suggest, is to always use a lower, fixed-amount colorpatch set: targen -d3 -e4 -g9 -m3, this yields 36 patches that most other profilers out there also seem to use and should give very good results with matrix profiles (of course YMMV, but imho it would be a good default. This is what I use in dispcalGUI atm). Then, I'd suggest colprof -qh for matrix profiles (lower quality levels will smooth the trc curves more, but I think high quality could model the device response more accurately). This shouldn't come at any speed penalty at the new low suggested colorpatch count. And, as GCM always does a calibration+profile, I'd use colprof -aS (single shaper+matrix) instead of -as (per channel shaper+matrix), as we can rely on the calibration already having established gray balance, thus no need to risk the per channel curves introducing banding or shimmering. These changes would remove the need for the current three profile 'precision' choices for screen calibration/profiling, so the last suggestion from me is to instead present the user with a choice for the calibration (dispcal) quality instead, or to get rid of the choice altogether (only for screen calibration/profiling ofcourse). What do you think? Am 06.05.2010 16:05, schrieb Richard Hughes: > 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.1 Regards -- Florian H?ch http://hoech.net From lists+gnome-color-manager at hoech.org Fri May 7 13:36:12 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:36:12 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE4174C.1050903@hoech.org> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From lists at hoech.net Fri May 7 13:33:36 2010 From: lists at hoech.net (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 15:33:36 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE41205.6080301@hoech.org> References: <4BE41205.6080301@hoech.org> Message-ID: <4BE416B0.6050309@hoech.net> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) Am 07.05.2010 15:13, schrieb Florian H?ch: > targen -d3 -e4 -g9 -m3 -- Florian H?ch http://hoech.net From pmjdebruijn at pcode.nl Fri May 7 15:48:54 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 7 May 2010 17:48:54 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: <4BE416B0.6050309@hoech.net> References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: > (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) > > Am 07.05.2010 15:13, schrieb Florian H?ch: >> >> targen -d3 -e4 -g9 -m3 I do agree 500 patches is a bit overkill... But the time it takes to measure a few extra patch is usually not that much, so I don't really see the point of measuring as few as possible patches... Is there any particularly reason why you're using -m3 instead of -f3? I think we need to trust Graeme a bit on the defaults... Regards, Pascal de Bruijn From lists+gnome-color-manager at hoech.org Fri May 7 16:47:39 2010 From: lists+gnome-color-manager at hoech.org (=?UTF-8?B?RmxvcmlhbiBIw7ZjaA==?=) Date: Fri, 07 May 2010 18:47:39 +0200 Subject: GNOME Color Manager 2.31.1 - suggested improvements for screen cal/profiling In-Reply-To: References: <4BE41205.6080301@hoech.org> <4BE416B0.6050309@hoech.net> Message-ID: <4BE4442B.5060804@hoech.org> Am 07.05.2010 17:48, schrieb Pascal de Bruijn: > On Fri, May 7, 2010 at 3:33 PM, Florian H?ch wrote: >> (correction: this should've been targen -d3 -e4 -g9 -m3 -f0) >> >> Am 07.05.2010 15:13, schrieb Florian H?ch: >>> >>> targen -d3 -e4 -g9 -m3 > > I do agree 500 patches is a bit overkill... But the time it takes to > measure a few extra patch is usually not that much, so I don't really > see the point of measuring as few as possible patches... Well, for 'shaper+matrix' profiles, when a certain amount of patches is reached, it doesn't seem to increase the accuracy of the curves perceptibly (atleast in my experience). > Is there any particularly reason why you're using -m3 instead of -f3? > I think we need to trust Graeme a bit on the defaults... Yes, agreed (actually I didn't know those were Graeme's defaults). And the default optimized farthest point sampling is working really great for LUT-type profiles and subtractive devices like printers. But I always found that when using additive devices like screens, shaper+matrix, and decreasing the number of patches, the simpler device grid spacing seemed to work as good (also note that -f3 will only add three ofps patches, while -m3 will generate 27 device grid patches). My own testing showed negligible difference in the resulting tone curves when comparing -f500 and -g9 -m3 -f0 (see attached, and ignore the jumping dot, thats just the point I was hovering when taking the screenshots). You could always increase the amount of grayscale patches for a 'single shaper+matrix' profile if increased curve accuracy is desired, but I would go as far as saying this is probably not even neccesary in most cases. Of course, YMMV. I can only talk about the few screens I've available, which is two cheap TN (one in a laptop), a PVA and an IPS panel, and some screens of other people I've tested so far (mostly PVA, some IPS). > Regards, > Pascal de Bruijn > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list -- Florian H?ch http://hoech.net -------------- next part -------------- A non-text attachment was scrubbed... Name: TRC.gif Type: image/gif Size: 10661 bytes Desc: not available URL: From pmjdebruijn at pcode.nl Sun May 9 00:21:26 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Sun, 9 May 2010 02:21:26 +0200 Subject: gcm-git gio dependancy Message-ID: Hi, The latest git checkout seems to require a newer version of gio than usual... /build/buildd/gnome-color-manager-2.31.2~git20100508/./configure: line 12841: GLIB_GSETTINGS: command not found checking for GLIB... configure: error: Package requirements (glib-2.0 >= 2.14.0 gobject-2.0 gthread-2.0 gio-2.0 >= 2.25.0) were not met: Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 I'm assuming this is intentional, for GSettings? Regards, Pascal de Bruijn From hughsient at gmail.com Sun May 9 09:39:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 9 May 2010 10:39:34 +0100 Subject: gcm-git gio dependancy In-Reply-To: References: Message-ID: On 9 May 2010 01:21, Pascal de Bruijn wrote: > The latest git checkout seems to require a newer version of gio than usual... > Requested 'gio-2.0 >= 2.25.0' but version of GIO is 2.24.0 > I'm assuming this is intentional, for GSettings? Sure. As GNOME Color Manager is a proposed module for 2.31.x I've been encouraged to push the GSettings code into master for wider testing. To get a good chance of "blessed" by GNOME we need to adhere to all the goals, and one of those is GSettings. You can use gnome-2-30 if you just want to use GCM on a stable system as I'm going to be quite aggressive backporting fixes. Richard. From hughsient at gmail.com Thu May 20 11:40:32 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 12:40:32 +0100 Subject: Adding device profiles Message-ID: In GCM, you can currently add "virtual" devices which you manually populate the fields then assign a profile. This sucks monkey balls. What I really want is to be able to point GCM at a RAW file (or TIFF, or PNG, or JPG) and for it to read out the metadata (EXIF data) and populate those text fields for me, and then autoselecting a profile if you've got one that matches. This allows us to provide the feature on the DBus interface too. To do this, I either need to depend on exiftool (perl, ick) or exifinfo (python, ick) or I can just decode the headers myself like I'm already doing for TIFF files. Assuming I do the latter, I really need a raw decoder, and the only one that looks sane from a packaging point of view is libopenraw -- which looks pretty easy to use. I can always make this a conditional build-time dep if this is not available in all distros. So, comments? Better ideas? Richard. From pmjdebruijn at pcode.nl Thu May 20 17:12:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Thu, 20 May 2010 19:12:41 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 1:40 PM, Richard Hughes wrote: > In GCM, you can currently add "virtual" devices which you manually > populate the fields then assign a profile. This sucks monkey balls. You forgot hairy :) > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Schweet! > To do this, I either need to depend on exiftool (perl, ick) or > exifinfo (python, ick) or I can just decode the headers myself like > I'm already doing for TIFF files. Well, since Nautilus already depends on libexif12 and libexempi, those would be the obvious candidates. That way GCM won't pull in extra dependancies... > Assuming I do the latter, I really need a raw decoder, and the only > one that looks sane from a packaging point of view is libopenraw -- > which looks pretty easy to use. I can always make this a conditional > build-time dep if this is not available in all distros. Well, I could be mistaken but libopenraw is extremely unfinished and doesn't support half of the fileformats dcraw does... Again, I haven't checked it recently so I could be mistaken! Maybe LibRaw is a workable solution? Regards, Pascal de Bruijn From knizek.confy at volny.cz Thu May 20 17:44:07 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 20 May 2010 19:44:07 +0200 Subject: Adding device profiles In-Reply-To: References: Message-ID: <1274377447.6560.13.camel@athlon> Richard Hughes p??e v ?t 20. 05. 2010 v 12:40 +0100: > What I really want is to be able to point GCM at a RAW file (or TIFF, > or PNG, or JPG) and for it to read out the metadata (EXIF data) and > populate those text fields for me, and then autoselecting a profile if > you've got one that matches. This allows us to provide the feature on > the DBus interface too. Will there be a provision for the situation "one camera" : "various profiles"? I usually use a single "universal" profile for my camera, however, there may be users with more variants - e.g. per type of scene light or a photo shooting session. regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 20 19:06:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 May 2010 20:06:24 +0100 Subject: Adding device profiles In-Reply-To: <1274377447.6560.13.camel@athlon> References: <1274377447.6560.13.camel@athlon> Message-ID: On 20 May 2010 18:44, Milan Kn??ek wrote: > Will there be a provision for the situation "one camera" : "various > profiles"? Sure. It's already supported in the DBus API and in the configuration file, somebody (me?) has to add the required UI parts. I'm not sure what it should look like, so ideas welcome. Richard. From hughsient at gmail.com Fri May 21 08:14:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 09:14:09 +0100 Subject: Help! I need a test RAW file Message-ID: Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of course, I could just take a picture with my D60, but I really don't want to add a huge 9Mb NEF file to git master just so I can test getting metadata in make check. Does anybody know how I can export or resize a RAW file with metadata so that it's only a few pixels in size? In git I have data/test/test.{png|jpg|tif} as test cases that are only a fex pixels across and thus are a few tens of K in size. I can promise beer in return. Thanks. Richard. From liw at liw.fi Fri May 21 08:17:22 2010 From: liw at liw.fi (Lars Wirzenius) Date: Fri, 21 May 2010 20:17:22 +1200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: <1274429842.27529.216.camel@havelock> On pe, 2010-05-21 at 09:14 +0100, Richard Hughes wrote: > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? If DNG format works, that would probably be your best bet. The proprietary, undocumented formats are read-only with all the tools I know of. Not that I know of a way to generate a DNG either. From pmjdebruijn at pcode.nl Fri May 21 08:34:39 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Fri, 21 May 2010 10:34:39 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. It might be a longshot, but maybe it's an idea to contact Dave Coffin? Regards, Pascal de Bruijn From lars.tore at mulebakken.net Fri May 21 09:04:53 2010 From: lars.tore at mulebakken.net (Lars Tore Gustavsen) Date: Fri, 21 May 2010 11:04:53 +0200 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. The rawsamples site have a Kodak DC50 raw file at 91kb http://www.rawsamples.ch/index_en.php From hughsient at gmail.com Fri May 21 10:43:45 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 11:43:45 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 20 May 2010 18:12, Pascal de Bruijn wrote: > Well, since Nautilus already depends on libexif12 and libexempi, those > would be the obvious candidates. > > That way GCM won't pull in extra dependancies... Sure, libexif gets us jpeg files working. I've added that just now, thanks. libexempi looks less useful unless you can parse the XMP data out of the RAW files, see below... > Well, I could be mistaken but libopenraw is extremely unfinished and > doesn't support half of the fileformats dcraw does... Again, I haven't > checked it recently so I could be mistaken! Sure, I'm not so interested in the output formats, just the XMP metadata in the file. Neither libraw or libopenraw seem to be able to extract the metadata from the raw file. Rawstudio and ufraw seem to use exiv2 which is written in C++, which is less than ideal (c++ compiler needed to compile GCM...). I'm not apposed to calling an external executable for this data, but exiftool with it's huge trail of perl deps isn't really on my wishlist. Richard. From hughsient at gmail.com Fri May 21 13:35:09 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:35:09 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() Message-ID: Now the functionality for assigning profiles to images is nearly finished (just drag the image file onto the virtual device dialog) -- I've also added a new DBus method: GetProfilesForFile() The idea is you feed it a image filename and out pops an array of profile filenames. Typically they'll be one entry in the array, in which case applications like Shotwell and GIMP should probably use the ICC profile in the main viewer. If there is more than one item in the array, then it's up to the application whether it wants to use the default (the first entry) or show a popup asking what profile to use. For the curious, I've also added this functionality to gcm-inspect. [hughsie at hughsie-t61 src]$ ./gcm-inspect --file ../data/tests/test.jpg Suitable profiles for: ../data/tests/test.jpg 1. /home/hughsie/.color/icc/GCM - NIKON - NIKON DSC D60 - NIKON NIKON DSC D60 7457338 (2010-02-08).icc Pascal de Bruijn, NIKON - NIKON DSC D60 (2010-02-08) All code is in git master. Richard. From andy at luto.us Fri May 21 13:52:26 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:52:26 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: I don't know if this counts for the beer, but I took the most compressible picture I could think of with my D40 (the sky, on a bright sunny day here in Boston, overexposed by quite a few stops). bzip2 gets it to 13K, attached. (bzip2 beats xz -9 by a bit and gzip quite handily). --Andy On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: > Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of > course, I could just take a picture with my D60, but I really don't > want to add a huge 9Mb NEF file to git master just so I can test > getting metadata in make check. > > Does anybody know how I can export or resize a RAW file with metadata > so that it's only a few pixels in size? In git I have > data/test/test.{png|jpg|tif} as test cases that are only a fex pixels > across and thus are a few tens of K in size. I can promise beer in > return. Thanks. > > Richard. > _______________________________________________ > gnome-color-manager-list mailing list > gnome-color-manager-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: overexposed.NEF.bz2 Type: application/x-bzip2 Size: 13187 bytes Desc: not available URL: From andy at luto.us Fri May 21 13:56:55 2010 From: andy at luto.us (Andrew Lutomirski) Date: Fri, 21 May 2010 09:56:55 -0400 Subject: Help! I need a test RAW file In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 9:52 AM, Andrew Lutomirski wrote: > I don't know if this counts for the beer, but I took the most > compressible picture I could think of with my D40 (the sky, on a > bright sunny day here in Boston, overexposed by quite a few stops). > > bzip2 gets it to 13K, attached. ?(bzip2 beats xz -9 by a bit and gzip > quite handily). That attachment is released under the CC0 license, available here: http://creativecommons.org/publicdomain/zero/1.0/legalcode --Andy > > --Andy > > On Fri, May 21, 2010 at 4:14 AM, Richard Hughes wrote: >> Right, I have a need for a .NEF, .CRF, (whatever) kind of raw file. Of >> course, I could just take a picture with my D60, but I really don't >> want to add a huge 9Mb NEF file to git master just so I can test >> getting metadata in make check. >> >> Does anybody know how I can export or resize a RAW file with metadata >> so that it's only a few pixels in size? In git I have >> data/test/test.{png|jpg|tif} as test cases that are only a fex pixels >> across and thus are a few tens of K in size. I can promise beer in >> return. Thanks. >> >> Richard. >> _______________________________________________ >> gnome-color-manager-list mailing list >> gnome-color-manager-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-color-manager-list >> > From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Fri May 21 13:57:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 May 2010 14:57:47 +0100 Subject: Matching ICC profiles from filenames: GetProfilesForFile() In-Reply-To: References: Message-ID: On 21 May 2010 14:35, Richard Hughes wrote: > Now the functionality for assigning profiles to images is nearly > finished (just drag the image file onto the virtual device dialog) Now even easier. Just drag a JPEG or TIFF image onto the main UI and all the device setup is done automatically. Richard. From hughsient at gmail.com Sat May 22 08:42:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:42:34 +0100 Subject: GNOME Color Manager wiki Message-ID: Some of you guys may not be aware of the GCM wiki page. That's fair enough, as until yesterday the content was tiny, and the page uninteresting. So, two late night later, I present http://live.gnome.org/GnomeColorManager It's quite a bit of a brain dump, and expect more content as I get more time. Hopefully you can see from the page what we're trying to achieve and the direction GCM is going in. It's a wiki, so if you see any spelling errors or glaring omissions, just jump in an make changes. Please don't move/delete/restructure vast swathes of content without asking first. Thanks. Richard From hughsient at gmail.com Sat May 22 08:47:36 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 22 May 2010 09:47:36 +0100 Subject: Supporting OpenIccDirectoryProposal Message-ID: OpenIccDirectoryProposal is a proposal to make the main CMMs in Linux and UNIX adhere to a common directory spec. I stumbled on it this morning, and agree with what it's trying to achieve. As such, I've committed two changes to GCM in git master (not gnome-2-30) to adhere to this spec: commit fef750d4bed38fa68d7b07b1963758f5d8d73210 Author: Richard Hughes Date: Sat May 22 08:36:09 2010 +0100 Use the common data path from OpenIccDirectoryProposal No migration is required, the old location is searched as well. :100644 100644 50f9001... 806fa26... M src/gcm-import.c :100644 100644 a0bd735... 882fc53... M src/gcm-profile-store.c :100644 100644 2760b75... 10e3367... M src/gcm-utils.c :100644 100644 3f9e5e0... 7c1c380... M src/gcm-utils.h commit 784a617285b82f4d2276cd8d7ce03d883066e10f Author: Richard Hughes Date: Sat May 22 08:24:58 2010 +0100 Use the common configuration path from OpenIccDirectoryProposal You will need to rename ~/.config/gnome-color-manager to ~/.config/color if you want to re-use your old configuration :100644 100644 2da35ed... 2760b75... M src/gcm-utils.c You can see from the last commit a rename is required if you don't want to re-assign all your profiles. I might do that automatically closer to the 2.31.2 release if there are people that file bugs, although it would be upsetting to run a GCM from a checkout which made your system GCM stop working. Maybe I can just put it in the release notes. Richard. From hughsient at gmail.com Mon May 24 07:40:16 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 08:40:16 +0100 Subject: Supporting OpenIccDirectoryProposal In-Reply-To: References: Message-ID: On 22 May 2010 09:47, Richard Hughes wrote: > You can see from the last commit a rename is required if you don't > want to re-assign all your profiles. I might do that automatically > closer to the 2.31.2 release if there are people that file bugs, > although it would be upsetting to run a GCM from a checkout which made > your system GCM stop working. Okay, I got sun-burnt on Sunday and had to sit inside for a few hours: commit a6c63ded454a8cde43ed9559c8b329da645e406e Author: Richard Hughes Date: Sun May 23 11:01:39 2010 +0100 Migrate the old device-profiles.conf to the new location so the user does not have to do it manually :100644 100644 ce2c1fb... b31f9bb... M data/org.gnome.color-manager.gschema.xml :100644 100644 962a7dd... 1327bae... M src/gcm-client.c :100644 100644 10e3367... 16be031... M src/gcm-utils.c :100644 100644 7c1c380... 384572f... M src/gcm-utils.h Richard. From hughsient at gmail.com Mon May 24 12:49:23 2010 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 24 May 2010 13:49:23 +0100 Subject: Adding device profiles In-Reply-To: References: Message-ID: On 21 May 2010 11:43, Richard Hughes wrote: > Rawstudio and ufraw seem to use exiv2 which is written in C++ commit 926ecf7a8f086dd0f2f2c63b1ba0b9f3700d8cdc Author: Richard Hughes Date: Mon May 24 13:44:19 2010 +0100 Add optional exif2 support so we can get properties of RAW files too Note: This is implemented as a separate executable that is used to avoid either compiling GCM with g++ and to avoid weird linker errors on random platforms :100644 100644 4cbdaa7... 1812054... M configure.ac :100644 100644 a79decd... 08f3786... M contrib/gnome-color-manager.spec.in :100644 100644 a745113... 451b0ab... M data/tests/Makefile.am :000000 100644 0000000... 3235462... A data/tests/test.kdc :100644 100644 55d7092... ef822fc... M src/.gitignore :100644 100644 684b583... 61e0173... M src/Makefile.am :100644 100644 a985383... 532084f... M src/gcm-exif.c :000000 100644 0000000... 6385d5b... A src/gcm-helper-exiv.cpp :100644 100644 8077a4a... 587be3e... M src/gcm-self-test.c Richard. From hughsient at gmail.com Wed May 26 08:29:47 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 09:29:47 +0100 Subject: Multiple profile device support Message-ID: Why might we want more than one profile for a device? * A monitor has two selectable modes, sRGB and wide gamut * A printer has different profiles depending on the media and inks * A camera has different profiles depending on whether it's shot in the studio or outside What situations still require 1:1 device profile mapping: * Scanners, where nothing can be altered Now, the DBus interface and the device-profiles configuration already supports multiple profiles for each device, just not the UI. If you guys have any other use cases for more than one profile for a device then I'm interested. So, if we decide we need prefs UI to choose between studio and outside camera profiles, what should it looks like? ___________________________________ | Nikon D60 Studio (default) |#Nikon#D60#Outside################ |__________________________________ [ Make default for device ] [ Assign another profile ] [ Unassign this profile ] Or we just have the buttons [ Add ] [ Remove ] and [ Make default ] Although then we have two "Add" and "Remove" buttons on the same tab. Or do we have hypertext entries in the cellview itself: __________________________________________________________ | Nikon D60 Studio (default) | /Remove/ |#Nikon#D60#Outside#############| /Make default/, /Remove/ |_______________________________|_/Add another profile/___ Or do we just let the user drag the profiles up and down to select the order? Double click to make default? Is this discoverable enough? How do users add profiles from the existing combobox? ASCII art welcome. :-) Thanks, Richard From paul at fincc.com Wed May 26 08:57:46 2010 From: paul at fincc.com (Paul Finnigan) Date: Wed, 26 May 2010 09:57:46 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274864266.2467.11.camel@localhost> Richard On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? ... > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. I have one to think about. I am racking my tiny mind to see how this would fit in with gcm! My camera profile is associated with an image! I have a Nikon D700, I thought other Nikon cameras took similar views. Each image has a profile associated with it according to the conditions under which the photograph was taken. I agree that five or six profiles will probably cover me for most of my work. But each image has a profile built in it. Do I need this or should the application be using this as a offset to a base profile? I have to say that currently most applications appear to show colour very well, once I have gcm setup. I just thought I would ask the question as to what should happen. -- Paul Finnigan From dan at berrange.com Wed May 26 08:56:54 2010 From: dan at berrange.com (Daniel P. Berrange) Date: Wed, 26 May 2010 09:56:54 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <20100526085654.GA25454@berrange.com> On Wed, May 26, 2010 at 09:29:47AM +0100, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut > * A printer has different profiles depending on the media and inks > * A camera has different profiles depending on whether it's shot in > the studio or outside > * A scanner can be in reflective media (paper) or transparent media (film / slides) mode. Each mode has potential for multiple profiles particularly for type of film > Now, the DBus interface and the device-profiles configuration already > supports multiple profiles for each device, just not the UI. If you > guys have any other use cases for more than one profile for a device > then I'm interested. > > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ > > [ Make default for device ] > [ Assign another profile ] > [ Unassign this profile ] > > Or we just have the buttons > > [ Add ] [ Remove ] and [ Make default ] > > Although then we have two "Add" and "Remove" buttons on the same tab. > > Or do we have hypertext entries in the cellview itself: > __________________________________________________________ > | Nikon D60 Studio (default) | /Remove/ > |#Nikon#D60#Outside#############| /Make default/, /Remove/ > |_______________________________|_/Add another profile/___ > > Or do we just let the user drag the profiles up and down to select the > order? Double click to make default? Is this discoverable enough? How > do users add profiles from the existing combobox? NB, for scanners you can have 2 defaults. Since the scanner program knows whether its doing transparencies or reflective media, it will want a default profile for each mode, along with other non-default choices for each. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From hughsient at gmail.com Wed May 26 09:24:35 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:24:35 +0100 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On 26 May 2010 09:57, Paul Finnigan wrote: > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Right, but the GetProfilesForFile returns a list of profiles (by design) so you can easily ask GCM for the list of profiles for a specific image. > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Well, if the image has an embedded profile then we don't need to ask GCM anything. Richard. From hughsient at gmail.com Wed May 26 09:26:48 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 10:26:48 +0100 Subject: Multiple profile device support In-Reply-To: <20100526085654.GA25454@berrange.com> References: <20100526085654.GA25454@berrange.com> Message-ID: On 26 May 2010 09:56, Daniel P. Berrange wrote: > ?* A scanner can be in reflective media (paper) or transparent > ? media (film / slides) mode. Each mode has potential for multiple > ? profiles particularly for type of film Point taken. So it does make sense to have the multiple-profile / device selector for all device types. > NB, for scanners you can have 2 defaults. Since the scanner program > knows whether its doing transparencies or reflective media, it will > want a default profile for each mode, along with other non-default > choices for each. Sure, that's exactly what the "options" hint is supposed to allow. We've not specified the allowed values for the hint, although sticking in something like "transparency" should probably change the /order/ (and thus also the default) of the profiles returned. Richard. From pmjdebruijn at pcode.nl Wed May 26 15:50:41 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:50:41 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 10:29 AM, Richard Hughes wrote: > Why might we want more than one profile for a device? > > * A monitor has two selectable modes, sRGB and wide gamut Does this actually make sense? Not really.... You profile your monitor, and then the CMS convert sRGB into the screens RGB... A display profile will always be about a display's native gamut (within a certain set of display settings). But again here, for the display settings, there is usually only way correct way to set them. > * A printer has different profiles depending on the media and inks Profiles galore! > * A camera has different profiles depending on whether it's shot in > the studio or outside Indeed... Though this is often very much exaggerated... A single profile well-made against daylight or a strobe can usually cover 80/90% of your usage scenario's, unless you're really anal retentive... > * Scanners, where nothing can be altered Think of negative/positive scanning as well, which could mean a profile per type of negative. > So, if we decide we need prefs UI to choose between studio and outside > camera profiles, what should it looks like? > ___________________________________ > | Nikon D60 Studio (default) > |#Nikon#D60#Outside################ > |__________________________________ This makes very little sense! At least if I'm getting this right (big IF) :) When developing RAWs: Which profile to apply is a decision you make on-the-fly when working with a RAW converter... When printing: Which profile to apply is a decision you make on-the-fly when loading the printer with paper before printing... This could very well be per 1 sheet... When scanning: To set a generic scanner profile this make sense... but for negatives/transparancies this is something you would apply on-the-fly using the scanning tool... So I'm not sure to what extent it is useful for GCM to get involved here... Except for setting the default profile :) Regards, Pascal de Bruijn From pmjdebruijn at pcode.nl Wed May 26 15:58:03 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 17:58:03 +0200 Subject: Multiple profile device support In-Reply-To: <1274864266.2467.11.camel@localhost> References: <1274864266.2467.11.camel@localhost> Message-ID: On Wed, May 26, 2010 at 10:57 AM, Paul Finnigan wrote: > Richard > > On Wed, 2010-05-26 at 09:29 +0100, Richard Hughes wrote: >> Why might we want more than one profile for a device? > ... >> Now, the DBus interface and the device-profiles configuration already >> supports multiple profiles for each device, just not the UI. If you >> guys have any other use cases for more than one profile for a device >> then I'm interested. > > I have one to think about. I am racking my tiny mind to see how this > would fit in with gcm! My camera profile is associated with an image! Really? Thus far I've never seen any camera profile RAW files with embedded profiles... Or am I misunderstanding? > I have a Nikon D700, I thought other Nikon cameras took similar views. > Each image has a profile associated with it according to the conditions > under which the photograph was taken. How do you figure this? > I agree that five or six profiles will probably cover me for most of my > work. But each image has a profile built in it. Do I need this or should > the application be using this as a offset to a base profile? Please don't confuse an actual color profile, for other color post-processing options... For example I think CaptureNX actually generates ICC files on-the-fly for the processing settings selected in the app, and seems to do the full image transform in the CMS... At least as far as I heard (I never personally investigated this properly, HEARSAY WARNING). It's a pretty creative approach, though not how color management is intended nor how it should be used... If you profile your camera yourself, usually a few profiles should do very well... I tend to get by very well with only a single matrix only profile), and a decent basecurve. Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 16:02:01 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 17:02:01 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 16:50, Pascal de Bruijn wrote: > Does this actually make sense? Not really.... There are wide-gamut monitors that allow different "modes" so you artificially lower the gamut range so you don't blow your eyes when you try to view uncorrected content. It turns out HP have a large number of those monitors "in the field" so to speak, and they are quite keen on getting them to work correctly. > A single profile well-made against daylight or a strobe can usually > cover 80/90% of your usage scenario's, unless you're really anal > retentive... Sure, but people that care about color management and anally retentive people are very co-morbid :-) >> * Scanners, where nothing can be altered > > Think of negative/positive scanning as well, which could mean a > profile per type of negative. Right, makes sense. > This makes very little sense! At least if I'm getting this right (big IF) :) > > When developing RAWs: > Which profile to apply is a decision you make on-the-fly when working > with a RAW converter... Yes, that's how it used to be. The RAW converter has to be "set" manually with the ICC profile to use, which is gobbledygook that nobody will do. That's something I want to automate, see http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ for details. The idea is that the RAW converter (darktable, f-spot, whatever) calls into GCM to find out the ICC profile that should be used for each file. > When printing: > Which profile to apply is a decision you make on-the-fly when loading > the printer with paper before printing... This could very well be per > 1 sheet... Sure. The CUPS parts are very much still up in the air and are being worked on. We don't have a very good story there yet. > When scanning: > To set a generic scanner profile this make sense... but for > negatives/transparancies this is something you would apply on-the-fly > using the scanning tool... Right, but presumably one wants to be used by default? For something like simple scan we can just tell it the default profile and there is no UI to configure. > So I'm not sure to what extent it is useful for GCM to get involved > here... Except for setting the default profile :) I'm really pushing GCM into the CMM role, where the defaults are got from GCM rather than set in each and every application. Richard. From pmjdebruijn at pcode.nl Wed May 26 16:45:50 2010 From: pmjdebruijn at pcode.nl (Pascal de Bruijn) Date: Wed, 26 May 2010 18:45:50 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > On 26 May 2010 16:50, Pascal de Bruijn wrote: >> Does this actually make sense? Not really.... > > There are wide-gamut monitors that allow different "modes" so you > artificially lower the gamut range so you don't blow your eyes when > you try to view uncorrected content. It turns out HP have a large > number of those monitors "in the field" so to speak, and they are > quite keen on getting them to work correctly. I actually have a HP screen, it does have an sRGB mode indeed... But this means the screen fiddles with it's internal LUT a bit to fake this... It's not really a great idea... The extra saturation because of the wide gamut usually is not that much of a problem... It's usually the high brightness combined with the extra saturation that is the problem... High brightness is usually frowned upon in color management anyways. When I turn up my brightness to 100% I need sunscreen to sit behind my screen for prolonged periods... That's why I set my brightness to a value that correlates to ~200cm/m2. >> A single profile well-made against daylight or a strobe can usually >> cover 80/90% of your usage scenario's, unless you're really anal >> retentive... > > Sure, but people that care about color management and anally retentive > people are very co-morbid :-) Hard to argue with that. >>> * Scanners, where nothing can be altered >> >> Think of negative/positive scanning as well, which could mean a >> profile per type of negative. > > Right, makes sense. > >> This makes very little sense! At least if I'm getting this right (big IF) :) >> >> When developing RAWs: >> Which profile to apply is a decision you make on-the-fly when working >> with a RAW converter... > > Yes, that's how it used to be. The RAW converter has to be "set" > manually with the ICC profile to use, which is gobbledygook that > nobody will do. That's something I want to automate, see > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > for details. And that's how it should be in the future... GCM can only help by not providing any irrelevant profiles... So if I have a 400D, it could provide 400D profiles only so if I have a 5D as well, I won't see those profiles... But GCM cannot tell whether a picture needs the "daylight" profile or the "studio" profile... Obviously this is where the default comes in... But the user still needs to be easy-able to make a last minute decision about this, without having to start gcm-prefs. > The idea is that the RAW converter (darktable, f-spot, whatever) calls > into GCM to find out the ICC profile that should be used for each > file. > >> When printing: >> Which profile to apply is a decision you make on-the-fly when loading >> the printer with paper before printing... This could very well be per >> 1 sheet... > > Sure. The CUPS parts are very much still up in the air and are being > worked on. We don't have a very good story there yet. Boatload of work... :( >> When scanning: >> To set a generic scanner profile this make sense... but for >> negatives/transparancies this is something you would apply on-the-fly >> using the scanning tool... > > Right, but presumably one wants to be used by default? For something > like simple scan we can just tell it the default profile and there is > no UI to configure. Again the scanning app doesn't know whether I'm scanning a transparancy or not... For an application like simple-scan this could be omitted because it's _not_ intended as a scanner's swiss-army-knife... But for say XSane (if anybody is still working on that, god forbid), it would still be the end-user that need to select which exact profile he needs to apply to his image... Obviously profiles for completely different scanner types could be omitted. > >> So I'm not sure to what extent it is useful for GCM to get involved >> here... Except for setting the default profile :) > > I'm really pushing GCM into the CMM role, where the defaults are got > from GCM rather than set in each and every application. That's good... Centralised defaults are VERY good :) Though there is another thing you need to keep track of... Profiles are not per-se interchangeable between different applications... For example UFRaw does not output 100% true linear RGB RAW before applying the profile... DCRAW/Darktable do at least as far as I know... Regards, Pascal de Bruijn From hughsient at gmail.com Wed May 26 17:56:57 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 18:56:57 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 17:45, Pascal de Bruijn wrote: > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... Sure, I don't disagree. > That's why I set my brightness to a value that correlates to ~200cm/m2. Out of interest, how did you measure that? > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > > So if I have a 400D, it could provide 400D profiles only so if I have > a 5D as well, I won't see those profiles... Sure at the moment it matches against make, model and camera serial number. > But GCM cannot tell whether a picture needs the "daylight" profile or > the "studio" profile... Correct. In the absence of hints GCM provides both profiles, well, it actually provides the filename and the description ready formatted, so applications like GIMP can easy populate a combobox if there are more than one entry and they don't just want the default. It's the reason we have the complicated a(ss) return type so applications don't have to parse the profile themselves to get the localized description value. > Again the scanning app doesn't know whether I'm scanning a > transparancy or not... It might, cleverer HP scanners can detect what accessories they have inserted. In general I agree tho. > But for say XSane (if anybody is still working on that, god forbid), > it would still be the end-user that need to select which exact profile > he needs to apply to his image... Obviously profiles for completely > different scanner types could be omitted. At the moment GCM just sets up the XSane default profile with the default profile for the device. I know for sure it can't support more than one profile, and I also know that XSane struggles with filenames with spaces in them... > Profiles are not per-se interchangeable between different > applications... For example UFRaw does not output 100% true linear RGB > RAW before applying the profile... DCRAW/Darktable do at least as far > as I know... Surely that's a UFRaw bug then? Richard. From hughsient at gmail.com Wed May 26 19:00:34 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 20:00:34 +0100 Subject: Multiple profile device support In-Reply-To: References: Message-ID: On 26 May 2010 09:29, Richard Hughes wrote: > ASCII art welcome. :-) The attached screenshot is what's in git master. Feedback welcome. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Color Management.png Type: image/png Size: 53028 bytes Desc: not available URL: From knizek.confy at volny.cz Wed May 26 18:45:31 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:45:31 +0200 Subject: Multiple profile device support In-Reply-To: References: Message-ID: <1274899531.19315.33.camel@athlon> Pascal de Bruijn p??e v St 26. 05. 2010 v 18:45 +0200: > On Wed, May 26, 2010 at 6:02 PM, Richard Hughes wrote: > > On 26 May 2010 16:50, Pascal de Bruijn wrote: > >> Does this actually make sense? Not really.... > > > > There are wide-gamut monitors that allow different "modes" so you > > artificially lower the gamut range so you don't blow your eyes when > > you try to view uncorrected content. It turns out HP have a large > > number of those monitors "in the field" so to speak, and they are > > quite keen on getting them to work correctly. > > I actually have a HP screen, it does have an sRGB mode indeed... But > this means the screen fiddles with it's internal LUT a bit to fake > this... It's not really a great idea... > It is not a best solution, but until the complete desktop is colour managed, it is needed to have a chance to switch to sRGB emulation. Otherwise, the window decorations and images in non-colour managed apps look unrealistic. > > Yes, that's how it used to be. The RAW converter has to be "set" > > manually with the ICC profile to use, which is gobbledygook that > > nobody will do. That's something I want to automate, see > > http://blogs.gnome.org/hughsie/2010/05/23/gnome-color-manager-and-you/ > > for details. > > And that's how it should be in the future... GCM can only help by not > providing any irrelevant profiles... > I agree. GCM would not only provide a default profile for each device type (one for 5D, another for D200, etc.) but also a list of potentially usable profiles, which were previously assigned by the user for the particular device. The advantage is that the list of available profiles gets shorter. >From the work-flow viewpoint, it would be really slow to start GCM UI only to change the profile or rendering intent for a single photo. This option must be available directly in the app (RAW converter, editor). Regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From knizek at volny.cz Wed May 26 18:54:59 2010 From: knizek at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Wed, 26 May 2010 20:54:59 +0200 Subject: Interoperability of GCM? Message-ID: <1274900099.19315.40.camel@athlon> Hello, since GCM is getting more into business of the central repository of ICC profiles for other applications, how does it stand from the viewpoint of interoperability between various desktop environments? I use mainly Gnome or GTK based apps (EoG, UFRaw, GIMP, CinePaint) but also digiKam (KDE) for archive management. If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers will be willing to implement support for GCM. Regards, Milan Kn??ek knizek (na) volny (te?ka) cz http://www.milan-knizek.net - O linuxu a fotografov?n? From hughsient at gmail.com Wed May 26 22:16:43 2010 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 26 May 2010 23:16:43 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274900099.19315.40.camel@athlon> References: <1274900099.19315.40.camel@athlon> Message-ID: On 26 May 2010 19:54, Milan Kn??ek wrote: > since GCM is getting more into business of the central repository of ICC > profiles for other applications, how does it stand from the viewpoint of > interoperability between various desktop environments? Well, GCM exposes a DBus interface that applications to use, rather than a shared library like other CMS solutions have tried to do. Being a DBus interface it means that applications written in any language can access the interface at runtime, rather than build time. This also means that if the interface is not available (either disabled, or just not installed) then the application can fall back to defaults or asking the user. It's like a soft run-time dep, rather than an implicit hard build-time dep. > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > will be willing to implement support for GCM. Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core access objects just depend on Glib (rather than GTK and random stuff like libnotify) so it would be very easy to write a program to expose the DBus interface without any of the other deps which applications like digiKam could use. Glib is already part of the LSB so it'll be installed on pretty much any system regardless of desktop environment. Are you worried specifically about the interface name (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) or are you just interested in discussion? :) Richard From knizek.confy at volny.cz Thu May 27 09:35:11 2010 From: knizek.confy at volny.cz (Milan =?UTF-8?Q?Kn=C3=AD=C5=BEek?=) Date: Thu, 27 May 2010 11:35:11 +0200 Subject: Interoperability of GCM? In-Reply-To: References: <1274900099.19315.40.camel@athlon> Message-ID: <1274952911.3401.168.camel@athlon> Richard Hughes p??e v St 26. 05. 2010 v 23:16 +0100: > On 26 May 2010 19:54, Milan Kn??ek wrote: > > since GCM is getting more into business of the central repository of ICC > > profiles for other applications, how does it stand from the viewpoint of > > interoperability between various desktop environments? > > Well, GCM exposes a DBus interface that applications to use, rather > than a shared library like other CMS solutions have tried to do. Being > a DBus interface it means that applications written in any language > can access the interface at runtime, rather than build time. This also > means that if the interface is not available (either disabled, or just > not installed) then the application can fall back to defaults or > asking the user. It's like a soft run-time dep, rather than an > implicit hard build-time dep. > Okay, thanks for info. > > If GCM is dependent on Gnome libs, I wonder if e.g. digiKam developers > > will be willing to implement support for GCM. > > Sure, GCM does depend on a lot of GNOMEy stuff. That said, the core > access objects just depend on Glib (rather than GTK and random stuff > like libnotify) so it would be very easy to write a program to expose > the DBus interface without any of the other deps which applications > like digiKam could use. Glib is already part of the LSB so it'll be > installed on pretty much any system regardless of desktop environment. > > Are you worried specifically about the interface name > (org.gnome.ColorManager) or the deps of the project (e.g. libnotify) > or are you just interested in discussion? :) On many other forums, there is a lot of flame wars about KDE/GNOME/whatever by both users and developers and hence I assume that proposing to digiKam developers to add a DBus interface to a GNOME application could result in unnecessary refusal or at least a heated discussion. I personally do not care much and rather try to use applications which fulfil my needs. Having a standardise interface (open file dialog, etc) would be a benefit, but Linux is not there yet. I assume that a politically feasible way for digiKam would be to have a KDE GUI (equivalent to GCM GUI) above the core access objects, and org.gnome.SomeThing might make it a bit more difficult. Anyway, I guess we (users) will have to wait some time until it gets standardised and things will then settle themselves. The worst solution would be to have GCM and "KCM" running at the same moment and fighting for screen calibration... P.S. I have briefly read the OpenICC mailing list discussion recently. Best regards, Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only) From hughsient at gmail.com Thu May 27 09:44:19 2010 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 27 May 2010 10:44:19 +0100 Subject: Interoperability of GCM? In-Reply-To: <1274952911.3401.168.camel@athlon> References: <1274900099.19315.40.camel@athlon> <1274952911.3401.168.camel@athlon> Message-ID: On 27 May 2010 10:35, Milan Kn??ek wrote: > On many other forums, there is a lot of flame wars about > KDE/GNOME/whatever by both users and developers and hence I assume that > proposing to digiKam developers to add a DBus interface to a GNOME > application could result in unnecessary refusal or at least a heated > discussion. Sure. I'm not that bothered about the name of the interface I'm using. I'm not sure making the dbus interface org.hughsie.ColorManager is any more cross desktop than org.gnome.ColorManager -- but I do understand the perception. > I assume that a politically feasible way for digiKam would be to have a > KDE GUI (equivalent to GCM GUI) above the core access objects, and > org.gnome.SomeThing might make it a bit more difficult. Yes. Ideally KDE could do a simple KCM which also wrote to ~/.config/device-profiles.conf and also provided the same interface. Note: If this was a viable option, I would have no hesitation to changing the DBus name to something non-gnome and working the KDE guys to get something working. > Anyway, I guess we (users) will have to wait some time until it gets > standardised and things will then settle themselves. The worst solution > would be to have GCM and "KCM" running at the same moment and fighting > for screen calibration... Sure. GCM or the mythical KCM would only be started by the correct desktop, and if they share a same name, then the correct one would be autostarted at session login. Note, a simple KCM would probably only take a few days worth of programming to put together. Richard. From hughsient at gmail.com Fri May 28 16:59:20 2010 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 28 May 2010 17:59:20 +0100 Subject: New gnome-color-manager release next Monday Message-ID: I'm planning a new release of gnome-color-manager unstable to become 2.31.2 -- if you have any translations to update and push, please do them this weekend. Any broken spelling or grammar (or anything that's just hard to translate) please email me. Thanks. Richard. From bruce at bcowan.me.uk Fri May 28 18:10:05 2010 From: bruce at bcowan.me.uk (Bruce Cowan) Date: Fri, 28 May 2010 19:10:05 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: References: Message-ID: <1275070205.4469.1.camel@Scooby-Dum> On Fri, 2010-05-28 at 17:59 +0100, Richard Hughes wrote: > I'm planning a new release of gnome-color-manager unstable to become > 2.31.2 -- if you have any translations to update and push, please do > them this weekend. > > Any broken spelling or grammar (or anything that's just hard to > translate) please email me. > > Thanks. After a rather limited review (by looking at the new strings in the en_GB translation), here's a fix: ../data/gcm-prefs.ui.h:82 "Reset the sliders to thier default values" -- Bruce Cowan From hughsient at gmail.com Sat May 29 07:27:24 2010 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 29 May 2010 08:27:24 +0100 Subject: New gnome-color-manager release next Monday In-Reply-To: <1275070205.4469.1.camel@Scooby-Dum> References: <1275070205.4469.1.camel@Scooby-Dum> Message-ID: On 28 May 2010 19:10, Bruce Cowan wrote: > Reset the sliders to thier default values Fixed, thanks. Richard.