[argyllcms] Re: What to include in bug reports?

Daniel Bachler wrote:

> The other problem I noticed (several patches displaying repeatedly
> while the patch counter goes up, then the patch counter staying the
> same and patches changing colour during calibration) is hard to
> reproduce.

It's absolutely normal for dispcal, not for dispread. It seems to me all right.

> Anyhow, now that the profile generation works (using version 1.0.4), I
> have another question: When I take a look at a gradient image in
> photoshop that goes through all the colours at full saturation (from
> red to green to blue to red again with the secondary colours in
> between) in a document that is in prophoto colour space the whole
> gradient is pretty uniform and seems to go to the maximum saturation
> as expected, except for a stripe around maximum blue saturation. There
> it drops off in brightness and saturation and this is by far the most
> non-uniform area. In a smaller colour space like adobe rgb everything
> is fine. I assume that this is because the prophoto colour space
> extends outside the famous horseshoe of visible colours, correct?

Yes. It's not quite correct to ask uniform gradients of unreal ProPhoto 
"colors" from v1.0.4. The problem described may take a place for relative and 
absolute rendering intents. If You do gamut mapping from ProPhoto to Your 
display, the result will be more and more correct.
In general, it's a bad idea to convert non-real image to real restricted gamut 
of a display. You had to compress initial gamut into destination gamut.
The good idea to perform individual gamut mapping of real images into Your 
display gamut. If You perform generic ProPhoto to Display profile gamut 
compession, You'll get significant saturaton loss, because mapping alhorithm 
had to compress huge gamut into small with minimal detal loss. I hope the 
compression in 1.1.0 version will better perform such tasks.

> But what I find strange is that it doesn't get mapped into the most
> saturated blue range but instead to a visibly darker and (maybe) less
> saturated area. Is there a way around this issue?

Yes, gamut mapping intended for solving this. But why You think the "true" 
ProPhoto RGB=0,0,255 is bright? Do You saw it on ProPhoto-reproducing device 
:))))) ? Honestly I know that B=255 must be brighter then B=127, but it very 
hard to proove on practice.

> Is this an issue of
> photoshop? Or is this transformation more complicated that it seems to
> a novice in colour transformation like me?

Photoshop just converts ProPhoto image into dispay space by Adobe ACE (or other 
selected) engine by display profile given. It's not a profile problem. It's an 
image problem, that it have unpractical gamut.
Yes, it can be converted with profile correctly, but it's not trivial. Gamut 
mapping (image-depended mapping is preferable) is needed.

Other related posts: