[argyllcms] Re: Question regarding gamut mapping for photographic images
- From: "Greg Sullivan" <greg.sullivan@xxxxxxxxxxxx>
- To: <argyllcms@xxxxxxxxxxxxx>
- Date: Fri, 22 Jul 2005 22:25:18 +1000
Graeme,
Thanks. I had only ever seen mention of perceptual contracting the gamut,
and it seems that this is the case.
Now, for saturation intent, my understanding is that this *maintained*
saturation, without expanding it, so that's not what I want. For example,
sRGB can't reproduce the dark vivid cyan hues that print can. (right?) I'd
like a profile which can expand this area of the gamut out, and yes, I don't
mind sacrificing accuracy, as long as the result looks appealing, and not
silly. So it looks like the enhanced saturation mode is what I'd like to
experiment with, yes. I hope it does it smoothly, though. I.e, I've read
that saturation intent is commonly used for business graphics. :)
Regarding the speed, it seemed to slow down at the stage where it updates a
percentage complete figure, which I think is related to the perceptual
processing(?). Without the perceptual table creation, a "high" quality
profile is quite quick to create. (feels like a few minutes, haven't timed
it) Adding the perceptual tables added between 1 and 2 *hours*, I think,
including perceptual saturation tables. FWIW, patches = 3000, and platform
is a 1GHz Pentium V, 1GB memory, and is running Windows XP.
Creating an "ultra" profile does take a very long time, even without the
perceptual tables. I perceive an incy wincy improvement in smoothness in
shadow flesh tones using ultra but I am not sure yet whether this is real.
(e.g, the dithering pattern may depend on the exact position that the image
is printed on the paper?)
I am very pleased with the results of my initial attempts at creating a
printer profile, anyway.
Greg.
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Graeme Gill
Sent: Friday, 22 July 2005 22:07
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding gamut mapping for photographic
images
Greg Sullivan wrote:
> Referring to this extract from a post to newsgroup sci.engr.color by
> tlianza, in thread "Chromacities of digital photo-exposer":
>
> "The final reproduction gamma of a reproduced
> image from an sRGB image through a Frontier printer should have a relative
> gamma of 1.2 to 1.6 and the extremes of sRGB should be mapped to the
> extremes of print material. Anything less than that will yeild an image
> that appears flat and lifeless when viewed at interior lighting
conditions."
>
> URL for the complete message:
>
http://groups-beta.google.com/group/sci.engr.color/msg/cd99c3af72b00a6b?hl=e
> n&
It's really a mater of philosophy. If you want the images to be as colorful
as possible, then by all means expand the source gamut out if it's smaller
than the destination. For some purposes, this may not be desirable though,
since at an extreme (converting a small gamut space into a very large one),
the images may begin to look a bit silly.
> Can I achieve this when I create a printer profile with Argyll? Is this,
in
> fact, simply what a perceptual intent normally does?
You can achieve something like this if you use the "saturation" intent
(use profile -t5 to use the saturation intent for the perceptual table,
or profile -T5 to use the non-saturation enhancing saturation intent
for the saturation intent profile table.)
It will distort the hues slightly more than "perceptual", but will expand
the source gamut outwards, not just compress it inwards, which is
what perceptual does. This is all assuming you are using profile
to target a specific source gamut (e.g. sRGB), or using icclink
in "non-dumb" mode.
> p.s Currently waiting for my sRGB perceptual tables to compute, for a
"high"
> quality profile. It's very, very, VERY slow! ;^)
Depends on the speed of your machine, and possibly amount of memory.
"high" quality is high resolution, and is usually rather slow.
It's the price paid for high precision and flexibility in computing
the reverse profile lookups. (I'm guessing it's spending most time
in creating the A2B table ?)
This is one of the applications where even a 100GHz machine wouldn't
be wasted, if such a thing existed.
"medium" quality is often good enough for many uses, and is noticeably
quicker to compute.
Graeme Gill.
Other related posts:
