Re: Adding printer profiling support
- From: Pedro Côrte-Real <pedro pedrocr net>
- To: gnome-color-manager-list <gnome-color-manager-list gnome org>
- Subject: Re: Adding printer profiling support
- Date: Wed, 17 Feb 2010 20:50:09 -0800
On Wed, Feb 17, 2010 at 6:05 AM, Richard Hughes <hughsient gmail com> wrote:
> In a few days time, my nice lovely ColorMunki should be delivered.
> Before it is, I figured I should get up to speed on how to profile
> printers, so we know what UI to add to GCM, and so I can get up to
> speed quickly.
>
> So. Does anybody have any hints, tips or suggestions on how to
> calibrate a printer. Device specific options (e.g. "The ColorMunki
> works really well with -f234 -g567") are more than welcome, as we
> already know the colorimeter device type.
Here is my experience with the Munki from my notes. I've used it
successfully to both profile a Dell U2410 LCD screen and an Epson
R2880. The LCD profiling should work already but I ended up using the
tools directly because g-c-m was failing to interact correctly with
the argyll tools when they asked to change the position of the device.
I think this has been fixed but haven't checked.
Anyway for the printing profiling my steps were:
1 - Generate a set of color patches
$argyll-targen -f 900 -v -d2 -c <BestPreviousProfile.icc> -A.8 <ProfileName>
This gave good results in the end. I did a first round of profiling
with 450 patches and that was used as BestPreviousProfile. For the
first round it would be instead:
$argyll-targen -f 450 -v -d2 <ProfileName>
In general the number of patches to create is a judgment call. I don't
know how we can present this option to the user. Maybe doing the
calculation in reverse and asking him how many sheets he is willing to
print and scan and then giving him an idea of how good a profile that
generates.
To then actually generate the files to print:
$ printtarg -t -v -iCM -pLetter <ProfileName>
"Letter" should obviously be changed to whatever paper the user wants
to use. The -iCM generates normally sized patches for the Munki, which
will require many sheets of paper to fit the 900 patches. See bellow
for a discussion of the hack I did to avoid this.
2. Print out the patches
I printed the resulting tiff files with PhotoPrint. I believe it uses
Gutenprint directly to drive the printer and is the only solution I
know right now that can actually apply the ICC profile when printing
later. The important thing here is to set the Gutenprint setting
"Color Correction" to "Uncorrected", and then any of the image
settings for the setup being used (type of paper, resolution,
dithering, etc).
3. Read back the patches
$chartread <ProfileName>
Munki will need to first be set to the self calibrate position, then
to the profiling position and then run through each of the patch lines
in turn while pressing its button. chartread asks for each of the
lines and will ask for them again if there is any error. The interface
needs to expose this. The last version allows you to reread a patch
line at will. I wonder if it would be possible to have some kind of
idea of how good the reads were and advise the user to reread one of
the lines if it is found to not be too good.
4. Generate the profile
$ colprof -v -D"<ProfileDescription>" -qm -S
<path/to/display/profile.icc> -cmt -dpp <ProfileName>
This runs by itself without problems. The specific flags are arguable
of course. I'm curious as to how changing -q (quality) to high or
ultra changes the profile. Some considerations:
- Some decent automatic naming would be nice
- Selecting the source profile would be nice too (defaulting to sRGB)
and possibly allowing the user to later generate the same profile with
another profile (e.g. AdobeRGB) as source might be useful.
- All the colprof settings can be changed without running the process
from the beginning again. I wonder if g-c-m should have the notion of
"Profiling runs" from which several actual profiles can be created.
This would solve the sRGB/AdobeRGB selection as well.
- Colprof outputs a final result with the mean and maximum error of
the profile. It would be great to give this result to the user in
plain English. Telling him the profile is "Poor/Fair/Good/Excellent"
or even a result out of 100.
The generated profile works in PhotoPrint. I assume it would also work
to transform an image before sending it to the general CUPS pipeline.
In theory the generated profile is only valid for the specific set of
settings used for the printer. In practice using the same profile on
even a different but similar paper is probably better than none at
all. And using it at a different resolution on the same paper may very
well be decent as well. I have no idea.
> In particular, we need to support printing to 6x4 inch cards, A4 and
> letter paper. I would love to integrate this better with CUPS (using
> the GTK print dialog for instance) than what we can do on the command
> line. We'll also need scans of the patches sheets that we send out, so
> we can show the user _how_ to scan in the patches. We'll also probably
> need a timer for "waiting for the ink to dry" and that sort of thing.
My only other comment about the process is that using the Munki with
default size patches is an incredible waste of paper and ink. In the
argyll mailing list someone pointed out some user's hack on dpreview
so I built one myself:
http://pedrocr.net/MunkiHelper.jpg
I'm not in any way suggesting that users should be expected to build
one of these but I would like to be able to configure g-c-m to have
not only the configuration for the normal Color Munki but also this
hack. The only difference is to change the -iCM flag to printtarg to
the -ii1, making the patches much smaller (by printing a sheet as if
it was for another instrument).
I know Pascal disagrees though. I share the sentiment of wanting to
make this as simple to the user as possible. However my experience
with this is that if we don't allow the user to fiddle with some of
the advanced settings, whenever he hits a speed bump the only option
is to fall back on argyll command line tools and totally bypass g-c-m.
That doesn't seem like much of a solution either. My suggestion would
be to have a set of default settings for each of the supported
instruments that work in a straightforward way and then an
"Advanced..." button to go and customize the settings.
Cheers,
Pedro
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]