Re: Adding printer profiling support

[Pascal de Bruijn <pmjdebruijn pcode nl>]

On Thu, Feb 18, 2010 at 5:50 AM, Pedro Côrte-Real <pedro pedrocr net> wrote:
> 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.

I didn't have any such issues, so I guess this has been fixed for a while.

> 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>

The -c option is very advanced, and requires a lot of logic in GCM in
determining what the best previous profile actually was... Or it
requires the user to select their best previous profile, and if they
select the wrong profile (or GCM automatically selects the wrong
profile) it all goes horribly wrong... So in the short run using
preconditioning (-c) probably will do more harm than good...

This could very well be reconsidered when GCM matures.

The 900 patch count is probably way too high for default, since we
don't want to waste 4 sheets of expensive paper _by default_.
Especially since some packages of expensive paper come in per 10
sheets packages. We'd be wasting 40% :)

Please remember the ColorMunki vendor software only uses 90 or so
patches by default, so having 210/190 (1x A4/Letter) is a huge
improvement...

Thus far I've had excellent results using only 210 patches with no
preconditioning, and it only requires a single sheet of paper. So I'd
highly recommend to use this as default.

Anything that requires more than a single sheet of paper should
probably go in high quality/advanced mode... Also I'd recon we should
not really talk about patch counts, but the amount of paper... For for
A4 we would use 210/420/630/840/1050 patches, or for Letter
190/380/470/660?

> To then actually generate the files to print:
>
> $ printtarg -t -v -iCM -pLetter <ProfileName>

printtarg has a -h option, which will generate smaller patches for the
ColorMunki, which fits 210 patches onto A4 instead of 90 or so...

This option basically shrinks the rows to a third size, so the
ColorMunki is exactly as wide as 3 rows with the aperture exactly over
the middle row.

> 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).

Not everybody uses a gutenprint supported printer... :)

It's basically possible to profile any application with any printer
driver, as long as the app nor the printer driver do any dynamic
transforms...

Your case is very optimal... HPIJS for example does not have an
uncorrected mode, but the output is static, so it can be profiled.

I apply my printer profile in F-Spot, so I also used F-Spot to print
my target images... In theory this should not be very relevant.

> 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.

I don't think argyll does this yet... But it would be cool indeed...

> 4. Generate the profile
>
> $ colprof -v -D"<ProfileDescription>" -qm -S
> <path/to/display/profile.icc> -cmt -dpp <ProfileName>

Using -qm for 210 is an excellent default, but when we go into
advanced mode with > 500 patches, we should probably use -qh.

I've never used the -S -cmt -dpp options, so I highly doubt they are
required... We shouldn't pass random arguments unless strongly
indicated that we should. Otherwise we should trust Argyll's
defaults...

> 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:

Graeme highly discourages the ultra mode, in his words: ultra mode
exists to prove that nothing above high is required.

> - 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.

Huh? printer profiles usually use LAB as Profile Connection Space,
this has nothing to do with sRGB/AdobeRGB.

The pipeline:
Image (in sRGB) -> sRGB profile -> XYZ (-> LAB) -> printer profile ->
printer native RGB/CMYK -> hpijs/gutenprint

> - 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.

I'd probably be against this too (at least for the short run). This
will complicate the user interface (and GCM's codebase), and probably
won't be used much by most people, so this is not in line with GNOME's
goals.

In the long run we could re-evaluate this...

> - 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.

That would be nice... I'd stick to Poor/Fair/Good/Excellent, everybody
understands that. Though we need to be very careful about how we
determine what is what.

> 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.