[Openicc] Fwd: Re: Krita color adjusting

[Chris Murphy]

On Jun 14, 2005, at 6:58 AM, Casper Boemann wrote:

> On Tuesday 14 June 2005 11:11, Jan-Peter Homann wrote:
>
>> Hello Caspar, hello list
>>
>> Today, I want share some ideas about coloradjustment and  
>> colormanagement
>> with you. As you explainend to me in private mail, your goal is a
>> coloradjustment, which is as much as possible independent from the
>> actual colorspace /colormodel you are actually using in Krita.
>>
>> As I explained to you, my goal is to use abstract-profiles or
>> devicelink-profiles as universal exchange format for color- 
>> adjustments.
>> In this case, a coloradjustment could be applied to all applications,
>> which use lcms or argyllcms.
>>
>
> Won't it be a problem that you can't recreate the way the profile was
>  created?

I think the idea here is that you'd simply use abstract profiles and  
devicelink profiles to build an edit list. Only when saving a full  
resolution composite file, such as TIFF, would you actually "run" the  
edit list. This is not dissimilar to how Live Picture worked. You  
could work on multiple 100MB+ layers and have a work in progress file  
that was maybe 2MB. It referenced it's external files, and the native  
file format was just a compilation of edits. One big edit list. From  
that perspective you don't technically need to follow the ICC spec  
and have stand alone abstract and devicelink profiles. Personally I  
find the ICC spec annoying from the perspective of transparency - you  
can't see what's in them without a special viewer. I'm inclined to  
prefer a self-documenting profile format. Something XML perhaps.



>
>
>> Workingspace, Adjustmentlayer, Simulationspace, Outputspace
>> ------------------------------------------------------------
>> Colormanagement makes it possible, to work in very complex color
>> environments. I will first start with easier ones, and go later to  
>> the
>> more complex versions.
>>
>> 1) The easiest model: workingspace and the outspace.
>> ----------------------------------------------------
>> The workingspace can be e.g. sRGB and the outputspace could be the
>> colorspace of the monitor or the printer.
>> All coloradjustments are made directly in the workinspace. For  
>> getting
>> the right color at the monitor, the CMM converts constantly from
>> workingspace to the monitor-colorspace.
>> After finishing the work, the data can be saved directly, and the
>> profile of the workingspace is embedded. For printing the color is
>> converted from workingspace to printer-colorspace.
>> If an file should be used in another workingspace, it is converted  
>> to a
>> new workingspace. E.g. the sRGB data is converted to SWOP (CMYK).
>> Now SWOP is the new workingspace, but the overall configuration:
>> - workingspace->monitorprofile
>> - workingspace->printerprofile
>> - coloradjustments directly in workingspace
>> - Save with embedded workingspace profile
>> stay always the same
>>
>
> this is the model we use currently

Actually the easiest model is for everything to already be in display  
space, no display compensation at all. And you create iterations  
based on the current display profile. This naturally means you have  
portability problems for the original work, but you can get a screen  
to print match. It's just that it will be a different print for each  
workstation you're on.

>
>
>> 2) Workingspace, Simulationspace, Outputspace
>> ----------------------------------------------
>> This is a little bit more complex.
>> The workingspace is mostly a widegamut RGB-colorspace or Lab/LCH
>> colorspace. The goal is to work on color independent from the later
>> output intention.
>> Color-adjustments, retouches and composings are made in the  
>> workinspace
>> RGB or Lab/LCH.
>> During work, it is possible to simulate different colorspaces for the
>> intended output.
>> The profilechain is:
>> workingspace-simulationspace-monitorprofile
>> workingspace-simulationspace-printerprofile
>> workingspace-Save with transformation and embedding the simulation
>> colorspace
>>
>
> Pretty smart idea that I thought of myself, but it more or less  
> requires that
> we decide on a working space once and for all?

You could come up with a default recommendation. Lstar RGB, or  
perhaps something with a much larger gamut like ProPhoto RGB but with  
L* TRC. If people want to use something else, let them choose such a  
thing.

But for peat's sake, please do not equate this profile as something  
to use as the default profile for untagged images. That needs to be  
either sRGB always, or a separate selection. We're in a pickle with  
all of the Adobe apps because it uses the same setting (Working  
Spaces) for two different things. There is no good reason to assume  
Adobe RGB (1998)(1) for untagged images because untagged Adobe RGB  
(1998) images are not naturally occurring. They're either tagged, or  
they're not Adobe RGB (1998)(1). [In a very scant minority of  
situations you find  untagged Adobe RGB (1998)(1) images produced by  
some saboteur who isn't tagging their images for some reason.]

> I thought that XYZ would be a good workingspace, but we have a  
> problem with
> our natural painting then. So in order to stay flexible in  
> accomodating _any_
> colorspace I don't think this is the way to go.

Many correction and enhancement tools work best in RGB. In particular  
RGB where R=G=B. Some of them even make assumptions about tone response.


>> If you concentrate on a Master RGB-workinspace, it makes more  
>> sense to
>> implement RGB-based coloradjustment.
>>
>
> since we won't limit ourselves to a single workingspace, I don't  
> see this as
> an option.

Why not limit yourselves to a single intermediate space? If you pick  
one big enough, with a suitable tone response to  make it docile  
enough for 8-bits/channel compositing, why not? I think the  
limitation is going to be bit-depth, at a certain level of  
functionality, rather than the choice of edit space. You can get a  
way with a lot at 16-bits/channel. And 32-bits/channel floating point  
files have arrived.


(1) Or any other RGB space for that matter.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)